KB — Pre-launch — Accessibility / WCAG

Accessibility / WCAG 2.2 AA researched

The accessibility standard every client site must meet before launch — targeting WCAG 2.2 Level AA.

Use this when

You are building or reviewing any client site and need to know what the accessibility bar is, how to reach it, and how to verify it before handing off.

Definition of done

Requirements

Semantic HTML and heading order. Use the right element for the job — <button> for actions, <a> for navigation, <nav>, <main>, <header>, <footer> as landmarks. Heading levels must form a logical outline: one <h1> per page, no skipped levels. Screen readers navigate by heading; a broken outline destroys that. (WCAG 2.2 SC 1.3.1 Info and Relationships)

Image alt text. Every <img> needs an alt attribute. Informative images get a concise description of what they convey, not what they look like. Decorative images get alt="" — an empty string, not the filename. Linked images must describe the destination. (SC 1.1.1 Non-text Content)

Descriptive link text. Link text must make sense in isolation — "read more" and "click here" fail because a screen-reader user scanning links hears only the link text, stripped of context. Describe the destination or action: "Download the 2025 accessibility audit (PDF)" beats "download here". (SC 2.4.4 Link Purpose)

Color contrast. Normal-size text (below 18 pt / 14 pt bold) needs at least a 4.5:1 contrast ratio against its background. Large text (18 pt or larger, or 14 pt bold or larger) needs at least 3:1. Non-text UI components — input borders, focus rings, icon-only buttons — also need 3:1 against adjacent colors. Measure with a tool; never eyeball it. (SC 1.4.3 Contrast Minimum; SC 1.4.11 Non-text Contrast)

Keyboard navigation. Every interactive element must be reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys where applicable — no mouse required. Never remove or suppress the browser's default focus outline without providing a visible replacement. WCAG 2.2 tightened the focus-visibility bar with SC 2.4.11 Focus Appearance (AA): the focus indicator must have a minimum area of the element's perimeter, a 3:1 contrast change, and must not be entirely hidden by other content. (SC 2.1.1 Keyboard; SC 2.4.7 Focus Visible; SC 2.4.11 Focus Appearance)

Form labels and error messages. Every input, select, and textarea needs a <label for="…"> that matches the input's id. Placeholder text does not count as a label — it disappears on input and has inadequate contrast. When validation fails, the error message must identify the field by name and describe what is wrong and how to fix it, not just "invalid input". (SC 1.3.1; SC 3.3.1 Error Identification; SC 3.3.2 Labels or Instructions; SC 3.3.3 Error Suggestion)

ARIA — sparingly and correctly. The first rule of ARIA is: don't use ARIA if a native HTML element does the job. A <button> is always better than <div role="button">. When ARIA is necessary — custom widgets, live regions, dynamic state — use it precisely: every aria-labelledby must reference an element that exists; every role must have its required owned elements; every live region must have an appropriate aria-live level. Wrong ARIA is worse than no ARIA — it actively misleads assistive technology. (SC 4.1.2 Name, Role, Value)

Reduced motion. Animations and transitions that run automatically can trigger vestibular disorders. Wrap non-essential motion in a prefers-reduced-motion: reduce media query and either cut or slow the animation. This is not an AA requirement (SC 2.3.3 Animation from Interactions is AAA), but it is expected practice and straightforward to implement. For any content that moves, blinks, or scrolls for more than five seconds, provide a pause/stop mechanism. (SC 2.2.2 Pause, Stop, Hide — AA)

How to test

Start automated, finish manually. Automated tools catch roughly 30–40 % of real issues — they are a floor, not a ceiling.

Automated: Run the axe DevTools browser extension or Lighthouse (Accessibility tab) on every key page type — homepage, article/CMS page, form page, nav-heavy page. Fix every critical and serious violation before launch. Record the score; a regression in the next build is a signal.

Keyboard pass: Tab through the entire page with no mouse. Verify: (a) every interactive element receives focus in a logical order, (b) the focus indicator is clearly visible at every stop, (c) modals trap focus while open and release it on close, (d) custom widgets (accordions, tabs, dropdowns) respond to the expected keystrokes.

Screen reader: Spot-check with VoiceOver on macOS (Cmd+F5) or NVDA on Windows with Firefox. Read the page top-to-bottom, navigate by headings and landmarks, submit at least one form. You are not looking for perfection — you are looking for anything that would block a real user: unlabeled controls, orphaned error messages, focus traps with no exit.

Gotchas

Why & sources

WCAG 2.2 is published by W3C WAI and is the reference standard adopted by most EU and US accessibility legislation (EN 301 549, ADA, AODA). Level AA is the accepted commercial bar. The quick reference for all success criteria is at w3.org/WAI/WCAG22/quickref/. The Understanding documents at w3.org/WAI/WCAG22/Understanding/ explain the intent behind each criterion with examples. For practical testing guidance see w3.org/WAI/test-evaluate/. The ARIA Authoring Practices Guide at w3.org/WAI/ARIA/apg/ is the canonical reference for widget keyboard patterns. Cross-reference with Launch checklist before every handoff.