We could check each component variant’s accessibility, which is hard to do using the actual site or app. However, we could have quick feedback when we develop new components in isolation.
Accessibility screen reader testing tools code#
This is more powerful than static code analysis, like ESLint, because it can find more problems, like checking if the text has sufficient color contrast.įor React Styleguidist, we could add react-axe manually:īoth don’t check things like the document outline or landmark regions, which would require rendering a complete page. Axe-coreĪxe-core is a library that checks the accessibility of the rendered HTML in the browser. However, we’re likely already using ESLint on a project, so the cost of having this plugin is minimal, and occasionally it finds issues before we even look at our site or app in the browser. it only works with plain HTML elements but doesn’t know anything about our custom components.static analysis of the code could only find few problems.Unfortunately, this plugin is somewhat limited: The linter is a perfect tool for that because it gives us immediate feedback when I’m writing code, right in the editor.įor React projects, eslint-plugin-jsx-a11y checks many accessibility issues, like missing alternative text on images or incorrect ARIA attributes and roles. I like it when someone tells me when I’m doing something wrong as soon as possible without asking myself. We’ll talk about each tool and technique in more detail in the rest of the article. This won’t make your site or app fully accessible but it’s a good first step in that direction. Tab through the site or app with a keyboard to test keyboard navigation and focus states.Run FastPass in the Accessibility Insights browser extension to find two most common accessibility issues, and fix them.