This checklist gives developers, QA teams and accessibility leads a working set of acceptance criteria mapped to the four WCAG principles, a testing workflow that combines automated and manual checks, and the governance steps a compliance programme needs. It follows the WCAG 2.2 Recommendation and the W3C guidance on evaluation tools, both of which stress that automated scanning alone cannot confirm compliance.
TL;DR:
- Automated scans typically detect only 30 to 50% of accessibility issues, making manual and assistive technology testing essential for comprehensive evaluation.
- Focus visibility and target size are the easiest WCAG 2.2 updates to implement, often requiring quick CSS adjustments that can be tested within a few hours.
- Testing should cover key user journeys with keyboard navigation and screen readers to ensure accessibility goals are met beyond automated results.
- Compliance programs must include third-party widget accessibility evidence, tagged documents, and an assigned owner with regular review to maintain adherence.
- Building accessibility into the design and development process from the start simplifies certification, especially on smaller sites, compared to retrofitting after completion.
Table of Contents
- Checklist by WCAG principle: Perceivable, Operable, Understandable, Robust
- What's new in WCAG 2.2 and where to focus first
- Combine automated scans with manual and assistive-technology checks
- Governing documents, third-party widgets and public reporting
- Turning the checklist into sprint-level tickets
- Making the checklist work on smaller sites
- Webnora as a managed route to an accessible website
- Where to check the source guidance
- Sources
- FAQ
Checklist by WCAG principle: Perceivable, Operable, Understandable, Robust
WCAG organises its success criteria into four principles, and building your checklist around them keeps testing focused rather than scattershot. Each item below states what a pass looks like and how to check it quickly.
Perceivable
- Images carry alt text that conveys purpose, not filename; decorative images use empty alt attributes. Test by tabbing through a screen reader pass and confirming each image announces meaning or stays silent.
- Video content has captions and a text transcript; audio-only content has a transcript. Test by playing media with sound off and reading the captions against the script.
- Text and interface elements meet minimum contrast ratios against their background. Test with a contrast checker on both normal and large text sizes.
- Content reflows without horizontal scrolling at 400% zoom. Test by zooming a page in a browser and checking that no content is clipped or requires two-directional scrolling.
- Alternatives exist for content delivered only through colour, shape or sound. Test by viewing the page in greyscale and confirming meaning survives.
Operable
- Every interactive element is reachable and operable by keyboard alone. Test by unplugging the mouse and completing a full task with Tab, Shift+Tab and Enter.
- Keyboard focus is visible at every stop, with a clear outline or highlight. Test by tabbing through a page and confirming the focus is always clearly visible.
- Touch and pointer targets meet the 24 by 24 CSS pixel minimum in most cases. Test by measuring button and icon dimensions in browser developer tools.
- Navigation is consistent across pages, and users can skip repeated blocks. Test by comparing header and navigation order across three or four templates.
Understandable
- Form fields have visible labels, not just placeholder text. Test by clearing a field and confirming the label remains readable.
- Instructions and error messages explain what went wrong and how to fix it. Test by submitting a form with deliberate mistakes and reading the resulting messages.
- Help mechanisms, such as a contact link or search, appear in the same place across pages. Test by comparing footer or header help links between templates.
- Users are not asked to re-enter information already supplied earlier in the same process, unless it is essential. Test by stepping through a multipage form and noting any repeated fields.
Robust
- Markup uses semantic HTML elements (headings, lists, buttons) rather than generic divs styled to look like them. Test by inspecting the DOM structure and heading order.
- ARIA attributes are used only where native HTML cannot do the job, and roles match actual behaviour. Test with a screen reader to confirm announced roles match what the element does.
- PDFs and office documents are tagged, with a logical reading order and named form fields. Test by opening the document's tag tree in Acrobat or a similar tool.
- Components work with current browsers and assistive technologies, not just one combination. Test the same journey in at least two browser and screen reader pairings.
Pro Tip: Keep a shared spreadsheet mapping each checklist item to the template or component it applies to, so a fix in a shared component updates the status everywhere it's used.
What's new in WCAG 2.2 and where to focus first
WCAG 2.2 added nine new success criteria, and a handful of them carry the most practical weight for teams building or rebuilding a site today. Focus visibility (2.4.11) requires that a focused element is not entirely hidden by other content such as sticky headers or cookie banners, a common failure on modern layouts. Target size (2.5.8) sets a concrete rule: pointer inputs need a target area of at least 24 by 24 CSS pixels in most cases, with exceptions for inline text links and equivalent alternatives. Accessible authentication (3.3.8) removes the requirement for users to solve puzzles like transcribing distorted text from memory, pushing teams towards password managers, one-tap links or other cognitive-friendly options.
24 by 24 CSS pixels is the minimum target size WCAG 2.2 sets for most pointer interactions, meaning icon buttons, close crosses and small navigation controls often need resizing or extra padding to pass.
For prioritisation, treat focus visibility and target size as quick wins: they are usually CSS changes, testable in an afternoon with browser developer tools. Accessible authentication is a larger job because it can mean redesigning a login flow, so plan it as a discrete piece of work with its own acceptance criteria rather than folding it into a general accessibility sprint. Teams already close to WCAG 2.1 AA should treat the 2.2 additions as a short, separate audit pass rather than a full re-test.
Combine automated scans with manual and assistive-technology checks
A reliable testing workflow runs in stages, and skipping any of them leaves gaps that automated tools cannot see on their own.
- Run a discovery scan across the whole site with an accessibility scanner extension to surface obvious issues like missing alt text, poor contrast and empty links.
- Feed the same checks into a CI pipeline tool so new code is tested before it reaches production, catching regressions early.
- Have a developer triage the automated results, since many flagged items are false positives or need context to judge.
- Walk through key journeys manually using keyboard-only navigation and a contrast checker for anything the scanner could not verify.
- Confirm the same journeys with at least one screen reader, since W3C guidance is explicit that no single automated tool can determine accessibility on its own and many criteria require human judgement.
Rather than testing every page manually, sample deliberately: pick each unique template, any dynamic component such as a modal or accordion, uploaded PDFs, and the journeys that matter most commercially, like checkout or account sign-up. Practitioner testing guidance suggests automated checks commonly catch roughly 30 to 50% of accessibility issues, which means manual and assistive-technology testing is doing the majority of the verification work, not a formality on top of it.
When logging results, use consistent fields every time: a plain description of the problem, steps to reproduce it, a suggested fix, a severity rating, an owner and a target timeframe. Consistent reporting is what turns a one-off audit into something a team can actually act on.
Pro Tip: Store each finding with a screenshot and the exact CSS selector affected, so a developer can find and fix it without repeating the walkthrough.
Governing documents, third-party widgets and public reporting
Compliance programmes often stall on things outside the main site template, so build these into the checklist deliberately rather than treating them as afterthoughts.
- Check that PDFs and office documents are tagged, have a logical reading order and use named, labelled form fields rather than flat scanned images.
- Confirm every video has captions and every audio-only file has a transcript, checked against the spoken content rather than assumed correct.
- For third-party widgets such as chat tools or booking calendars, request accessibility test evidence in the contract before integration, and keep a documented fallback if the vendor cannot demonstrate it.
- Assign a named owner for the accessibility programme and set a review cadence, rather than leaving it to whoever last ran an audit.
- Publish an accessibility statement covering conformance level, known limitations and a contact route for reporting issues, in line with what UK public-sector accessibility regulations require for statements and monitoring, and keep it under regular review rather than static.
Where a fix is genuinely disproportionate, document the reasoning, the alternative provided and the date it will be reconsidered, rather than leaving the limitation unexplained.
Turning the checklist into sprint-level tickets
A checklist only works once it lives inside the team's actual workflow rather than a separate document nobody opens.
- Scope the site into templates and components rather than individual pages, since fixes usually apply at the component level.
- Map relevant success criteria to each template, using the WCAG quick reference to filter to what applies.
- Write a pass or fail acceptance criterion for each mapped item, worded so a tester needs no extra context to judge it.
- Add automated checks to the CI pipeline so obvious regressions are caught before release.
- Require manual sign-off from a second person, not the original developer, before marking a ticket done.
Each ticket should record the expected outcome, the exact test steps, a place to attach evidence such as a screenshot or recording, and a named reviewer. Bring in an accessibility specialist or run testing with assistive-technology users when a component is genuinely novel, such as a custom data visualisation or an unusual form pattern, rather than for routine items the checklist already covers. Track progress with a simple backlog count of open items by severity, reviewed at a fixed interval rather than only before a launch.
Pro Tip: Add "accessibility acceptance criteria met" as a required checkbox on every pull request template, so it can't be skipped under deadline pressure.
Making the checklist work on smaller sites
Accessibility works best when it's part of design and build from the start, not a fix applied after a site is finished. On smaller projects, that means checking colour contrast and heading structure while a layout is still in Figma, and testing keyboard access as components are built rather than at the end of a sprint. Because every site is built from scratch rather than adapted from a template, accessibility checks fit naturally into the same review before approving and paying for the finished site.
— Ar
Webnora as a managed route to an accessible website
Running this checklist properly takes time most small business owners don't have alongside the rest of their work, and that's the gap a managed build fills. This service designs and builds custom, lightweight websites for small businesses and freelancers, with accessibility considerations built into the design and development process rather than bolted on afterwards.
This is one route among several, not a claim that it replaces an in-house accessibility programme for larger organisations with complex platforms. What it does offer:
- A custom-built site rather than a recycled template, so accessibility fixes can be implemented more straightforwardly.
- The chance to review and approve the finished site before any payment is made, allowing review of the site before committing.
- Direct, personal communication with the person building the site, rather than a support queue.
If you'd rather hand the implementation work to someone else, take a look at Webnora's services to see what a custom build involves.
Where to check the source guidance
- WCAG 2.2 Recommendation
- WCAG 2.2 overview and quick reference
- Selecting web accessibility evaluation tools
- UK public-sector accessibility regulations
- Target size minimum, Understanding WCAG 2.2
Sources
- Selecting Web Accessibility Evaluation Tools
- Public Sector Bodies (Websites and Mobile Applications) Accessibility (Amendment) (EU Exit) Regulations 2022
- Testing for accessibility — practitioner guidance (University of Chicago)
FAQ
How do I check a website for WCAG compliance?
Run an automated scan first to catch obvious issues such as missing alt text or poor contrast, then follow it with manual keyboard testing and a screen reader walkthrough of key journeys. W3C guidance is clear that automated tools alone cannot determine compliance, so manual and assistive-technology checks are not optional extras.
What content actually needs to meet WCAG requirements?
Everything a user interacts with or needs to understand the page counts: text, images, forms, navigation, video and audio content, and documents like PDFs linked from the site. This includes third-party widgets embedded on the page, which should be checked or contractually required to provide their own evidence of testing.
How do I build a compliance checklist for my own project?
Map the WCAG success criteria relevant to your site against your actual templates and components, write a clear pass or fail acceptance criterion for each, and add automated checks to your build pipeline with manual sign-off before release. Keep the checklist living inside your ticketing system rather than as a static document reviewed once a year.
What does the WCAG 2.2 checklist cover that older versions don't?
WCAG 2.2 adds nine new success criteria, with the most commonly prioritised being focus visibility, target size and accessible authentication. Target size sets a concrete rule of 24 by 24 CSS pixels for most pointer inputs, while accessible authentication removes the need for memory-based puzzles like transcription tasks.