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.
The following list is a small portion of accessibility standards but will get you started on your journey to understanding accessibility standards. If you’re in the US and not a government employee, I recommend WCAG 2.1.
- 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
While gaining an accessibility certification is not necessary to become or consider yourself an accessibility tester, it will allow you to have a robust knowledge of various testing processes, strategies, and further engrain the compliance standards into your testing. Below are two very common and thorough certifications along with one prep course.
- 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.
Screen readers
Screen readers are generally used by users with visual impairments to experience content on computers or mobile devices. Screen readers provide an auditory description of the elements and text displayed on a User Interface. Each screen reader relays information slightly differently, have various features, and other nuances that allow users to make an informed decision on which to use.
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.
Magnification
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.
High contrast
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
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.
Automation
Automation allows you to quickly determine if low hanging accessibility violations exist within the product. Below are a few examples of automation tools although many exist, and some companies have internal testing tools as well:
- 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.
Manual
The majority of accessibility testing still requires manual effort. This can vary from verifying proper alt text on images, determining if link text is sufficient, verifying that color is not the only means of conveying information, checking non-text contrast, and so on. The following list are some options to utilize while testing for accessibility that can help you in your manual testing.
- 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.
Basic HTML
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.
ARIA
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
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 |
| iOS | Voiceover | N/A |
| Android | Talkback | Voice Assistant (Samsung) |
7. Empathy
Arguably the most important aspect of accessibility testing is empathy. The ultimate goal of accessibility testing is to allow users to experience content or products regardless of ability. Make sure when finding and logging bugs that you always keep in mind the end users impacted by this poor experience. Below are some resources or activities you can attempt in order to put yourself in shoes other than your own.
- 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
Still not feeling empathetic? Watch any of the following videos and if you don’t truly want the world to be more accessible for the individuals. Maybe it’s best to stick with your standard QA testing role.
Closing
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.
