Practice : Accessibility Testing

Purpose and Strategic Importance

Accessibility Testing ensures that digital products are usable by people with a wide range of abilities and disabilities, including those using assistive technologies. It’s a key practice for inclusive design, legal compliance, and delivering equitable user experiences.

Beyond compliance, accessibility is a marker of quality - good for users, good for business, and good for brand reputation. It’s essential in creating software that serves everyone, regardless of ability.

Description of the Practice

  • Accessibility tests validate conformance with standards like WCAG 2.1, ADA, or EN 301 549.
  • Tests evaluate things like contrast ratio, keyboard navigation, screen reader compatibility, semantic HTML, and ARIA roles.
  • Tools include Axe, Lighthouse, Pa11y, WAVE, and NVDA or VoiceOver screen readers.
  • Automated checks are combined with manual review and user feedback for full coverage.
  • Accessibility testing is done early and often - not just as a pre-launch task.

How to Practise It (Playbook)

1. Getting Started

  • Integrate accessibility linters or checkers into your development and CI workflows.
  • Run tools like Axe or Lighthouse to identify basic issues (e.g. missing alt text, poor contrast).
  • Use screen readers and keyboard-only navigation to test key journeys manually.
  • Educate teams on accessibility principles and why they matter.

2. Scaling and Maturing

  • Establish accessibility acceptance criteria in user stories and design specs.
  • Create reusable components that enforce accessibility best practices by default.
  • Include users with disabilities in testing and usability sessions.
  • Monitor for regressions using automated tools on staging and production builds.
  • Report and track accessibility issues with the same rigour as functional bugs.

3. Team Behaviours to Encourage

  • Treat accessibility as part of Definition of Done - not an afterthought.
  • Collaborate with designers and content writers to ensure inclusive UX.
  • Review accessibility as part of design reviews, code reviews, and retrospectives.
  • Celebrate fixes that improve access and usability for all users.

4. Watch Out For…

  • Over-relying on automation - it can’t catch everything.
  • Accessibility efforts siloed to a single person or phase.
  • Ignoring legal and ethical responsibilities to deliver inclusive products.
  • Fixing symptoms (e.g. adding ARIA roles) without addressing root issues (e.g. semantic HTML).

5. Signals of Success

  • Users of all abilities can successfully use your product.
  • Accessibility regressions are rare and resolved quickly.
  • Teams have the knowledge, tooling, and support to build accessibly by default.
  • Accessibility is discussed regularly - not just when something breaks.
  • Your product meets or exceeds WCAG AA or relevant compliance standards.