The Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), are the international standard for making websites usable by people with disabilities. WCAG is not a law itself, but it is the technical benchmark nearly every accessibility law points to — ADA case law, the European Accessibility Act, Canada's AODA, and U.S. Section 508 all reference it, most often at Level AA. Meet WCAG 2.2 Level AA and you are in a strong position under almost any accessibility regime in the world.
WCAG is organized around four principles — content must be Perceivable, Operable, Understandable, and Robust — but in practice it breaks down into concrete, checkable items: does every image have a text alternative, can every feature be used with a keyboard, do form fields have labels.
This checklist translates the most impactful WCAG 2.2 Level AA requirements into tasks a site owner or web team can actually work through. It is not a substitute for a full audit, but ticking every box below addresses the issues behind most real-world barriers and legal complaints.
Level AA is the target
WCAG has three conformance levels: A, AA, and AAA. Level AA is the one referenced by laws and regulators worldwide, including ADA case law, the EAA, Section 508, and EN 301 549.
WCAG 2.2 is current
WCAG 2.2, published in October 2023, is the current version and is backwards-compatible: a site meeting 2.2 AA also meets 2.1 and 2.0 AA.
Most failures are basic
Large-scale scans find the same failures dominating year after year: low-contrast text, missing alt text, unlabeled form fields, and empty links. Fixing these basics removes most barriers.
Testing is part of the job
Automated tools catch roughly a third of WCAG issues. Keyboard-only testing and screen reader spot checks are needed for the rest.
Images and non-text content
Every piece of visual information needs a text equivalent so that screen reader users get the same information. Missing alt text remains one of the most common failures on the web.
- Every informative image has alt text describing its purpose, not just its appearance ("Diagram of the checkout flow" beats "image123.png").
- Purely decorative images have an empty alt attribute (alt="") so screen readers skip them.
- Images that act as links or buttons have alt text describing the destination or action.
- Charts and infographics have a longer text description nearby or linked.
- Standalone icons (a magnifying glass, a hamburger menu) carry an accessible name via alt text or aria-label.
Color and contrast
Low-contrast text is consistently the single most common WCAG failure found in large-scale scans. It affects people with low vision, color blindness, and anyone reading a screen in sunlight.
- Body text has a contrast ratio of at least 4.5:1 against its background; large text (roughly 24px, or 19px bold) needs at least 3:1.
- Buttons, form field borders, focus indicators, and meaningful icons meet 3:1 contrast against adjacent colors.
- Color is never the only way information is conveyed — errors are marked with text, not just a red border; links in body text are distinguished beyond color alone.
- Text over background images or gradients stays readable at every point (test the worst spot, not the average).
Keyboard and focus
Many people cannot use a mouse, including screen reader users and people with motor disabilities, so WCAG requires everything to work with a keyboard alone. The fastest test you can run today: put the mouse aside and use your site with only Tab, Enter, Space, and the arrow keys.
- Every interactive element — links, buttons, menus, form fields, custom widgets — can be reached and activated by keyboard.
- A visible focus indicator shows where you are at all times; it has not been removed with CSS for aesthetic reasons.
- Focus moves in a logical order that follows the visual layout, with no keyboard traps; modals close with Escape and return focus where it was.
- A "skip to main content" link is the first focusable element, so keyboard users are not forced through the full navigation on every page.
- Nothing requires precise dragging or complex gestures without a simple click or keyboard alternative.
Forms and error handling
Forms are where accessibility failures cost you money directly — an unusable checkout or signup form is a lost customer. WCAG's requirements here are also just good UX for everyone.
- Every input has a programmatically associated label, not just placeholder text that disappears when typing begins.
- Required fields are indicated in text, not by color or an unexplained asterisk alone.
- Error messages identify which field has the problem and say how to fix it ("Enter a date in DD/MM/YYYY format").
- Inputs use correct types and autocomplete attributes (email, tel, name) so browsers and assistive technology can help fill them.
- Users are not asked to re-enter information they already provided in the same process — a WCAG 2.2 addition.
- Login does not depend on a puzzle or memory test; WCAG 2.2's Accessible Authentication criterion means supporting paste and password managers.
- Time limits can be extended, and legal or financial submissions can be reviewed and corrected before confirmation.
Structure, navigation, and page basics
Screen reader users navigate by headings, landmarks, and link lists rather than by scanning visually. A well-structured page lets them jump straight to what they need.
- Every page has a unique, descriptive title and a declared language (lang attribute).
- Headings form a logical outline: one h1 per page, with h2/h3 nested in order, never chosen just for font size.
- Link text makes sense out of context — "View pricing" rather than "click here".
- Navigation is consistent across pages, and there is more than one way to find content (menu plus search or a sitemap).
- Content reflows without horizontal scrolling on small screens, text resizes to 200% without breaking, moving content can be paused, and nothing flashes more than three times per second.
- Semantic HTML (nav, main, button, real tables with headers) is used instead of styled generic divs — the heart of the Robust principle.
Media: video, audio, and documents
Multimedia needs alternatives so that deaf, hard-of-hearing, and blind visitors can access the same information.
- Pre-recorded videos have accurate synchronized captions — not just auto-generated ones left uncorrected.
- Videos where important visual information is not spoken have audio description or a text alternative.
- Audio-only content (podcasts, recordings) has a transcript.
- Media players are keyboard-operable, and nothing auto-plays sound for more than three seconds without a way to stop it.
- PDFs and other downloadable documents are tagged and accessible, or an accessible HTML version is offered.
How to verify — and keep it that way
Compliance is a process, not a one-time project. New pages, marketing banners, and CMS edits can all introduce regressions, so build checking into your routine.
A layered approach works best: continuous automated scanning, manual keyboard and screen reader testing on key journeys, and ideally feedback from real users with disabilities. Tools like AccessWiser can help by monitoring for common WCAG issues and improving the experience for assistive technology users — though no tool or widget alone can guarantee full conformance or legal compliance.
- Run an automated checker (axe, WAVE, or Lighthouse) on your highest-traffic templates and fix everything it flags.
- Complete your top user journeys — find a product, contact you, check out or sign up — using only a keyboard.
- Spot-check those same journeys with a screen reader (VoiceOver is free on Mac and iOS; NVDA is free on Windows).
- Publish an accessibility statement with a contact method, and treat any barrier reported by a visitor as a priority fix.
- Re-audit after redesigns, major feature launches, or platform migrations.
Frequently asked questions
Is WCAG compliance legally required?
WCAG itself is a voluntary technical standard, but many laws make it effectively mandatory. U.S. courts routinely reference WCAG in ADA website cases, the European Accessibility Act (whose obligations have applied since June 28, 2025) relies on EN 301 549, which incorporates WCAG, and Section 508 and Canada's AODA point to it too. Meeting WCAG AA is the practical way to satisfy all of them.
Should I target WCAG 2.1 or 2.2?
Target 2.2. It is the current version and includes everything in 2.1 plus nine additional criteria addressing common real-world problems like focus visibility and accessible authentication. Because versions are backwards-compatible, a 2.2 AA site automatically satisfies legal references to 2.0 or 2.1 AA.
Can an automated tool make my site fully compliant?
No. Automated tools catch machine-detectable issues like missing alt attributes and contrast failures — roughly a third of WCAG issues — but cannot judge whether alt text is meaningful or focus order makes sense. Use tools for continuous monitoring, and manual testing for judgment calls.
What is the difference between Level A, AA, and AAA?
Level A covers the most basic barriers, AA adds the requirements laws and regulators reference, and AAA is an enhanced level that even the W3C does not recommend requiring for entire sites. Aim for full AA, and adopt individual AAA criteria where they fit your audience.
This article is provided for general information about accessibility regulations and standards. It is not legal advice — consult a qualified professional about your specific compliance obligations.