How to Test a UI Component for Accessibility
You should get in the habit of testing UI components for accessibility every time you work on them, and as often as possible when reviewing your colleagues’ work.
Here are the steps I take to manually test components and pages:
- Use the keyboard to TAB through the page. Can you reach, operate, and see every interactive control on the screen? Can you use the arrow keys for compound widgets?
- Note that not everything has to be interactive for screen readers (e.g. headings)!
- Run a browser extension like Axe (opens in a new tab) or Accessibility Insights (opens in a new tab) to surface WCAG violations and best practices. Test the heading structure with the Web Developer (opens in a new tab) toolbar.
- Debug elements using the browser DevTools as well.
- Zoom in to at least 200% to make sure pages reflow without horizontal scrolling. Do any components break when zoomed in?
- Test with a screen reader like VoiceOver or NVDA.
- Check that animation, motion, and autoplaying video can be turned off with controls and Reduced Motion settings.
- Make note of any media in need of captions, transcripts, and other alternative content.
Bake it into the code
In addition to manual testing (which is a must), you should also find ways to test your components with automation. You can’t automate everything, as we’ll discuss in a later section. But you can certainly run a test API like Cypress-Axe (opens in a new tab) and write your own feature tests for keyboard access, ARIA attributes, and more.