Websites and forms everyone can use.

WCAG 2.2 AA in plain words

WCAG is the international standard for accessible web content. Level AA is what most laws and policies ask for.

The Web Content Accessibility Guidelines are published by the W3C. Version 2.2 became a W3C Recommendation in its current form on 12 December 2024, and builds on 2.1: content that meets 2.2 also meets 2.1 and 2.0. Each rule, called a success criterion, has a level: A (the minimum), AA (the usual target) and AAA (the highest).

The criteria are grouped under four principles. Content must be:

• Perceivable: people can see or hear it, whatever their senses. Text alternatives, captions, enough contrast.
• Operable: people can use it, whatever device they use. Keyboard access, enough time, nothing that flashes dangerously, clear navigation.
• Understandable: people can follow it. Plain language, predictable behaviour, forms that help you avoid and fix mistakes.
• Robust: it works with assistive technology such as screen readers, now and as they change.

WCAG 2.2 added criteria including focus not being hidden, alternatives to dragging movements, minimum target size, consistent help, not asking people to re-enter information they already gave, and accessible authentication.

The fixes that matter most

Start here. Each one removes a common barrier and is within reach of a small team without specialist help.

1. Describe imagesGive every meaningful image a short text alternative that says what it shows or does. Decorative images get an empty alternative so screen readers skip them. A logo that links home should say “Home”, not “logo”.
2. Use real headingsMark headings as headings, in order, rather than making text big and bold. Screen reader users jump between headings the way sighted readers skim.
3. Check colour contrastNormal text needs a contrast ratio of at least 4.5:1 against its background; large text at least 3:1. Pale grey on white usually fails. Never use colour alone to carry meaning, such as red for required fields.
4. Label every form fieldEvery field needs a visible label tied to it in the code, not just placeholder text that disappears when you type. Error messages should say what went wrong and how to fix it.
5. Make everything work by keyboardEverything you can do with a mouse should be possible with the Tab, Enter, Space and arrow keys, with a clearly visible focus outline, and nothing hidden behind a sticky banner when it gets focus.
6. Caption video, transcribe audioPre-recorded video with sound needs captions. Automatic captions are a start, not a finish: correct names and key terms. Podcasts and audio need transcripts.
7. Be careful with PDFsA scanned PDF is a picture of text that screen readers cannot read. Where you can, publish information as a web page. Where you need a PDF, export it from a properly structured document with headings and alt text, not a scan.
8. Make buttons big enoughWCAG 2.2 adds a minimum target size: buttons and links should be at least 24 by 24 CSS pixels, or spaced so they are hard to miss. It also asks that sign-in does not depend on memorizing or transcribing a code without help, such as allowing paste and password managers.

Test it yourself, cheaply

You do not need special software to find the biggest problems. You need an hour and the tools you already have.

1. The keyboard-only pass (15 minutes)

• Put the mouse away. Press Tab from the top of your home page and your most important form.
• Can you see where you are at every step? Can you reach and use every link, button, menu and field? Can you get out of every pop-up?
• Submit the form with a mistake in it. Is the error clear, and does focus go somewhere sensible?

2. A screen reader that is already installed (30 minutes)

• On iPhone, iPad and Mac: VoiceOver on iPhone and VoiceOver on Mac.
• On Android: TalkBack.
• On Windows: Narrator.
• Learn the basic gestures first, then listen to your home page and form. Do images make sense? Are fields announced with their labels? Do buttons say what they do?

3. A free automated checker (15 minutes)

• Lighthouse, built into Chrome’s developer tools, and WAVE from WebAIM, flag missing alt text, low contrast, missing labels and more.
• Automated tools find only some problems, and a perfect score does not mean a page is accessible. Use them alongside the manual checks above, not instead of them.

Fix what you find, starting with anything that stops someone completing a task: applying, booking, paying, contacting you.

The law, where we verified it

Many countries have disability-discrimination laws that can apply to websites. These are the rules we checked at the source.

United States: ADA Title II rule for state and local governments

The Department of Justice’s rule under Title II of the ADA requires state and local governments’ web content and mobile apps to meet WCAG 2.1 Level AA, with limited exceptions. An Interim Final Rule published on 20 April 2026 extended the compliance dates:

Meeting WCAG 2.2 AA also meets 2.1 AA, so aiming for 2.2 is a sound choice.

United Kingdom: public sector accessibility regulations

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public sector bodies, including local government, to meet WCAG 2.2 AA (unless there is a valid legal reason not to) and to publish an accessibility statement. Charities and other non-government organizations are exempt unless they are mostly financed by public funding, provide services essential to the public, or provide services aimed at disabled people. Every UK service provider still has a duty to make reasonable adjustments under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland.

Other countries where Moraph has offices have their own disability and accessibility laws. We have not summarized them here because we have not yet verified them at the source.