# 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.* Operations · By T P Joshi · 2026-08-22 (updated 2026-09-22) · 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.