I have recently run a seminar on prioritising web accessibility during the build of a web site for both DrupalGov and Joomla Day Sydney. You can download the slides for Prioritising web accessibility in the build of a web site from Prezentt. I have highlighted the main issues I covered in this blog post. For more information, have a look at our Services section on Accessibility testing during the web development lifecycle.
In building an accessible web site, accessibility needs to be considered at various different stages of the Web Development Lifecycle. If you ignore accessibility and only complete an accessibility audit once the site is finished you are more likely to have to significantly rebuild the site.
Choosing the right developers
Choosing a developer with accessibility experience goes a long way towards building an accessible site. Query your developers on their accessibility knowledge and review their previous sites for accessibility compliance.
Review key documents
Many accessibility issues can be addressed upfront in the specification phase. Reviewing documents like functional specifications and web style guides can highlight any accessibility problems long before coding starts.
Design evaluation
A design evaluation is an accessibility audit of the design only. Not only are design issues identified, but it is also an opportunity to find areas that may prove difficult in coding accessibly. These areas can be addressed in training.
WCAG2 success criteria that should be reviewed at the design stage include:
- 1.3.3 Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound (Level A).
- 1.4.1 Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element (Level A).
- 1.4.3 The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (Level AA).
- 2.3.1 Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds (Level A).
- 2.4.4 The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general (Level A).2.4.5 More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process (Level AA).
- 2.4.6 Headings and labels describe topic or purpose (Level AA).
- 3.2.3 Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user (Level AA).
- 3.2.4 Components that have the same functionality within a set of web pages are identified consistently (Level AA).
- 3.3.2 Labels or instructions are provided when content requires user input (Level A).
Training
Training should be conducted for both developers and content authors.
Template evaluation
A template evaluation is an accessibility audit of the template only. This is an opportunity to find errors in the templates before they are deployed across the entire site. It is important that the templates are tested against all success criteria.
Audit
Even if you have addressed accessibility through the Web Development Lifecycle, you still need to complete an audit of the site once it is finished. This will identify any content accessibility errors as well as one-off coding issues.