Skills on AI 459 skills

Active theme: Light

Accessibility Testing

Use when asked to test whether a website or application is usable by people with disabilities — WCAG/ADA compliance, automated scanning, and manual/user testing — as distinct from screen-reader-specific verification (see screen-reader-testing) or general usability testing (see usability-testing).

Accessibility testing evaluates whether a website, application, or program is usable by people with disabilities, so that everyone — regardless of ability — can use it without barriers. Beyond the ethical case, it also reduces legal exposure under accessibility law.

Standards to test against

WCAG (Web Content Accessibility Guidelines) is the primary technical standard; jurisdictions layer legal requirements on top of it (e.g. the ADA in the US, the Rehabilitation Act's Section 508 for US federal systems). See HTML's accessibility section for concrete markup technique WCAG conformance depends on.

Four complementary methods

  • Compliance checking — verifying against the specific WCAG success criteria (or another named standard) the project has committed to.
  • Automated testing — tools scanning for color-contrast ratios, missing alt text, missing form labels, and similar mechanically-detectable issues; catches maybe a third of real issues, fast and cheap to run continuously.
  • Manual testing — a tester combining expertise and tooling to check what automation can't (logical reading order, meaningful focus order, whether an ARIA label actually makes sense in context).
  • User testing with people with disabilities — the only method that reliably surfaces real barriers automated and manual expert review both miss; see Screen Reader Testing for the screen-reader-specific slice of this.

Common pitfalls

  • Relying on automated scanning alone — it has a real, well-known ceiling on what it can detect; treating a clean automated scan as "fully accessible" is a common, false conclusion.
  • Testing only with a screen reader and skipping other assistive tech — magnification, voice control, and switch devices surface different issues than a screen reader alone.
  • Deferring accessibility testing to the end of a project — the same shift-left logic that applies broadly (see Shift Left Testing) applies here: retrofitting accessibility into a finished design is far more expensive than building it in from the start.

Learn more

View accessibility-testing/SKILL.md on GitHub