How to check WCAG 2.1 and 2.2 compliance on your website
Checking a website against the Web Content Accessibility Guidelines is not a matter of running one scanner and reading a score. Automated tools are quick and useful, but they can only test the parts of WCAG a machine can measure, such as missing alt attributes or low contrast. Whether the alt text makes sense, whether a menu works with a keyboard, or whether a screen reader user can complete your checkout needs a person to try it. This guide shows how to check WCAG 2.1 and WCAG 2.2 at level AA on a small site: choosing which pages to test, running automated scanners from the browser and the command line, the manual keyboard, screen reader, zoom and contrast tests that cover what tools miss, and how to record the results so you can fix them and prove progress.
What WCAG compliance means
WCAG is published by the W3C and organised into success criteria, each a testable statement such as all non-text content has a text alternative. Every criterion has a level: A is the minimum, AA is the standard almost every law and contract refers to, and AAA is the highest and rarely required for a whole site. Meeting AA means passing every A and AA criterion.
| Version | Published | What changed |
|---|---|---|
| WCAG 2.0 | 2008 | The original set, still the base of many older policies |
| WCAG 2.1 | 2018 | Adds criteria for mobile, low vision and cognitive needs, such as reflow at 320 CSS pixels, non-text contrast and text spacing |
| WCAG 2.2 | October 2023 | Adds nine criteria, including focus not obscured, target size of at least 24 by 24 pixels, dragging alternatives and accessible authentication, and removes 4.1.1 Parsing |
The versions are backwards compatible: a page that meets 2.2 AA also meets 2.1 AA and 2.0 AA. So if you are asked how to check for WCAG 2.1, testing against 2.2 covers it, with a few extra checks on top. Test against 2.2 AA unless a contract names another version.
Compliance applies to a page, and a page passes only if all of it passes, including the cookie banner, chat widget and embedded forms supplied by third parties. That is why the method below tests full pages and complete tasks, not isolated components. The WCAG requirements guide explains the criteria themselves.
Choose the pages to test
You rarely need to test every page. Pick a sample that covers every template and every important task, following the approach in the W3C's evaluation method, WCAG-EM:
- the home page, a typical content page and a blog post;
- one page of each template, such as product, category, service and location pages;
- every step of key tasks: contact form, sign-up, login, basket and checkout, booking;
- pages with unusual content: video, maps, data tables, calculators, PDFs;
- a few random pages to catch content editors' mistakes.
For a small business site that is usually 10 to 25 pages. Record the list and the date, because a result only means something alongside the pages it covers.
Run automated scans first
Automated tools find a useful share of problems quickly, and they are the right first pass. In the browser:
- axe DevTools adds an axe tab to Chrome or Firefox DevTools and lists failures with the WCAG criterion and the element.
- WAVE overlays icons on the page, which is good for seeing heading structure and missing labels in context.
- Lighthouse, in the Lighthouse tab of Chrome DevTools, includes an accessibility category built on axe. Its score is a weighted summary, not a compliance result.
To test your page list in one go, use a command line tool. With axe, limited to WCAG 2.2 A and AA rules:
npx @axe-core/cli https://www.example.com/ https://www.example.com/contact \
--tags wcag2a,wcag2aa,wcag21a,wcag21aa,wcag22aaOr with Pa11y, which reports against the WCAG 2 AA standard by default:
npx pa11y --standard WCAG2AA --runner axe https://www.example.com/checkoutA few console checks are handy while you work through pages:
// images with no alt attribute at all
document.querySelectorAll('img:not([alt])');
// the heading outline, in order
[...document.querySelectorAll('h1,h2,h3,h4,h5,h6')]
.map(h => h.tagName + ' ' + h.textContent.trim());The manual tests that cover what tools miss
Keyboard
Put the mouse aside and use Tab, Shift and Tab, Enter, Space, the arrow keys and Escape. Every link, button, form field, menu and dialog must be reachable and usable, in a logical order, with a focus outline you can always see and that is not hidden behind a sticky header. Check that you can close pop-ups and are never trapped. The keyboard navigation guide and focus indicators guide cover the fixes.
Screen reader
Use NVDA on Windows, which is free, or VoiceOver on a Mac (Command and F5) or iPhone. Move through the page by headings and by landmarks, fill in each form and listen to what is announced. Buttons should say what they do, form fields should announce their labels, errors should be announced, and images should be described or skipped if decorative.
Zoom, reflow and text spacing
Zoom the browser to 200% and check all text remains readable. Then set the window to 1280 pixels wide and zoom to 400%, which equals 320 CSS pixels: content should reflow into one column with no sideways scrolling. For text spacing, apply this CSS with a bookmarklet or the DevTools Styles pane and check nothing is cut off:
* { line-height: 1.5 !important; letter-spacing: 0.12em !important;
word-spacing: 0.16em !important; }
p { margin-bottom: 2em !important; }Contrast and use of colour
Body text needs a contrast ratio of at least 4.5 to 1, large text 3 to 1, and icons, input borders and focus outlines 3 to 1 against what is next to them. Check that links, errors and required fields are not shown by hue alone. See the colour contrast guide.
Media, forms and timing
Videos need captions, and audio-only content a transcript. Forms need visible labels, clear error messages and no need to re-enter information already given. Anything that moves for more than five seconds needs a pause control, and time limits need a way to extend them.
Recording the results
Keep one row per issue, so fixes can be assigned and checked:
| Page | Criterion | Level | Issue | Found by | Severity | Status |
|---|---|---|---|---|---|---|
| /checkout | 2.1.1 Keyboard | A | Delivery date picker cannot be opened by keyboard | Manual | Blocker | Open |
| /contact | 1.3.1 Info and Relationships | A | Email field has no label | axe | High | Fixed |
| All | 2.4.11 Focus Not Obscured | AA | Sticky header hides focused links | Manual | Medium | Open |
Severity should reflect impact: a blocker stops someone completing a task, high makes it very hard, medium causes difficulty. Fix blockers on key tasks first.
For a public summary, write an accessibility statement saying which standard you test against, the date, the known issues and how people can report problems. Public sector sites in the UK must publish one. Businesses selling to larger organisations are sometimes asked for an accessibility conformance report, often based on the VPAT template, which records a result for each criterion.
Platform notes
- WordPress. Theme and page builder output causes most failures, especially menus, sliders and forms. Test with the plugins you actually run. See accessibility in WordPress.
- Shopify. Check the theme's product variant pickers, cart drawer and filters by keyboard, as these are the usual problem areas. See accessibility in Shopify.
- React and other frameworks. Single-page navigation often fails to move focus or announce the new page. Add axe to your component tests. See accessibility in React.
- Overlays. Accessibility overlay widgets do not make a site compliant, and they can interfere with assistive technology. Fix the underlying code instead.
The fix, step by step
Step 1
Pick the standard and the page sample
Decide which standard you are testing against, normally WCAG 2.2 level AA unless a contract names WCAG 2.1. List 10 to 25 pages that cover every template, every step of your key tasks such as contact, sign-up and checkout, pages with media or tables, and a few random pages. Save the list with the date, because your results only apply to the pages you tested.
Step 2
Run an automated scan on every page
Run axe DevTools or WAVE on each page in your sample, or test the whole list from the command line with npx @axe-core/cli using the WCAG A and AA tags, or with pa11y --standard WCAG2AA. Log each failure with its page, criterion and element. Inspect each one in the browser to rule out false positives before adding it to your results table. Rerun the scan after each round of fixes.
Step 3
Test everything with the keyboard
Without a mouse, move through each page with Tab and Shift and Tab, and operate menus, buttons, forms and dialogs with Enter, Space, arrow keys and Escape. Check the order is logical, focus is always visible and never hidden behind sticky headers, and nothing traps you. Complete each key task this way. Log every control you cannot reach or use. Note the key you pressed when each problem appeared.
Step 4
Test with a screen reader
Turn on NVDA on Windows or VoiceOver on a Mac or iPhone, then navigate by headings and landmarks and complete each key task. Listen for unlabelled buttons, form fields without names, images with unhelpful or missing descriptions, errors that are not announced and content that is read in a confusing order. Log each problem against the criterion it breaks, noting exactly what was announced so a developer can reproduce it.
Step 5
Check zoom, reflow and text spacing
Zoom to 200% and confirm all text stays readable and nothing overlaps. Set the window to 1280 pixels and zoom to 400%, and check the page reflows into one column without sideways scrolling, except for content such as maps or data tables. Apply the text spacing CSS and look for clipped or overlapping text. Log any failures with screenshots, and repeat the check on a phone in both portrait and landscape orientation.
Step 6
Check contrast and use of colour
Measure text contrast with the DevTools contrast picker or axe, aiming for 4.5 to 1 for body text and 3 to 1 for large text. Check icons, form borders and focus outlines reach 3 to 1 against their surroundings. Confirm that links, errors and required fields are identified by more than hue alone, such as underlines, icons or text. Record the measured ratio for every failure so the fix can be checked against it.
Step 7
Check media, forms and moving content
Confirm every video has accurate captions and audio-only content has a transcript. Submit each form with mistakes and check errors are described in text, linked to the field and announced. Check that carousels and animations can be paused, time limits can be extended, and nothing asks people to re-enter information they already gave in the same process. Log any failure with the page and the step where it happened.
Step 8
Record, prioritise and fix
Put every issue into one table with page, criterion, level, description, how it was found, severity and status. Fix blockers on key tasks first, then high and medium issues, working at template level where possible so one change fixes many pages. Retest each fix with the same method that found it, and mark it fixed only when it passes. Keep fixed rows in the table, because they show progress over time.
Step 9
Publish a statement and schedule retests
Write an accessibility statement naming the standard, the date of testing, known remaining issues and a way for people to report problems, and link it from the footer. Add the automated scan to your deployment process so new failures are caught, and book a full manual retest of your sample at least yearly and after any redesign. Update the statement each time with the new test date and any issues still open.
Edge cases worth knowing
- Third-party content. Embedded booking tools, payment pages, chat widgets and cookie banners are part of your page. Test them and raise issues with the supplier; note them in your statement if you cannot fix them yourself.
- PDFs and documents. Downloadable documents are covered too. Tag PDFs properly or provide the same content as an accessible web page.
- Mobile. Repeat the key tasks on a phone with VoiceOver or TalkBack. Target size, orientation and gesture alternatives are easiest to judge on a real device.
- False positives. Tools sometimes flag contrast on text over images or gradients they cannot measure, or hidden elements. Confirm each automated finding by inspecting the page before logging it.
- Partial conformance. If a part of the site is outside your control, say so plainly rather than claiming full conformance.
Keeping it compliant
- Add the axe or Pa11y command to your deployment process, so new automated failures block a release.
- Repeat the keyboard test on any new template, component or plugin before it goes live.
- Give content editors a short checklist: meaningful alt text, real headings in order, descriptive link text, captions on video.
- Rerun the full sample, including screen reader tests, at least once a year and after a redesign, and update the accessibility statement.
The accessibility guide explains the most common failures in more depth, and alt text and form labels cover two of the issues found most often.
1. How do I check if my website is WCAG compliant?
Check a sample of pages that covers every template and key task, first with automated tools such as axe, WAVE or Lighthouse, and then with manual tests. The manual tests are keyboard-only use, a screen reader, zoom to 200% and 400%, text spacing, contrast checks, and reviewing captions and forms. Log every failure against the WCAG success criterion it breaks. A page complies only when it passes every A and AA criterion, including parts supplied by third parties.
2. How do I check for WCAG 2.1 specifically?
Test against WCAG 2.1 level AA by running your automated tool with the 2.0 and 2.1 A and AA rules, then adding the manual checks that 2.1 introduced. Those include reflow at 320 CSS pixels, text spacing, non-text contrast for icons and borders, content on hover or focus, orientation and character key shortcuts. Because WCAG 2.2 builds on 2.1, a site that passes 2.2 AA also passes 2.1 AA, so testing to 2.2 is a safe way to meet a 2.1 requirement.
3. What is the difference between WCAG 2.1 and 2.2?
WCAG 2.2 keeps every WCAG 2.1 criterion except 4.1.1 Parsing, which was removed as obsolete, and adds nine new ones. The new A and AA criteria cover focus not being hidden by sticky content, pointer targets of at least 24 by 24 pixels, alternatives to dragging, consistent placement of help, not asking for the same information twice, and sign-in that does not depend on memory tests. WCAG 2.2 became a W3C Recommendation in October 2023 and is now the version most new guidance points to.
4. Can an automated tool tell me if my site is compliant?
No. Automated tools can only test the criteria a machine can measure, such as missing alt attributes, missing form labels, low text contrast and invalid ARIA. They cannot tell whether alt text is accurate, whether headings describe the content, whether focus order makes sense or whether a custom widget works with a keyboard and screen reader. Use automated scans as a fast first pass and for catching regressions, then rely on manual testing for the rest of the judgement.
5. Which screen reader should I test with?
Test with NVDA on Windows if you can, because it is free and widely used, and with VoiceOver on an iPhone, because many screen reader users browse on mobile. VoiceOver on a Mac is a reasonable alternative if you do not have Windows. JAWS is common in workplaces but needs a paid licence for regular use. You do not need every combination; testing key tasks with one desktop and one mobile screen reader finds most problems.
6. What level of WCAG do I need to meet?
Level AA is the target for almost every legal requirement and contract. UK public sector websites must meet WCAG 2.2 AA under the accessibility regulations, the European standard EN 301 549 references WCAG AA, and US guidance for public bodies uses WCAG 2.1 AA. Level AAA is not recommended as a whole-site requirement, because some content cannot meet every AAA criterion, but individual AAA criteria are worth meeting where they are practical for your site.
7. How often should I check WCAG compliance?
Run automated checks on every release, test any new template or component by keyboard before it goes live, and repeat a full manual audit of your page sample at least once a year. Also retest after any redesign, change of theme, new checkout or booking system, or new third-party widget, because these are the changes most likely to introduce failures. Update your accessibility statement each time, with the date of the latest test and any remaining issues.
The accessibility audit tests your pages against WCAG 2.2 A and AA rules, lists each failure with its criterion and element, and points out the manual checks no scanner can make for you.
Open Accessibility Fixes →