Usability & Web Accessibility – Testing Procedures
Posted by Yale University | Date Accessed: August 17, 2022
Accessibility testing can range from quick checks to full audits, depending on a site owner’s needs. The process will look different for a developer building a project than for a site owner maintaining a live site.
Checklists are a necessary and helpful part of any accessibility testing process. The best checklists translate WCAG criteria into understandable language. Checklists may also be role-specific, focusing on editors, designers, or developers. Though checklists are not a perfect substitute for understanding WCAG guidelines, they are nevertheless invaluable. Yale recommends the following checklists:
- Yale’s Checklist for Content Editors(link is external)
- Web Accessibility Initiative’s Easy Checks First(link is external)
- Yale’s simplified, filterable WCAG Guidelines
- WebAIM’s WCAG 2 Checklist(link is external)
- W3C’s Filterable WCAG Criteria by Role(link is external)
Using automated tools is best viewed as a helpful step in an accessibility process. Automated tools detect less than half of accessibility issues on a page. They can also generate false positives or raise warnings that need interpretation. Hence, they are insufficient for confirming accessibility. Still, they are a valuable tool in a developer’s workflow. Automated scanners include:
- WAVE (Chrome or Firefox extensions)(link is external)
- Axe (Firefox extension)(link is external)
- Axe (Chrome extension)(link is external)
- Siteimprove (Chrome or Firefox extensions)(link is external)
- Lighthouse (Chrome)(link is external)
- HTML Codesniffer (bookmarklet)(link is external)
- Microsoft’s Accessibility Insights (Chrome or Edge extensions)(link is external)
Color Contrast Checkers
- WebAIM Color Contrast Checker(link is external)
- WebAIM Link Color Contrast Checker(link is external)
Keyboard Only Testing
Many users with disabilities will not be able to use a mouse. Hence, developers must ensure that all content on a page is operable with a keyboard. In most browsers, use the Tab key to ensure that all functionality receives visible focus and responds to common key presses (Enter, Space). Default focus styling may be inadequate for some designs, or may be removed by CSS resets. Custom widgets may not be keyboard operable without considerable scripting effort. Testing with a keyboard throughout development will catch these issues.
Assistive Technology Testing
Applications should be tested with assistive technology. Ideally, a user who uses the assistive technology would perform this testing. But, developers can learn the basic operations of screen readers well enough for their own testing during development. Major screen readers include VoiceOver (default on Mac), NVDA (free to download on Windows), and JAWS (available for purchase on Windows).
About This Article:
A Life Worth Living has copied the content of this article under fair use in order to preserve as a post in our resource library for preservation in accessible format. Explicit permission pending.
Link to Original Article: https://usability.yale.edu/web-accessibility/articles/testing-procedures