Tools for accessibility testing
I shared my experience with accessibility testing
When I read the book Full Stack Testing: A Practical Guide for Delivering High Quality Software, it was the first time that I thought how difficult it is for people with disabilities (for example, blind people or people with arthritis) to do things as simple as watching videos on the internet. The WHO estimates that 1.3 billion people – about 16% of the global population have some significant disability.
Some tools, like screen readers, eye tracking, and braille keyboards, help. The following video shows how some pages and tools help disabled people.
What is accessibility testing?
It is a type of software testing that ensures the website's design is accessible to all people despite visual, hearing, mobility, and cognitive impairments.
You can follow some guidelines to help make your websites more accessible. One of the most common is WCAG. That offers a checklist and guidelines to make your site accessible to everyone. And focus on 4 areas:
Perceivable: All users with disabilities (sight, hearing, motor) can interact with your site.
Add captions to the videos for deaf or hard-of-hearing users.
Transcripts for audio files for deaf or hard-of-hearing users.
Alternative text to describe images for visually impaired users. Decorative images don’t need alternative text.
Operable: Users can navigate your site with different devices, not only a mouse or keyboard.
Access all elements with the keyboard.
Add focus visible to the focused element.
Give users enough time to read your content.
Provide a simple point alternative for complex mobile gestures like drag and drop or zooming. For example, you can use a click to zoom out instead of pinching out.
Understandable: All the info should be easy to understand.
Include the language of the page.
Don’t perform any action on focus an element like submit a form or launch a new window.
Add clear error messages. For example, don’t rely only on color, like the font's red color. You can add an error icon and a border to the element with the error.
Robust: Content can be accessed with different devices and user agents.
It can be accessed via mobile phones, tablets, laptops, etc., without losing content.
Good color contrast.
Good font-size.
Reflow your design with zoom at 200%.
Assistive technology users are aware of new status messages added to the page.
You can check a visual Summary of the WCAG checklist. With practice and focusing on how disabled people can use your website or app, you can create a better website.
Unfortunately, there are no official guidelines like the WCAG for mobile testing, but you can follow the same WCAG guidelines.
Why is it important?
Making your site accessible is the law in some countries and will be required in the EU (European Union) on 28 June 2025. Some companies, like Nike, Walmart, Amazon, and Netflix, were sued because their websites were inaccessible to disabled people. Companies can be fined up to $75,000 for a single ADA violation.
Software helps people, so designing websites for all users is crucial to helping disabled people. It improves the SEO and makes your site clear for everyone.
You can watch the following video that explains 5 stats about disability
How to make your site compliant?
It’s important to include accessibility in all areas of your software lifecycle and train or hire companies to audit your website.
You must manually validate your site with automated tools. Automated tests cannot find all the issues, but they can help find some. It would help if you considered disabled people more than passing the checklist.
It is important to include QA-disabled testers and pay the same salary as normal QA. Disabled people have lower salaries than people without disabilities.
Use tools to generate your video captions, subtitles, and transcripts. For example, when you upload a video to YouTube, you can generate the captions and transcripts of your videos. Although you manually need to review the AI tool, it helps.
You can use third-party components that include accessibility like angular material, kendo UI, and Devextreme for angular.
Tools for accesibility
Screen readers
A screen reader is software that reads all the information on your computer or cellphone. You can use different screen readers, the most popular of which are JAWS, NVDA, and VoiceOver on Apple products.
You must be patient with the screen reader, as its voice usually sounds like a robot and reads everything on your screen.
It reads differently for Edge, Chrome, and Firefox, so sometimes, getting the same behavior in all browsers is a bit complex.
Browser Extensions
Accessibility insights: This can help you initially because it includes guidelines for manual and some automated tests.
Automated test with the option to copy failure details 
Quick guides Silktide: It includes exciting options like a screen reader in beta mode, some simulator modes, and a tab order that is not always visible on all sites.
Options and simulator modes available 
Focus order when it is not visible Axe Deque: Inside developer’s tools include some advanced options like guided tests and sharing the test results in the paid version (for $45 per month, or $500 per year)
Axe deque issues dashboard Wave: Includes options highlighting elements and shows the code with the error.
Sometimes, the different extensions found different errors.
I use the accessible colors to give me some suggestions to fix the color contrast errors.
Automated tools
You can include some options to integrate into your regression test:
ESLint rules: You can include some ESlint rules in your CI pipeline that can detect some accessibility issues.
Axe-core: Add accessibility validations for end-to-end tests that are available for all common frameworks.
Lighthouse: Google evaluates a page from different aspects, such as performance, accessibility, best practices, and SEO.
Webhint: A VS Code extension that suggests best practices for HTML and accessibility.
My playwright tool
Because I only found a few tools last year, I added accessibility testing with Playwright and Axe Deque and included them in the regression testing. The framework has the following options:
Dashboard with the summary of the bugs
Summary of the issues:
Page
By Accessibility rule error.
Video with all errors found
POC of tab order on the page
POC with a summary of all aria-label
New tools
This year, I saw some pre-release accessibility testing with
Cypress: Uses axe-deque. I requested early access, but I didn’t receive any answer. However, the demo in the Cypress Conf looks good.
One interesting tool for cypress is wick-ally. You can add with the command:npm install wick-a11y --save-devIt will add some borders to the elements with the error and an HTML report
HTML Report
BrowserStack: Uses WebAIM, which offers 3 months of free access but has a lot of issues:
False overlap elements
Can’t check contrast with gradient colors
Very slow detects around 3,300 errors in a page with few accessibility issues.
Inexistent support, I send an email with the issues to some person in the support in the chat, without any answer, ticket the same no answer.
The Chrome extension is only available below the browser, not on the sides.
Lambdatest: It includes a screen reader and looks like the same WebAIM tool, but here, it works better with an option to classify issues like contrast color.
GitHub Copilot Chat: You can request GitHub Copilot Chat to help you write and review your code for accessibility. It can suggest fixes or tips. If you are using an accessible third-party component, it can suggest some false positives because the final code includes the code that was suggested.
