Whether you want to become an accessibility tester yourself or need to build an accessibility team, you need to learn a few capabilities. Below is a list of important considerations when it comes to accessibility testing. Please note that this not an all-inclusive list of everything you will need to know, but it is a good starting point.
1. Compliance Standard Knowledge
There are many standards to wrap your head around but understanding the various standards and being able to spot pass and failure examples of each is essential for proper accessibility testing. Depending on your location, the standards may be slightly different, but they all revolve around similar concepts.
- WCAG 2.1 – A wide range of recommendations for making web content more accessible, authored by W3C
- EN 301 549 – Accessibility requirements suitable for public procurement of ICT products and services in Europe.
- Section 508 – Standards that apply to electronic and information technology procured by the federal government.
2. Accessibility Certifications
- IAAP CPACC or WAS Certification Preparation Course:
- Price: $45 or $150
- Summary: Preparation courses for the IAAP Certification
- IAAP Certification (CPACC or WAS)
- Price: $425 – $475 for certification
- Summary: this certification aims to better define what accessibility professionals are expected to know and increase quality and consistency of work performed by accessibility professionals. Recommended for web accessibility testers that need to adhere to WCAG 2.1
- DHS Trusted Tester
- Price: Free
- TT provides a code-inspection based test approach for determining software and website conformance to the Section 508 standards. Required for accessibility testing government software.
3. Assistive Technology (AT)
Due to varying disabilities, personal preference, and access to resources, there are many different types of assistive technologies that testers will need to use and should be familiar with.
Below are a few of the most popular screen readers:
- NVDA – A very popular, free, open source screen reader.
- JAWS – The industry standard screen reader with varying pricing options.
- VoiceOver (iOS/Mac) – Default screen reader on iOS/OSX.
- TalkBack (Android) – Default screen reader on Android devices.
- Narrator – Default screen reader on Windows OS.
Some users choose to utilize OS or browser settings to increase UI text font size. Other users employ applications such as Windows Magnifier which simulates a real-world magnifying glass to enlarge UI content to improve the visual experience.
Windows high contrast settings are built into the OS. Other devices will have their own high contrast options and some browsers utilize extensions (such as Chrome high contrast) in order to allow for users to see content.
Voice input allows users to navigate across the various features on a user interface using a microphone and voice commands as an alternative to a mouse or keyboard. Dragon NS is an example of Voice Input AT tool. Other common voice input options are Cortana, Siri, “OK Google”, and Alexa.
Other AT Tools include (but are not limited to):
- Switches – Allow users to navigate and select by pressing buttons.
- Sip and Puff – Allows users to navigate and control via their mouth.
- Refreshable Braille Displays – Used to read content via Braille.
If accessibility is properly implemented into a product, the above AT will function for users.
4. Testing Tools
When testing for accessibility, several manual and automation tools are available to identify issues, determine specific causes, and even provide product owners with information on how to fix accessibility standard violations.
- aXe – Browser extension that analyzes pages for accessibility and buckets the violations. Very user friendly.
- WAVE Evaluation Tool – Input URL and run automation to find accessibility errors and have them shown on the analyzed webpage with notes/suggestions.
- Nu HTML checker – Provides a compiled list of errors found on an analyzed website. Less visual but shows you offending HTML.
- Web Accessibility Toolbar – Toolbar for IE that allows users to check programmatic structure and determine if a webpage is accessible.
- Colour Contrast Analyser – Allows users to select or input colors to determine if they meet accessibility requirements between the foreground and background.
- Inspect – Part of the Windows SDK, Inspect allows users to gather programmatic information from software and HTML elements such as the name, role, and value.
Use whatever tools best suit the platform you are testing and become proficient in them to better optimize results and output.
5. HTML/CSS/ARIA Knowledge
Becoming familiar with various languages and syntax is a valuable aspect of accessibility testing and remediation. While testers do not need to be proficient in HTML, CSS, or ARIA, to truly be an effective tester, it is very beneficial to know how websites work and be able to speak to not only why an issue is occurring but providing valuable input on how to resolve it.
The ability to look at the DOM (Document Object Model) and determine if an element, tag, or attribute is coded correctly is one of many aspects of accessibility web testing. Knowing whether Alt= is a valid attribute for <a> tags, being familiar with properly closing out tags, being familiar with various roles that could be utilized by developers, among other HTML knowledge will not only allow you to tell product owners that an element is not compliant, but also inform them how they can fix their code.
To take it a step further, ARIA (which stands for Accessible Rich Internet Applications) goes beyond basic HTML but is used purely to make HTML more accessible. Caution: Improper usage can lead to a less accessible product than using native elements, so it is crucial to understand ARIA if it is being suggested as a resolution to accessibility violations.
CSS (Cascading Style Sheets) is used to describe how HTML elements are displayed to users. Screen readers will ignore this styling but improper usage can lead to accessibility issues such as focus visibility (WCAG documentation), focus order (WCAG documentation), contrast minimum (WCAG documentation), and other accessibility violations. Having an idea of what could cause these issues can better help product owner fix their accessibility bugs but generally won’t be applicable to accessibility testing.
6. Test Matrix
There are a wide variety of web browsers/products available through which web interfaces can be explored and utilized. Each browser/product has multiple versions in wide use. Since it may not always be practical to test all available browsers or products and versions, test plans should include the highest priority browsers/versions based on the platform, operating system, and type of accessibility testing to be conducted.
Clearly mobile devices offer different experiences compared with say, a desktop computer. Likewise, different operating systems don’t necessarily behave the same nor run the same software. As with any software testing, accessibility testing too needs to establish the platform, operating system, and version combinations upon which tests will be executed. These combinations dictate what browser, product, AT, tools, and other software can be incorporated into the accessibility testing.
It is also important to note that certain products/assistive technologies have better compatibility and support so just because a browser and AT exists, does not mean they should be tested together. The following table illustrates the most common AT/browser combinations.
|Browser/OS||Primary Screen Reader||Secondary Screen Reader|
|Microsoft Edge||Narrator (ver. 1803 or higher)||JAWS (ver. 2018.18 or higher) or NVDA (ver. Jan 1st 2018 or higher)|
|Google Chrome||NVDA (ver. Jan 1st 2018 or higher)||JAWS (ver. 2018.18 or higher)|
|Internet Explorer 11||JAWS (ver. 18 or higher)||NVDA (ver. Jan 1st 2018 or higher)|
|Safari (OS-X)||Voiceover (OS-X)||N/A|
|Android||Talkback||Voice Assistant (Samsung)|
- Utilize only keyboard controls while (no mouse allowed!)
- Blindfold/turn off your monitor and use a screen reader
- Frosted glasses
- Use the Windows high contrast settings
While there may be many additional facets involved in accessibility testing, understanding the compliance standards, knowing the ins and outs of various assistive technology, becoming familiar with testing tools, being able to speak to issues in the HTML, and becoming more empathetic to those with disabilities, will leave you with the knowledge necessary to become a good accessibility tester.
Finally, as you continue to gain experience and grow, so will your skillset and knowledge of accessibility making you all the more valuable and impactful in the accessibility community.
Posted 11 January 2019. All content referenced outside of this article was verified to be present and working at the time this article was published. If you find a link which is no longer working, please contact us.