There are a lot of tools and techniques for accessibility testing. This page contains a list of some of the tools I've been using while doing accessibility audits.
Browsers and tools can detect color contrast quite well. I've noticed that some tools don't recognize dark and light modes that are built with Tailwind. If that happens, test the contrast manually.
Chrome has a tool for emulating vision deficiencies. Open DevTools, select More tools, then Rendering. At the bottom, there is a dropdown with options for some vision deficiencies.
Note that simulation doesn't accurately show what people are seeing. But it can give you some perspective.
If you go to System Settings > Accessibility > Display, you can find Colour Filters. There is a Filter type setting that allows you to simulate vision deficiencies.
CSS media feature prefers-color-scheme listens to the settings on a user's operating system.
The last time I checked, you can find the settings like this: Settings > Personalization > Colors > Choose your color.
If you have chosen custom, then the setting the prefers-color-scheme listens to is Choose your default app mode.
Go to System Settings > Appearance. You can choose between light, dark and auto.
While this isn't required by AA-level requirements, I recommend checking for these if the site has animations or auto-playing content.
The CSS media feature prefers-reduced-motion listens to the settings on a user's operating system.
Go to Settings > Ease of Access > Display > Show animations in Windows.
System Settings > Accessibility > Display > Reduce motion
This section also has a setting to dim flashing lights, which might be useful to you.
While automated tools can detect, for example, ARIA mistakes, I recommend you always do manual screen reader testing.
There are multiple screen readers available for Windows:
For Apple devices:
For Android:
Some tools can check tabbing logic, but they might not be able to catch possible issues accessing some of the elements.
On Firefox you have a setting to zoom either the page or just the text. Both are zoomed with cmd/ctrl and +/-.
On Safari you use cmd and +/- for regular zoom. When you add the option key to the combination, you can zoom text only. Note that on Safari you can actually use both zooming options.
I've recently learned about the Hemingway Editor. With it, you can get an assessment of the readability grade of your content.
Some automated tools might report on content-related quality, but I haven't seen it work for any other language than English.
Chrome has a tab for Lighthouse. The tool generates a report of multiple categories, one of which is accessibility.
Firefox and Chrome both include built-in tools to inspect the element's accessibility properties, including name and description. Chrome Developer Tools will also show the hierarchy of the accessible name computation for a specific element. This tool can help you test for criterion 2.5.3.
HTML_Codesniffer bookmarklet is a quite nice tool. It lists the errors and warnings of a page for WCAG criteria. It provides you with details of the errors along with the problematic code snippet.
WAVE (Web Accessibility Evaluation Tool) can be used on the website and it is also available as an extension for Chrome and Firefox.
The W3C Markup Validation Service can be used by giving it a page address or you can upload a file or use direct input. As a result, you will receive a list of errors and warnings as well as the reasons for each one and the row of the problematic code. This tool is more useful to developers because developers can interpret the results. The tool isn't perfect, but it picks up most errors.
Text spacing bookmarklet helps you test for criterion 1.4.12.
UK Government Digital Service team has recently published their internal guide on how to test for each specific WCAG criteria (level AA).
I created a testing site for a workshop. Feel free to use it to test some accessibility issues. The site also has some accessibility information added to each section.