Web accessibility procedure

Intent

This procedure ensures that accessibility is addressed at all stages of website development, including procurement, design, development of new websites and also the maintenance of existing websites. The result is a compliant and inclusive user experience for the widest possible audience.

Scope

This procedure applies to all staff members who plan projects for the RMIT web presence or contribute content, design components and coding to the RMIT web presence.

Exclusions

This procedure does not apply to:

  • Websites that have no relationship to RMIT (for example, personal or private sites)
  • Web authoring tools not provided or supported by the University
  • Student work used for an online showcase
  • academic research or experimental works not used for official purposes by the University
  • Courseware that cannot be reasonably supplied in accessible formats, such as simulation tools. In this case the educational designer and academic coordinate alternatives with the Disability Liaison Unit as required

Procedure steps and actions

Procedure (including key points)

Responsibility

Timeline

Content Owner,
Web Manager,
Project Manager,
Deputy Vice-Chancellor Academic,
Procurement Manager,
Digital and Customer Experience Strategy

Ongoing

Planning web accessibility

1. Review

1.1. Review the specific accessibility requirements captured in your New Website Proposal.

1.2. Review the minimum accessibility standards that apply to RMIT websites. Refer to the Web Accessibility Auditing Instruction, which details the WCAG checkpoints.

1.3. Research current best practices in accessible design techniques that may be relevant to the project.

1.4. Review the user requirements and consider the range disabled users in the audience for the website. You may analyse this group by:

1.4.1. Including people with disabilities in user analysis activities such as interviews, field studies and focus groups. Guidance for recruiting appropriate research participants is outlined in the User Research Instruction.

1.4.2. Ensuring that analyses of tasks, information architecture, business processes or workflows consider how people with disabilities do tasks, including any adaptive strategies that they might use.

1.4.3. Evaluate existing versions of resources or systems using the Web Accessibility Auditing Guidelines. This provides an audit process, checklist and report template for the required level of compliance, and identifies where design can be improved.


Web Manager


Ongoing

2. Plan

2.1. Create a copy of the Web Accessibility Checklist for use throughout the project. This will be used during review and feedback points (in conjunction with the User-Centred Design Checklist).

2.2. Allocate time in the project for including accessibility issues.

2.3. Ensure that specialist skills in accessible design and development exist within the project team.

2.3.1. Refer to Recruiting for Web Accessibility Skills for selection criteria.

2.3.2. Consult with Digital & CX staff as needed.

2.4. If commissioning a vendor-supplied web solution, refer to Commissioning Accessible Vendor-supplied Resources.


Project Manager


Ongoing

3. Communicate

3.1. Ensure that the project team, including the business owner, is aware of the project’s accessibility components.

3.1.1. Ensure that individuals understand any accessibility issues specific to their area (e.g. content creation, design, development).

3.1.2. Provide training where required. Consult with WSIP on the training options.

Creating web accessibility

During the creation of content, design solutions and development, record all checkpoint failures in your Web Accessibility Checklist. Refer to the Web Accessibility Auditing Instruction for details of the WCAG checkpoints that need to be met. The principles are:

  • Ensure that the widest range of visual, mobility, hearing, cognitive and learning limitations of people with disabilities is considered when developing conceptual models, design concepts and navigation systems.
  • Where there are shortfalls, let the user know and provide appropriate guidance.

Produce accessible websites during the creation phase and avoid resource-intensive remedial projects.


Project Manager


Ongoing

4. Content

4.1. Written content must be perceivable to all users in accordance with WCAG checkpoints.

4.1.1. Text must be created according to the Creating Text Content Procedure.

4.2. Image content must be perceivable to all users in accordance with WCAG checkpoints.

4.2.1 Images must be created according to the Image Procedure.

4.3. Video, audio and animated content must be perceivable to all users in accordance with WCAG checkpoints.

4.3.1. Video and audio must be created according to the Video and Audio Procedure.

4.4. Other content

4.4.1. Non-HTML resources published to the web (for download) must meet the following standards:

4.4.1.1. PDF documents – Accessibility Standards for PDF
4.4.1.2. Word documents – Accessibility Standards for Word Documents
4.4.1.3. Presentation documents – Accessibility Standards for Presentation Documents
4.4.1.4. Spreadsheet documents – Accessibility Standards for Spreadsheet Documents

4.4.2. Student content used for official purposes must follow the Accessibility Standards for Student Work.

4.4.3. Research content used for official purposes should follow the Accessibility Standards for Research Work.



Web Manager

Web Editor

Content Creator



Ongoing

5. Design

5.1. Working within the RMIT design system

5.1.1. The design templates specified in the GUI Design Instruction meet the WCAG checkpoints relating to visual design.

5.2. Working with custom user interface design

5.2.1. Custom graphical user interface (GUI) design components must be designed to meet the WCAG checkpoints relating to visual design.


Web Manager


Ongoing

6. Coding

6.1. Working within the RMIT design system

6.1.1. The HTML templates illustrated in the GUI Design Instruction meet WCAG checkpoints that relate to web development.

6.1.1.1. Main websites must use the templates available in the CMS.
6.1.1.2. Connected websites must use the template “shell” that is available on request from WSIP.
6.1.1.3. Related websites must use the template “shell” that is available on request from WSIP.
6.1.1.4. Associated websites must use the template “shell” that is available on request from WSIP.

6.2. Working with custom user interface design

6.2.1. Build accessible web templates meeting the relevant WCAG checkpoints before populating them with content. For example, ensure that:

6.2.1.1. All elements that can accept focus (e.g. links, form fields, buttons) are keyboard accessible.
6.2.1.2. Focus should follow a logical order.
6.2.1.3. Focus should be clearly visible.
6.2.1.4. Behaves consistently across supported web browsers. Refer to the Usability Evaluation Instruction.

