An accessible website works for everyone, including people who use screen readers, navigate by keyboard, have low vision, colour blindness or motor impairments, or are simply using a phone in bright sunlight. It's also good business: more people can buy from you, and many accessibility fixes improve SEO and usability at the same time. This checklist covers the WCAG 2.2 Level AA essentials in plain English.
WCAG in one paragraph
The Web Content Accessibility Guidelines (WCAG) are the international standard, published by the W3C. Version 2.2 became a Recommendation in October 2023. They're organised around four principles: content must be perceivable, operable, understandable and robust. Most organisations aim for Level AA.
Perceivable: can everyone see and hear it?
- Images have alt text that describes their purpose; decorative images have empty alt text
- Text contrast is at least 4.5:1 against its background (3:1 for large text)
- Interface elements and icons have at least 3:1 contrast against their surroundings
- Colour isn't the only signal: errors aren't shown only in red, links aren't distinguished only by colour
- Videos have captions, and audio content has transcripts
- Text can be resized to 200% without breaking the layout
- Content reflows on small screens without horizontal scrolling
Operable: can everyone use it?
- Everything works with a keyboard: menus, forms, sliders, pop-ups
- Focus is clearly visible as you tab through the page
- Focus isn't hidden behind sticky headers, cookie banners or chat widgets (new in 2.2)
- No keyboard traps: you can always tab out of a component
- A "skip to content" link lets keyboard users bypass navigation
- Touch targets are at least 24 × 24 CSS pixels, or have enough space around them (new in 2.2)
- Dragging has an alternative, such as buttons for a slider or reordering (new in 2.2)
- Moving content can be paused, and nothing flashes more than three times a second
- Time limits can be extended where they exist
Understandable: can everyone make sense of it?
- The page language is set in the HTML
- Links make sense on their own: "Read the pricing guide", not "click here"
- Forms have visible labels, not just placeholder text
- Errors are explained in text, with how to fix them
- Help is in a consistent place across pages (new in 2.2)
- People aren't asked for the same information twice in one process (new in 2.2)
- Navigation is consistent from page to page
Robust: does it work with assistive technology?
- Semantic HTML: real headings in order, lists, buttons and links
- Custom components have the right roles, names and states
- Sign-in doesn't rely on a memory or puzzle test alone; allow password managers and pasting (new in 2.2)
- Status messages (like "added to basket") are announced to screen readers
The quickest wins
If you only do five things this month:
- Fix colour contrast on body text and buttons
- Add meaningful alt text to every content image
- Label every form field properly
- Test the whole site with a keyboard alone
- Make sure focus is always visible and never hidden by sticky elements
How to test your site
- Run an automated checker to catch obvious issues.
- Tab through every key page with the keyboard only.
- Try a screen reader: VoiceOver on Mac and iPhone, or NVDA on Windows.
- Zoom to 200% and check nothing breaks.
- Test with real people who use assistive technology, if you can; see usability testing on a small budget.
Common problems on small business sites
| Problem | Why it fails | Fix |
|---|---|---|
| Cookie banner traps keyboard focus or hides content | Keyboard users can't dismiss it; focus is obscured | Make it keyboard-operable and don't cover focused elements |
| Auto-playing carousels | Moving content, hard to pause, often unlabeled | Add pause controls, or replace with static content |
| Text in images | Screen readers can't read it; it doesn't resize | Use real text, or describe it in alt text |
| PDF-only information | PDFs are often inaccessible | Publish key information as web pages |
| "Click here" links | Meaningless out of context | Describe the destination |
| Placeholder-only form labels | Labels vanish when typing | Use visible labels |
| Low-contrast grey text | Hard to read for many people | Meet 4.5:1 for body text |
| Icon-only buttons | No accessible name | Add a text label or aria-label |
Writing alt text: quick rules
- Describe the purpose, not just the picture. A photo on a team page: "Sara, lead designer, at her desk."
- Keep it short: usually one sentence.
- Don't start with "image of". Screen readers already announce it's an image.
- Include text that appears in the image, if it matters.
- Leave it empty for decoration (
alt=""), such as background textures. - For charts, summarise the finding: "Bookings doubled after the redesign," with the data in the text nearby.
An accessibility statement
An accessibility statement tells visitors how accessible your site is, what you're working on and how to report problems. A simple one includes:
- The standard you aim for (for example WCAG 2.2 AA)
- Known issues and when you plan to fix them
- How to contact you if something doesn't work
- When the statement was last reviewed
Public-sector organisations in many countries are required to publish one; for private businesses it's good practice and builds trust.
Making accessibility part of the process
Retrofitting accessibility is expensive; building it in is cheap:
- Design: check contrast and focus states in mock-ups.
- Content: write alt text and meaningful links as you publish.
- Development: use semantic HTML and test with a keyboard.
- Review: include accessibility in every pre-launch check.
- Maintenance: re-test after significant changes.
Accessibility and SEO
Many fixes help search too: descriptive alt text, logical headings, meaningful link text and fast, well-structured pages. See image SEO and Core Web Vitals.
Check accessibility automatically
Zelvorm's free AI Website X-Ray includes accessibility checks alongside speed, SEO and a UX review. On client projects, AI Proofing Preflight checks contrast and accessibility on every deliverable before it reaches review, and a person signs off.
The short version
Aim for WCAG 2.2 Level AA: sufficient contrast, alt text, captions, full keyboard access with visible focus, large enough touch targets, clear labels and errors, consistent help and semantic HTML. Test with automated tools, a keyboard, a screen reader and real people.
