Web accessibility auditing instruction

Instruction statement

This instruction sets out the auditing responsibilities of web project teams to ensure RMIT web resources meet legislative requirements.

Exclusions

This instruction 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.

Instruction steps and actions

Instruction (including key points)

Responsibility

Timeline

RMIT standards

Web authoring tools

Web authoring tools are web and software applications used for creating and managing web content. These include:

  • Desktop web authoring tools (e.g. Dreamweaver)
  • Tools that enable conversion to web format (e.g. MS Word)

The University will develop, provide and support authoring tools that aim to meet all appropriate and achievable checkpoints from Authoring Tool Accessibility Guidelines 2.0, W3C World Wide Web Consortium Candidate Recommendation 7 November 2013, Level A and Level AA Success Criteria

NA

Web content

Web content includes web pages, websites, web and other online applications including Rich Internet Applications and multimedia for which RMIT is legally responsible under the Disability Discrimination Act, 1992.

All content on RMIT websites must aim to conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation 11 December 2008, Level A and Level AA Success Criteria plus Success Criteria 1.4.8-9, 2.4.9-10, 3.1.3-6

NA

When to conduct audits

Primary websites

Content Owners

Twice annually

Schools and business units

Content Owners

Annually

University-wide

Digital and Customer Experience Strategy

Annually

During internal design/development projects:

  • To evaluate existing versions of resources (benchmarking)
  • To evaluate the new design

Project managers

Analysis phase

Test/evaluation phase

When purchasing web resources and authoring tools:

  • New purchases
  • Renewals and upgrades

Procurement

Auditing approaches

Conduct a preliminary review to quickly determine if there are any accessibility problems. This can be useful during development to resolve basic issues early and adjust development approaches. Refer to Web Accessibility Evaluation Instruction.

Project managers

Design phase

Perform a full conformance evaluation to check whether a website meets accessibility standards. This can be done:

  • before redesign of an existing site for benchmarking purposes
  • during development and testing of new websites before they are launched
  • for ongoing monitoring of existing websites, and
  • to validate conformance claims by external suppliers

Refer to Web Accessibility Evaluation Instruction and Commissioning Accessible Vendor-supplied Resources Instruction.

Content Owners

Analysis phase

Test/evaluation phase

Procurement

Expertise required for auditing

Evaluations must be performed by individuals who have sufficient expertise in accessibility. Refer to Recruiting for Web Accessibility Skills.

Reviewers with intermediate to advanced knowledge of:

  • web markup languages such as HTML, CSS, WAI-ARIA and JavaScript
  • WCAG 2.0
  • accessible web design
  • assistive technologies and evaluation tools
  • web browsers with DOM inspection tools, and
  • how people with different disabilities use the web

need to apply their judgement as to whether a web resource conforms to accessibility success criteria.

Where possible, two or more reviewers should be involved in an audit. This will ensure that the greatest number of accessibility issues can be identified and resolved before the usability of the website is tested with users with disabilities.

Accessibility compliance does not guarantee that a website is usable for the widest possible audience. Project teams should refer to Usability Testing Instructions and involve users with disabilities in testing.

Project managers or equivalent

NA

[Next: Supporting documents and information]