Automated first pass
A scanner can quickly flag many code, naming, contrast and structure problems. It cannot decide whether the whole experience works.
WCAG 2.2 for website owners
Work through real customer journeys, use automation for the checks it can make reliably, and keep human review where context decides the answer.
How to use this checklist
Start with your homepage and the path to enquiry, booking, signup or checkout. Check representative templates, record what failed, repair the shared source, and repeat the same journey.
A scanner can quickly flag many code, naming, contrast and structure problems. It cannot decide whether the whole experience works.
Use keyboard, zoom, reflow and task-based review where sequence, meaning and usability depend on context.
Bring in accessibility expertise for assistive-technology journeys, media alternatives and a formal conformance position.
Website-owner checklist
These checks translate common WCAG 2.2 A and AA concerns into an operating list. They do not replace the complete standard or its applicability notes and exceptions.
Start with the information people need to perceive and navigate the page.
Decorative images should be ignored by assistive technology; informative images need text that serves the same purpose in context.
Check normal text and large text in every state, including errors, placeholders, disabled controls and text placed over images.
Headings should describe the sections beneath them. Visual size alone should not create the page outline.
At narrow widths and high zoom, content should remain available without overlapping, clipping or forcing two-dimensional scrolling except where it is genuinely necessary.
A link name should explain its destination or action from its text and immediate context, rather than relying on “read more” everywhere.
A form is only accessible when people can understand, complete and recover from it.
Visible labels, instructions and required-state cues must stay associated with the right input after validation runs.
Do not rely on colour alone. Put a useful message beside the field and provide a summary when the form is long or the error may be off-screen.
After submission, loading, filtering or adding to a basket, confirm the result without forcing keyboard or screen-reader users to hunt for it.
Within one process, auto-populate or let people select information they have already entered unless repetition is essential.
Password, one-time-code and account-recovery steps should work with password managers, paste and accessible alternatives to cognitive tests.
Test the complete task, not merely whether individual controls receive focus.
Menus, dialogs, carousels, filters, checkout and account controls need a logical route with no keyboard trap.
The focused control needs a clear indicator and should not disappear behind sticky headers, cookie banners or open overlays.
Tab order should follow the intended reading and interaction sequence, especially after content opens, closes or updates.
Anything completed by dragging should also have a simple pointer-operated alternative, such as buttons for moving or reordering an item.
Review crowded icon rows, pagination, close controls and adjacent links. WCAG 2.2 Level AA includes a minimum target-size criterion with defined exceptions.
People need equivalent information and enough control over moving or time-sensitive experiences.
Captions should include the dialogue and meaningful audio needed to understand the content; autogenerated text needs a human accuracy check.
If important information is only visual, provide it through audio description or an equivalent alternative that preserves the experience.
Carousels, animation, tickers and refreshes should not compete indefinitely with reading or interaction.
Do not publish rapidly flashing content. Motion triggered by device movement should have an accessible control unless the motion is essential.
Where a session or task expires, people generally need notice and a way to extend it unless a WCAG exception applies.
For each journey, record the page or template tested, the date, automated findings, manual checks, fixes made and the re-test result. A repeated failure in a header, form component or theme belongs in the shared source, not on a page-by-page patch list.
Keep unresolved manual questions visible. “No automated issues found” and “this journey works for people using assistive technology” are different statements and need different evidence.
ClearSite's scan and verified-fix evidence record can preserve the automated part of that history. It is not a full accessibility evaluation.
The boundary
This is not a complete WCAG conformance audit. WCAG conformance depends on the full applicable success criteria, complete processes and pages, supported accessibility technologies, and any relevant exceptions.
ClearSite is a diagnostic and guidance tool. It does not determine legal compliance, provide legal advice, or replace manual testing and specialist judgement.
Use the official W3C WCAG 2.2 Quick Reference as the primary route to every success criterion, technique and failure.
Scan one important page, repair what the automated layer finds, then complete the manual checks for the journey.
Run the free scanNeed the testing boundary first? Read what automated accessibility testing can and cannot find, then use the tested accessibility issue repair guides for common findings.
Primary guidance consulted: W3C Web Content Accessibility Guidelines 2.2, W3C How to Meet WCAG Quick Reference, and W3C WAI Easy Checks.