Use checklists
Checklists can be helpful for teams. They are usually insufficient to move an organization beyond a limited compliance mindset. There is no single checklist that covers all WCAG issues. As Intopia warned, a checklist mentality can actually be harmful for inclusion. That said, if approached as part of a broader strategy, they can be very helpful. We recommend that teams might want to customize one to better meet their needs. Access Armada has some interesting suggestions on more strategic approaches to checklists. Ultimately though, regularly reviewing your checklists is important. They can be a powerful tool for teams to keep learning how to create more inclusive content.
Microsoft's Accessibility Insights has both a FastPass and Assessment component. The Assessment component guides users through doing a manual review. Using this tool, organizations could:
- Run the FastPass's automated axe checks on every page.
- Check that the Tab stops follow a logical order when navigating with a keyboard.
- Look over the elements that are marked Needs reviews to see if there are elements where a manual review can identify whether it is an issue or not.
- Complete the rest of the assessment to ensure that the page meets WCAG requirements.
This is a time consuming process, but would give the reviewer a high level of confidence that the site has good accessibility.
One could also look to use a tool like WebAim's WAVE, ANDI, or Tota11y to scan a web page for errors. In which case a reviewer could do something like this:
- Scan the page with the WAVE Toolbar:
- Look for clear errors (red boxes with an X in them).
- See if the alt text effectively describes the images on the page.
- Ensure that there is sufficient color contrast.
- Do keyboard only testing (using just tab, shift-tab, arrow keys & escape) to navigate the page.
- Evaluate page for plain language using free tools like the HemingwayApp.
- Magnify the page up to 200% and look for usability and readability issues.
There are lots of checklists, rotating through a few of them will help give different people different things to think about accessibility:
- W3C's Web Accessibility Initiative (WAI)
- 18F - USA Government
- UK's Government Digital Services (GDS)
- WebAim
- Elsevier's WCAG 2.1 Checklist
- A11yProject
- Heydon Works
- VoxMedia
- PSU
- Yale
- University of Washington
- tmobile's A11yEngineer
- dev.to's Web Accessibility Cheat Sheet
- The Book on Accessibility
- Intopia's Accessibility Not-Checklist
Checklist Anchor link
- Have a checklist that builds on automated testing approaches.
- Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.
- Change your checklists so that new elements can be improved.
- Ensure checklists are short and concise enough that they are used.
Key questions Anchor link
- Are you making good use of the time and attention of your staff?
- Are the checklists boring, or supporting your team?