← Go Back

WCAG (Web Content Accessibility Guidelines)

What is WCAG?

WCAG (Web Content Accessibility Guidelines) is the international standard for making web content accessible. It’s published by the W3C and organised around four principles (POUR): Perceivable, Operable, Understandable, Robust. Conformance is measured at three levels: A (minimum), AA (common target), and AAA (stretch).

Use it when: you’re building or auditing any web product. Aim for Level AA unless you have a justified exception; many regulations reference WCAG.

Copy/paste checklist (WCAG AA, high level)

  • [ ] Perceivable: Text alternatives for images; captions for video; content can be presented in different ways; colour isn’t the only way to convey information; text has sufficient contrast.
  • [ ] Operable: All functionality available via keyboard; no keyboard traps; enough time to complete tasks; no content that flashes in a way that could cause seizures; clear focus order and focus visibility.
  • [ ] Understandable: Language of page set; navigation and behaviour are consistent; forms have labels and clear errors; input purpose can be programmatically determined where appropriate.
  • [ ] Robust: Valid, semantic markup; name, role, value exposed for UI components; works with assistive technologies.

Why WCAG matters

  • Provides a shared, testable standard so teams know what “accessible” means.
  • Reduces legal and compliance risk in many jurisdictions.
  • Improves usability for a wide range of users, not only those with disabilities.
  • Aligns with accessibility best practice and inclusive design.

What good WCAG conformance includes

Checklist

  • [ ] Level chosen – typically AA; document if you’re targeting A or AAA.
  • [ ] Scope defined – which pages or flows are in scope (e.g. all public pages).
  • [ ] Testing – automated (e.g. axe) plus manual (keyboard, screen reader, zoom).
  • [ ] Known issues – list of non-conformant items and plan to fix or document exceptions.
  • [ ] Ongoing – new features are checked before release; conformance isn’t one-off.

Common formats

  • WCAG 2.1 Level AA: the most common target; includes mobile and low-vision criteria from 2.1.
  • WCAG 2.2: adds more criteria (e.g. focus visibility, dragging); consider when starting new work.
  • Statement of partial conformance: if only part of the site conforms, state the scope clearly.

Examples

Example (the realistic one)

Your product team targets WCAG 2.1 Level AA. You run axe in CI and in manual QA; you test with keyboard and one screen reader (e.g. NVDA or VoiceOver). You keep a list of known issues (e.g. “Legacy widget X fails 2.4.7”; “Fix in Q2”). New components are checked against the checklist before merge. You document your target and scope in your accessibility statement.

Common pitfalls

  • Automated-only testing: many issues need manual and assistive-tech testing. → Do this instead: use automated as a baseline; add keyboard and screen reader testing.
  • Fixing only “critical”: Level A is the floor; AA is the usual target. → Do this instead: aim for AA and document any exceptions.
  • No ownership: accessibility is “someone else’s job”. → Do this instead: make conformance part of definition of done; involve design and dev from the start.
  • Ignoring 2.2: if you’re starting fresh, consider WCAG 2.2 so you don’t retrofit later. → Do this instead: check current W3C recommendation and your legal context.
  • WCAG vs accessibility: accessibility is the outcome; WCAG is the standard you use to get there.
  • WCAG vs Section 508 / EAA / etc.: many laws reference WCAG (e.g. Section 508 points to WCAG 2.0). Check your jurisdiction.
  • WCAG vs design systems: your design system and component libraries should be built to meet WCAG so every use is accessible by default.

Next step

Run an automated audit (e.g. axe) on one key flow and fix the issues. Then add keyboard testing using Keyboard navigation and Focus management. Declare your target (e.g. WCAG 2.1 AA) and scope in your accessibility statement.

Related Terms