WCAG Compliance Checklist

This checklist is a practical self-review at roughly WCAG 2.1 Level AA, not a substitute for a full audit — many success criteria require code review and assistive technology testing to evaluate properly. If you can't confidently check an item, treat that as the finding.

0 of 0 checked

Perceivable

Every meaningful image has alt text that conveys its purpose, and decorative images are marked as decorative
Body text meets a 4.5:1 contrast ratio, and large text and interface components meet 3:1
Color is never the only way information is conveyed (errors, required fields, chart series, status)
Video has accurate captions and audio-only content has a transcript
Content reflows without horizontal scrolling at 400% zoom on a 1280px viewport
Text can be resized to 200% without loss of content or function
Form fields, tables, and headings use real semantic markup rather than styled text

Operable

Every interactive element can be reached and activated with a keyboard alone
Focus is always visible, with a clearly distinguishable indicator
Focus order follows the visual and logical reading order
There are no keyboard traps — a keyboard user can always move out of a component
Modals move focus in on open and return it on close
A skip link lets keyboard users bypass repeated navigation
Users can pause, stop, or hide any auto-playing, moving, or scrolling content
Session timeouts warn the user and offer a way to extend
Link text makes sense out of context — no bare "click here" or "read more"

Understandable

The page language is declared, and sections in another language are marked
Navigation, labels, and components behave consistently across the site
Every form input has a programmatically associated visible label
Placeholder text is never used as the only label
Errors are identified in text, explain what went wrong, and suggest how to fix it
Error messages are announced to screen reader users, not just displayed
Instructions don't rely on sensory characteristics alone ("the button on the right")

Robust

Custom components expose a correct name, role, and value to assistive technology
ARIA is used only where native HTML can't do the job, and used correctly
Dynamic updates (cart totals, filter results, validation) are announced appropriately
The site has been tested with an actual screen reader, on desktop and mobile

Beyond The Website

PDFs and downloadable documents are tagged, readable, and not scanned images
Third-party platforms (portals, chat, scheduling, payments) have been tested or have a current VPAT
A published accessibility statement names your standard and gives a working contact
A written policy assigns accessibility ownership, and content authors have been trained