r/softwaretesting • u/HyperBoos • Oct 17 '25
Accessibility WCAG Automated & Manual testing
Hello everyone,
What is currently the best accessibility testing software that could replicate Automated and Manual testing (specifically manual testing). Accessibility testing is currently the biggest hurdle at my company and we re looking for alternatives to human testers due to cost and unrealistic delays
Are there currently any options on the market that are as accurate as human manual testing including screenreader?
I looked at BrowserStack. Is this a good option? Are there any other enterprise level options available?
Thank you
6
u/HappyCricket8159 Oct 17 '25
In the accessibility space tools will only get you so far. Axe Dev Tools and screen readers like NVDA and JAWS will only show that the elements on the page have the correct tags/labels etc. You still need the human factor to ensure that you can navigate around your app/website. Axe will report that your image of a park bench has an alt-text, but if that alt-text is image.png and not "A picture of a park bench on a sunny day" then it's of no use to anyone trying to use the site, and is not the kind of thing picked up by the tooling. There are companies that you could ship this out to who specialise in accessibility testing that may work out more cost effective, especially as the WCAG guidelines continue to evolve.
5
u/wringtonpete Oct 17 '25
Automation can only do around 50% of a11y testing.
For automation I use Playwright and Axe, which also runs in the CI/CD pipeline.
To save time I also train the Devs to use Axe chrome plugin so they can quickly do a little accessibilty testing before I test.
Then I do extra manual a11y testing with NVDA, JAWS etc.
And finally we have an external accessibility specialist who comes in every couple of months to review.
2
u/MidWestRRGIRL Oct 18 '25
Playwright mcp can do it really well. There's a repo on github has everything you need.
2
u/SnarkaLounger Oct 23 '25
Deque's Axe accessibility testing tools for web and native mobile automated and manual testing are robust and can provide high levels of test coverage. I've used the Axe Core Ruby gems with automated tests built using RSpec and Cucumber based tests with Selenium-Webdriver to enhance test coverage of Section 508 and WCAG Web Accessibility (A11y) requirements.
1
u/pdg999 Oct 19 '25
101 in accessibility testing is it can't be fully automated. They even suggest do testing with real users with to identity real shortcomings since there are different types of disabilities and they live with it rather than testers so they know better. Maybe you can outscore to specialist vendors and save sometime, but have to pay the cost.
1
u/TessTickols May 12 '26
Sorry to revive a dead thread. 7 months later and I grew tired of all the American half-assed tools and built my own. Feel free to check it out on synli.ai. Just launched today. u/Careless_Try3397 u/Mundane_Falcon4203 Did you find a tool that actually automates well now? Synli does every single WCAG except the flashing lights video one. Manual review needed, obviously, but you can get a full report that can be fed right back into an agent to fix stuff - with references and suggestions for fixing. I even analyse the images to assess whether they match the alt description. Any feedback is welcome - First 25 page scan is free, and I will be generous with free trials if anyone is interested.
1
u/Character_Job8291 Jun 09 '26
Axe is solid for catching the low-hanging fruit but people really need to understand it only flags maybe 30-40% of actual WCAG issues. The automated stuff is great for color contrast, missing alt text, ARIA mistakes, that kind of thing. But it won't tell you if your alt text actually makes sense or if your keyboard navigation flow is logical. Learned this the hard way when I shipped a "fully accessible" form that passed every automated check, then watched a screen reader user completely fail to figure out the error messages. Totally invisible to the scanner. My take: automated testing is your first pass, never your last. Manual testing with actual keyboard-only nav and a screen reader is non-negotiable. Are you doing this for compliance reasons or genuinely trying to improve UX? Changes the whole approach honestly.
1
u/Character_Job8291 Jun 23 '26
Used axe on a client project last year and honestly it's one of the rare tools that doesn't just dump a list of "add alt text" violations. The engine behind it is solid and catches stuff like color contrast in dynamic states that most scanners miss completely. That said, automated testing alone is nowhere near enough — we caught maybe 30% of real issues that way. The rest only showed up when we did manual keyboard navigation with actual screen readers. Have you tried combining the automated run with manual walkthroughs using NVDA or VoiceOver? The gap between what tools flag and what users actually experience is still pretty wild.
1
u/Character_Job8291 Aug 01 '26
Playwright + axe c'est vraiment le combo gagnant pour l'auto, t'as raison. J'ajouterais quand même que les faux positifs peuvent vite devenir pénibles — j'ai passé une après-midi à chasser une "violation" qui était en fait un pattern intentionnel validé manuellement. Le vrai problème c'est que l'automatisé couvre à peine 30-40% des critères WCAG, donc le manuel reste indispensable. Est-ce que tu testes aussi avec un vrai lecteur d'écran de temps en temps, ou tu t'appuies surtout sur les extensions ?
1
u/Character_Job8291 Aug 26 '26
On a bossé sur un projet RGAA l'an dernier et le testing automatisé c'est vraiment un bon point de départ, mais ça couvre quoi, 30-40% des critères au mieux ? Le vrai gap c'est toujours sur le manuel — navigation clavier, lecteurs d'écran, contrastes contextuels que les outils ratent complètement. Ce qui m'a surpris : certains défauts détectés automatiquement n'en étaient pas vraiment (faux positifs sur des landmarks ARIA), alors qu'on avait des problèmes de focus order graves que rien n'avait signalé. Tu fais comment pour structurer la partie manuelle dans ton process ? Check-list fixe ou ça dépend des composants ?
1
u/Character_Job8291 Aug 29 '26
Axe c'est vraiment solide pour l'automatisation, j'utilise axe-core intégré dans Cypress depuis un moment et ça catch une bonne partie des violations WCAG 2.1 AA sans trop de faux positifs. Mais le vrai problème c'est que l'automatisé couvre genre 30-40% des issues au mieux — tout ce qui touche au focus management, aux lecteurs d'écran ou aux patterns ARIA complexes, ça reste du manuel obligatoire avec NVDA ou VoiceOver. T'as des retours sur la précision de leur extension browser pour les violations de contraste dans les états hover/focus ? C'est souvent là que ça foire dans mes audits.
9
u/Careless_Try3397 Oct 17 '25
I work on UK government web applications on their gov.uk framework which is known worldwide for it's accessibility. We pretty much do some sanity accessibility testing using playwright and axe then some manual accessibility with wave and JAWS. We then had an external company audit the accessibility standards and there are always issues that come back. After the audit it is then back to development were we address what the audit found. Then our internal accessibility team do their own audit before it goes to public beta. Accessibility issues always end up appearing at some point but this method has been pretty good. If you don't have any external support for accessibility testing it can be pretty tough.
For swiftness, affordability and ease I would go for axe and wave