Operations

Accessibility checklist for public web pages (WCAG 2.2 AA)

The automated checks, the manual review and the requirements no scanner can verify, applied to every public page before it is released.

By T P Joshi · · Updated · Accessibility · 3 min read

Automated testing is necessary, not sufficient

An engine such as axe-core should run against every page template in an end-to-end test on a production build, and fail the pipeline on a violation. It reliably finds missing text alternatives, insufficient colour contrast, unlabelled controls and invalid ARIA attributes.

It cannot judge whether alternative text is meaningful, whether the focus order is sensible, whether a widget traps the keyboard, or whether a consent banner covers the control a visitor is about to use. A passing scan therefore establishes a floor, not conformance.

Manual review for each page type

Each new page type, and each component that introduces a new interaction, receives a manual review:

  • Keyboard only. Every control is reachable and operable in a logical order, the focus indicator is always visible (2.4.7), and no component traps focus (2.1.2). A sticky element must never hide the control that has focus (2.4.11).
  • Screen reader. With NVDA on Windows, and VoiceOver where Apple platforms matter, headings make sense when read as a list, links identify their destination, and form fields announce their label, whether they are required and any error.
  • Zoom and reflow. At 200 percent zoom (1.4.4) and a 320 CSS pixel viewport (1.4.10), nothing is clipped and the page does not scroll in two directions.
  • Reduced motion. Transitions and reveals are removed under prefers-reduced-motion, and moving content that runs for more than five seconds has a pause control (2.2.2).
  • Forced colours. Under Windows high-contrast themes, controls and their states remain recognisable.

Rules that scanners cannot verify

  • Required fields are marked in words, not by an asterisk or a colour alone (1.4.1, 3.3.2).
  • Errors are specific and reachable. Each is identified in text (3.3.1), linked to its field, and summarised at the top of the form with focus moved to the summary.
  • Target size. Interactive targets are at least 24 by 24 CSS pixels (2.5.8); primary controls are 44 by 44 for comfortable use.
  • One primary action per page, repeated consistently, so that a visitor never has to choose between several equally weighted buttons.
  • Consent banners are not modal, do not cover a call to action, and present accept and reject with equal prominence.
  • The header scrolls with the page. A fixed header is a common cause of obscured focus (2.4.11); a header that scrolls away is the simplest way to comply.
  • Native elements come first. Custom widgets need correct names, roles and states (4.1.2); ARIA is added only where no native element fits.

Making it routine

  • Every new page template is added to the automated route list before release; a route that is not tested is not verified.
  • The manual review is part of the definition of done for a new page type, and its findings and known gaps are recorded.
  • An accessibility statement names the standard targeted and gives visitors a way to report a barrier.
  • Testing with people who rely on assistive technology complements all of the above. Scans and expert review approximate their experience without replacing it.

Why marketing pages are included

A marketing site is the first product a prospective customer with a disability experiences. A defect that survives on a brochure site usually points to a process gap that will recur in the product, and the discipline transfers directly to the software built behind it.


This site follows the checklist above: axe runs against every page template of a production build, and each new template joins the route list before release.