6.2.2. Must ensure valid code in accordance with the RMIT UI development standards (Development standards TBA) and the Accessible UI Development Instruction.

6.3. Vendor-supplied products must meet the Accessibility Standards for Vendor-supplied Resources.

6.4. Validate accessibility

6.4.1. Test design prototypes and include people with disabilities in design walkthroughs and prototype testing. Guidance for recruiting appropriate research participants is outlined in the User-Centred Design Instruction.

6.4.2. Engage an accessibility specialist to review design prototypes using the Web Accessibility Auditing Instruction, which provides an audit process, checklist and report template for the required level of compliance.

6.5. Accessibility statement

6.5.1. Include an accessibility statement on the website that explains any shortfalls and offers practical workarounds for users.


Project Manager


Ongoing

7. Implementation and launch

7.1. Refer to your Web Accessibility Checklist during implementation for quality assurance during implementation and ensure those engaged in implementation or roll-out understand the process.

7.2. Share your Web Accessibility Checklist with WSIP for review and feedback pre-launch. Digital & CX will provide feedback within five working days.


Project Manager

Digital & CX


Ongoing

Maintaining web accessibility

Maintaining web accessibility involves adhering to standards when adding content or revising the site in any way. It also involves keeping abreast of updates to standards. During the maintenance of content, design and coding, record all checkpoint failures in your Web Accessibility Checklist for the website (established during the creation phase).


Content Manager


Ongoing

8. Content

8.1. New content must be created in accordance with section 4 above.

8.2. Revised content must adhere to the standards specified in section 4 above.


Web Manger


Ongoing

9. Design

9.1. Working within the RMIT design system

9.1.1. Design changes must follow the GUI Design Instruction, which meet the WCAG checkpoints relating to visual design.

9.2. Working with custom user interface design

9.2.1. When working on websites that fall outside the GUI Design Instruction and require custom design elements, these must be designed to meet the WCAG checkpoints relating to visual design. Refer to the Web Accessibility Auditing Instruction.


Web Manager


Ongoing

10. Coding

10.1. Working within the RMIT design system

10.1.1. Template changes must follow the standards illustrated in the GUI Design Instruction meet WCAG checkpoints that relate to web development. See section 6.1 above for more information.

10.2. Working with custom user interface design

10.2.1. Template changes must meet the relevant WCAG checkpoints before implementation. The checkpoints are described in the Web Accessibility Auditing Instruction. See section 6.2 above for more information.

10.2.2. Changes to front-end code must validate in accordance with RMIT UI development standards (Development standards TBA).

10.3. Vendor-supplied products must meet the Accessibility Standards for Vendor-supplied Resources. Monitor and record any vendor-driven changes that impact on accessibility. Use the Web Accessibility Checklist.

10.4. Validate accessibility

10.4.1. Test development changes to ensure that standards are maintained. Refer to the Web Accessibility Auditing Instruction.

10.5. Accessibility statement

10.5.1. Update the accessibility statement on the website if required. This statement should explain any shortfalls and offers practical workarounds for users.


Web Editor













UI Developer

Evaluating web accessibility

Periodically websites should be evaluated for compliance to accessibility standards and remediation plans put in place. Use the Web Accessibility Auditing Instruction and record all checkpoint failures in your Web Accessibility Checklist for the website (established during the creation phase). Refer to the Web Accessibility Evaluation Instruction for suggested techniques and tools for measuring accessibility.


Web Manger

11. Content

11.1. Audit the content and record failures, targeting a representative sample of key pages.

12. Design

12.1. Audit the design and record failures, targeting a representative sample of key pages.

13. Coding

13.1. Audit the code and record failures, targeting a representative sample of key pages.

14. Review and feedback

14.1. Share your Web Accessibility Checklist with WSIP for review and feedback. WSIP will provide feedback within five working days (unless the complexity of the request requires this to be extended in consultation with the sender). Depending on the type and scale of the website, WSIP may recommend:

14.1.1. Remedial work (See section 15 below).

14.1.2. Update to the website’s accessibility statement.

14.1.3. Deletion or archive of specific items.


WSIP

15. Remedial work

15.1. Content Owner will be informed of the recommendations.

15.2. Content and technical owners discuss opportunities to implement change.

15.3. Recommendations for non-compliant websites:

15.3.1. All reasonable attempts must be made to create, implement, customise, or source resources and authoring tools that comply with the standards.

15.3.2. Where compliance with standards cannot be achieved during the design and development process, or evaluation of an existing website has revealed non-compliant components, the website will be registered by WSIP for future remedial or redevelopment work, replacement, deletion or archiving.

15.3.3. The appropriate content owner, project manager or web manager is responsible for the remedial or redevelopment work and must submit an accessibility compliance plan to the Senior Manager User Experience outlining:

15.3.3.1. the recommended solution with links to relevant techniques and successful code examples
15.3.3.2. if possible, identification of the complexity of solution (e.g. high, medium, low) to help establish the scope of change.

15.3.4. Where compliance cannot be achieved for web resources, the content owner will provide for accessible alternatives as needed. Where accessible alternatives are needed for students or prospective students, the requirements of the Disability Standards for Education 2005 must be met.

15.3.5. Where compliance can’t be achieved for authoring tools, the commissioning staff member will warn creators of web resources about the limitations of the tools they may be using, and:

15.3.5.1. Provide information about workarounds for various resource elements (e.g. data table mark-up) where these exist,
15.3.5.2. Provide access to alternative solutions, such as seeking assistance from a web specialist.
15.3.5.3. Where workarounds or other solutions aren’t available, the commissioning staff member will provide for accessible alternatives as needed


Web Manager

[Next: Supporting documents and information]