Answer in brief
Work through WCAG 2.2 level AA in this order: images and headings, colour contrast, keyboard and focus, forms, video captions, then testing by hand and with a screen reader. Fix problems in the shared templates, not page by page, and repeat the checks whenever the site changes. Automated tools find only part of the problems.
Where a website accessibility checklist comes from
A website accessibility checklist is only as good as the standard behind it, and for the web that standard is WCAG, the Web Content Accessibility Guidelines of the W3C. Version 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria and removed one, 4.1.1 Parsing, which the W3C lists as obsolete. GOV.UK, for one, tests public services against level AA, and this list follows the same level.
The checklist finds problems; it is not a certificate. The W3C’s own Easy Checks page says that these quick checks cover only a few issues and that passing them does not mean a page is accessible. None of it is legal advice, and whether a law applies to your business is a question for a lawyer who knows your country.
The six failures that appear on almost every home page
The WebAIM Million, an annual automated scan of one million home pages, reports for 2026 that 95.9% of the pages had detected WCAG failures, an average of 56.1 errors per page. Six problems lead the list. Low contrast text appeared on 83.9% of pages, missing alternative text on 53.1%, missing form labels on 51%, empty links on 46.3%, empty buttons on 30.6% and a missing document language on 13.5%.
None of these needs a redesign. They are habits in how templates and content are made: a button that holds only an icon, a link that holds only an image, grey text on a lighter grey. They repeat across pages because the templates repeat, which is also why they can be fixed in bulk.
Images, headings, page titles and language: the content checks
Start with images. The W3C’s Easy Checks ask whether each image has a short text description that conveys its purpose, because people who use a screen reader cannot see it. WebAIM adds that a decorative image should carry an empty alt attribute so that it is skipped, and that an image which is also a link needs alt text saying where the link goes. Write for the job the image does, not for what it shows.
Next come the page title and the headings. The title appears in the browser tab and is one of the first things a screen reader announces, so each page needs its own. Headings should work like a table of contents, because screen reader users often move through a page by headings. WebAIM asks for real heading elements, not bold text in a larger font, and for headings that are informative: three sections all called Details tell nobody where they are.
Then the language of the page. A lang attribute on the html element lets assistive technology pronounce words correctly. The scan above found it missing on 13.5% of home pages, which makes it one of the cheapest fixes on the list. One edit in the base template covers every page built on it.
Colour contrast, links and zoom: the checks you can measure
Contrast is where the checklist gives numbers. WebAIM’s summary of WCAG lists 4.5:1 for normal text and 3:1 for large text at level AA, and 3:1 for icons, form controls and focus indicators. A link that differs from the surrounding text only by colour needs 3:1 against that text plus another cue, such as an underline on hover and focus. Run a contrast checker on the real palette, including the grey help text and the text laid over photographs.
Zoom is the second measurable check. The Easy Checks ask that text and images enlarge when you zoom and remain legible and usable. Try the page at a high zoom level and on a phone, and watch for cut-off text, overlapping buttons or a menu that can no longer be opened.
Keyboard, focus and target size: using the site without a mouse
Put the mouse aside and press Tab. WCAG asks that all functionality works with a keyboard and that focus is never trapped on one element, and the Easy Checks add a visible indicator that moves with every press. The first stop should be a skip link that jumps over the menu to the main content.
WCAG 2.2 sharpened this area. Criterion 2.4.11 says a focused element must not be entirely hidden by other content, which is what a sticky header or a chat widget does to the field you are typing in. Criterion 2.5.8 asks for pointer targets of at least 24 by 24 CSS pixels unless they are adequately spaced. Criterion 2.5.7 asks for a single-pointer alternative to any dragging action, such as a slider that can also be set with buttons.
Focus order matters as much as visibility. WebAIM lists 2.4.3, a logical and intuitive order, and 3.2.1, which says that receiving focus must not trigger a substantial change in the page. Tab forward through each template, go back with Shift and Tab, and note every place where you lost track of where you were.
Forms and video: labels, errors, captions and transcripts
Forms are where a visitor becomes a customer. Each field needs visible text that says what to enter, tied to the field in the code, which WebAIM lists under criteria 1.3.1 and 3.3.2. Required fields should be marked, and errors should be identified clearly and come with a suggestion for correcting them.
WCAG 2.2 added two rules that touch forms. Redundant Entry, 3.3.7, says people should not have to type again information they already gave in the same process. Accessible Authentication, 3.3.8, says a login step must not depend on a cognitive test unless there is an alternative or support. A checkout that asks for the delivery address twice fails the list.
Video and audio have their own checks. Prerecorded video needs synchronized captions under 1.2.2, audio-only content needs a text transcript, and where important visual information is missing from the soundtrack, the video needs audio description. The Easy Checks describe captions as synchronized text of speech and important non-speech sounds.
Testing with tools, a keyboard and a screen reader, then every release
Automated tools cover many pages quickly, and they are not enough. GOV.UK’s service manual says that you will miss some issues if you only do automated testing, and the W3C says that tools cannot do everything and can sometimes give incorrect results. Use them for the repeated, mechanical errors. Then check by hand whether alt text is meaningful and whether an error message helps.
Next, use the site the way a person with assistive technology would. GOV.UK expects testing with screen readers and speech recognition software and recommends doing it yourself where possible. You do not need every page; GOV.UK’s guidance advises testing a sample that shows the variation in content and functionality.
A fixed site does not stay fixed. GOV.UK’s service manual says to run tests every time a new feature is added, and the same holds for a banner, a new form or a plugin. Give one person the job of re-running the checks before each release and write the result down. GOV.UK’s guidance for public-sector sites also asks for an accessibility statement in plain English, reviewed at least once a year; ask a specialist whether any such rule covers you.
Ordering accessibility fixes: what to prepare and what you get
On a small site you can run this list yourself in a few days. Order the work when the list is long, when the fixes sit in code you do not touch, or when you need a record of what changed. Prepare the address of the site, a list of key templates such as the home page, a content page, a form and the checkout, and the results of your own checks or of an audit you already have.
VITON13 Studio sells this work as two packages. Accessibility fixes means that the issues from the audit are corrected in your code and content: fixes in templates and code, corrections such as alt text, headings and link names, and a re-test after the changes. Before you pay, you get a free draft: one fixed template, shown on a staging copy of your site. The price is fixed, from $213, and the work takes 7–15 working days.
Accessibility monitoring covers what a one-time list cannot: new pages stay accessible as the site changes. It includes a monthly re-check of new and changed pages and a short report with what to fix, and fixes are quoted separately when new issues appear. It costs $13/mo and can be cancelled with 30 days’ notice, and its free draft is a sample report on one page of your site. Whether the result is enough for any legal requirement remains a question for your lawyer.
Practical checklist
- Give every image meaningful alt text, or an empty alt when it is only decoration.
- Measure contrast: 4.5:1 for normal text, 3:1 for large text and interface parts.
- Tab through every key template and confirm that focus is visible and never hidden.
- Tie a visible label to each form field and mark the required ones.
- Re-run the list before every release and keep the result in writing.
Questions and answers
How long does it take to run a website accessibility checklist?
It depends on the number of templates more than the number of pages. GOV.UK advises testing a sample that shows the variation in content and functionality: the home page, a content page, a form and the checkout. Pages built on one template share their defects.
Is WCAG 2.2 level AA the level a small business should aim for?
It is the level GOV.UK uses for public services, and it is the usual target of checklists. Which level a law requires of your business is a question for a lawyer in your country, not for a checklist.
Can an automatic scanner replace the manual checks?
No. GOV.UK’s service manual says you will miss some issues with automated testing alone, and the W3C says tools cannot do everything. A scanner cannot judge whether alt text is meaningful or whether the keyboard order is sensible.
What changed in WCAG 2.2 compared with the earlier version?
The W3C lists nine new success criteria, among them focus not obscured, dragging alternatives, target size, consistent help, redundant entry and accessible authentication. The old criterion 4.1.1 Parsing was removed as obsolete.
Do all videos on my website need captions?
WebAIM’s summary of WCAG lists captions for prerecorded video at level A and for live media with audio at level AA. Audio-only files need a transcript. Whether a specific law applies to your videos is a question for a specialist.
