Integrated Accessibility
Reducing the cost and improving the efficacy of accessibility delivery by taking an integrated approach.
Overview
The quality of the product we deliver is everyone's responsibility.
This principle guides and explains the concept of integrated accessibility testing; no single person or team can add missing accessibility into a product that was designed, authored, and built to be inaccessible.
The more effective approach is to delegate each role in the process to be responsible for the accessibility concerns that they have control over.
An applied example of this philosophy is the Gov.UK website:
"We just wanted GOV.UK to be as accessible as possible, which is why inclusive design is one of our design principles. It's also the reason why we consider accessibility to be everyone's responsibility, why we follow accessibility guidelines, and why we test everything we do with older and disabled people." [1]
Areas of responsibility
Below is an example of how to integrate four areas of accessibility responsibility into each different team based on areas of expertise.
Implementation Checks
These checks are made on the code that implements a feature. These seek to identify barriers in the markup, scripting or styling code, or other implementation-specific resources. Such checks are most likely to be the domain of Software Developers. Many, but not all, of these checks may be automated and can be included in the existing functional and non-functional testing that is already conducted at this stage of the product cycle.
Examples
- Does the implementation validate against relevant standards?
- Does the implementation conform to relevant legal and organisational requirements and regulations for accessibility?
- Is the implementation compatible with all supported assistive software and devices?
- Is the implementation compatible with its core purpose on client software that is functionally limited or restricted?
Usability Checks
These checks seek to reveal barriers relating to the operation of and interaction with the web component. These checks challenge assumptions about which devices and interactions users employ to operate web components. This testing is likely to be the domain of UX Designers. Some of these checks, but not all, may be automated.
Examples
- Can the feature be operated efficiently by the supported range of assistive software and devices, such as by keyboard or voice control?
- Can disabled users complete typical tasks efficiently, on par with users who are not disabled?
- Can users identify and correct errors easily, regardless of the use of assistive software or devices?
- Does the feature remain usable for its core purpose even when the client software or hardware is functionally limited or restricted in typical ways?
- Is keyboard focus controlled appropriately so that a user navigating by keyboard does not get lost or trapped?
Interface Checks
These checks are traditionally concerned with a user's experience of the visual elements in an interface but, crucially for accessibility, it should also consider the interface as experienced by users who may be unable to see it at all, who are partially sighted, have limited sight in terms of contrast or colour perception, or who use magnifiers or filters to augment their vision. Other interface elements such as sound or animation are considered against the supported range of possible user abilities. These checks are likely to be the domain of UI Designers. Some of these checks may be automated, such as measuring relative contrast and checking for the presence of alternative content formats on visual elements. User testing with people having a range of disabilities will also be useful.
Examples
- Are the interface elements appropriately easy to identify, recognise and learn regardless of the use of assistive software or devices?
- Are critical web features such as links, buttons, headings, forms, and lists presented in a way that can be identified as such by their appearance or when using a screen reader?
- Do elements identified by colour provide alternative ways of perceiving their meaning?
- Has the user journey been deliberately considered and designed to be satisfying and effective for users with each of the supported types of disability?
- Can users easily determine where they have navigated to and how they can navigate away or back at any time?
- Do elements that automatically change over time allow the user to control the interaction at their own pace?
- Are elements that flash or have looping animations limited or controllable to prevent distractions or photosensitive epilepsy symptoms?
- Is it possible for users who navigate by keyboard to easily identify which element currently has focus, and to easily predict where focus will go next?
- Is a visible label present for all interactive elements so that it is obvious what such elements are for and what they are called?
- Do adjacent elements have enough contrast to be recognised by users with low contrast or colour perception?
Content Checks
Barriers that come from content production are primarily avoided by skillful copywriting and editing. Having well-considered standards and style guides for writers and visual content producers is vital. Additionally, in the case of web pages, content management systems add another layer in which accessibility barriers must be monitored. These checks are likely to be the domain of information architects, copywriters, editors, and CMS operators. Some of these may be automated, for example by using software to measure the complexity of sentences or vocabulary level.
Examples
- Is the content logically ordered and organised in a way such that it can be easily scanned and navigated?
- Is the page title descriptive of the content specific to this page?
- Is the language used on the page defined in the page metadata?
- Is the wording, icons, and imagery clear and easily understood for users with each of the supported types of disability and by people of varying class, education, and cultural backgrounds?
- Is the arrangement and grouping of words, sentences, and paragraphs conducive to ease of reading and understanding?
- Are the words or images used inclusive such that they don't unnecessarily exclude, stereotype, or disparage disabled people?
- Is the information available to more than one mode of perception, and each having comparable meaning in the context of the overall article or page?
- Considering the different ways content may be extracted and selectively presented by assistive technologies, will each element still be easily understandable in that context?
Automation Tools
"Even if they do detect a barrier, sometimes the results they give will be inconclusive or require further investigation. Or even just wrong." [2]
There are many tools available which can help with accessibility checks. These can reduce the burden of running checks by quickly flagging certain types of accessibility problems, but no automated tool can detect every type of barrier.
This fact was demonstrated when a study by the Gov.UK Digital Service found that automated tools only identified about 20 to 40 percent of errors in their test case. Even vendors of automated tools point out that these tools can only be expected to identify fewer than six out of ten accessibility issues. And Gov.UK found that for certain types of errors, about 30% of the errors they tested against, every automated tool they tried failed to identify the barrier.
Using automated tools can be a good way to augment your overall testing strategy, but it can not be a substitute for manual testing. Define your strategy for conducting regular accessibility checks to include automated tools where appropriate, but also ensure that each team is trained and supported to carry out necessary manual checks as well.