What the WCAG accessibility checker tests
The free website accessibility checker loads your home page and up to four more pages from the same website in a real browser. It then runs axe-core, the open source accessibility testing engine, against the rendered pages. This matters because many accessibility problems only become visible after a page has loaded its styles, scripts, menus, forms and interactive components.
The checker tests rules mapped to WCAG 2.1 and WCAG 2.2 at Levels A and AA. Results can include problems with colour contrast, missing text alternatives, form labels, page language, heading structure, keyboard related markup and ARIA. It also identifies criteria introduced in WCAG 2.2 where the automated rule can test them. W3C published WCAG 2.2 as a Recommendation in October 2023 and added nine success criteria compared with WCAG 2.1.
Automated testing is most useful as a repeatable first pass. It can expose defects that are easy to miss during everyday content updates and gives developers a concrete element to inspect. A clean automated result is not evidence that a site meets every WCAG requirement, because some criteria depend on meaning, context or real user interaction.
How to read your accessibility score and results
Each checked page receives an accessibility score out of 100, followed by an overall average across the pages tested. The score compares checks that pass with issues that fail and weights failures by severity: critical, serious, moderate or minor. It is a prioritisation aid, not a WCAG compliance certificate. Two sites with similar scores can still have very different barriers.
Start with the individual issues rather than the number alone. The results show the relevant WCAG Level A or AA criterion, place more serious findings first and provide a plain English fix with an example element from the page. That lets a developer move from a general warning to the actual HTML, component or content that needs attention.
Best practice findings are shown separately from WCAG failures. They can still be worth fixing because good document structure and predictable component behaviour make pages easier to maintain and use, but they should not be confused with a failed WCAG success criterion. Where a result is marked as WCAG 2.2, it highlights a requirement added in the newer version so teams still working from a WCAG 2.1 checklist can see what changed.
Why manual accessibility testing still matters
An automated WCAG checker cannot judge every barrier a person may encounter. It cannot reliably decide whether alternative text describes the purpose of an image, whether link wording makes sense in context, whether captions are accurate, whether instructions are understandable or whether a screen reader announcement is useful at the right moment.
Keyboard testing also needs a human. A page can have technically focusable controls and still be frustrating if focus moves in an unexpected order, disappears visually, becomes trapped in a menu or modal, or skips an important action. Screen reader testing can uncover similar problems with labels, status messages, dynamic content and reading order that are difficult to assess from markup alone.
For a fuller assessment, combine automated checks with keyboard use, screen reader testing and a review of representative journeys such as navigation, forms, checkout or account tasks. GOV.UK guidance for public sector websites also recommends checking a representative sample of pages and functionality rather than treating a single automated scan as the whole accessibility assessment. See our accessibility audit service for manual WCAG 2.2 AA testing.
What to fix after a WCAG check
Fix the issues that create the biggest barrier first. Critical and serious failures deserve early attention, especially when they affect navigation, form completion, essential information or controls that people cannot operate. Then work through moderate and minor findings, checking whether the same component appears across multiple pages. A single theme, template or reusable block change can sometimes remove the same defect site wide.
Retest after each group of changes rather than waiting until the end. Accessibility fixes can interact with styling and JavaScript, so a change that solves one issue should be checked for regressions elsewhere. Keep a record of what was changed and which WCAG criterion it addressed.
The checker can email a PDF report if you need a copy to share with colleagues or developers. If you need manual keyboard and screen reader testing, our Accessibility Audit is £549 and includes a prioritised, costed fix plan. For sites that change regularly, Accessibility Monitoring is £69 a month and combines monthly automated checks with human review of flagged issues.