accessibility-testing

Implementing accessibility correctly is crucial to deliver quality web experiences for everyone, including developers.

Software requirements & programmatic testing

To catch accessibility defects quickly and reliably, employ automated and rule-based accessibility checks. For this, set up a development requirement for the pa11y/pa11y CLI tool and the axe-core runner, and run it against fresh development builds. Also cover individual features and components, isolated from the rest of the page.

Include these checker tools into an existing CI pipeline.

Manual checks

For each component, check each component for its full WCAG 2.2 level AAA conformance, and create a table that contains the number of the success criterion, its name, a short description, and the conformance status (pass, fail, not applicable, untested)

If it helps, you may also make this as a template and re-use it accordingly.

You may use browser based tools (like Playwright) to run checks yourself that traditionally required real users for testing. If you can't make a judgement or it might be un-reliable, note a todo with a clear and concise assessment instruction for a developer.

Generate deliverables

Whenever you have made an accessibility assessment or judgement, produce a short writeup of all documented issues and suggested fixes. Never suggest quick-wins or shorthand fixes if a complete architectural overhaul would be the better and correct choice. This is especially true if the quick fix would involve ARIA patterns.