Accessibility Checker
Enter a page address to check for missing alt text, unlabelled fields, empty links and buttons, heading and landmark problems and more, each tied to a WCAG 2.2 criterion.
Questo contenuto è in inglese.
Esempi svolti
Checking a shop homepage
https://shop.example.com typed into the address box
(Illustrative) Findings from the page as first delivered: 3 images without text alternatives, 1 form field without a label and 2 links with no text. Each finding shows where it was found.
The check reads the HTML only, so colour contrast and keyboard use still need a person to test them.
Simple page with few issues
https://example.com/about typed into the address box
(Illustrative) No findings from the automated checks, with a note that the page still needs manual testing.
A clean result means the automated checks found nothing, not that the page is fully accessible.
Informazioni su Accessibility Checker
An accessibility checker looks for the problems that stop some people using a web page, such as images without alt text, form fields without labels, buttons and links with no name, a missing page language, headings that skip levels or a viewport that blocks zooming. Enter a page address and the page is read as it is first delivered. Every finding names the WCAG 2.2 criterion it relates to, how serious it is, how many times it occurs and up to three examples taken from the page. It is written for site owners and developers who want clear, practical pointers rather than a long technical report.
Each finding also comes with a plain explanation of what to do. Problems are sorted with the most serious first, and checks that found nothing are listed too, so you can see what was covered. This is a quick, static check. It cannot test colour contrast, keyboard use or how a screen reader reads the page, and it does not see anything added by scripts after the page loads, so it is a starting point and not a full audit. Examples are shortened and escaped, so you can see which part of the page to look at.
Come usare Accessibility Checker
- Enter the full address of the page you want to check.
- Select Check page.
- Read the note on what the check cannot cover.
- Start with the high severity findings and use the examples to find them.
- Fix, run the check again, then test the page by keyboard and with a screen reader.
Usi comuni
- Checking a new page before it goes live
- Finding quick wins to improve an existing site
- Preparing for a fuller accessibility review
- Giving developers a list of fixes with WCAG references
- Checking a template after a redesign
Domande frequenti
What can this checker find?
It finds problems that can be seen in the page code, including a missing language, a missing or empty title, images with no alt text, unlabelled form fields, unnamed buttons and links, vague link text, heading and landmark problems, duplicate ids, positive tabindex, a missing skip link, autoplay, untitled frames, tables without headers, blocked zoom and timed refreshes.
What can it not find?
It cannot test colour contrast, keyboard operation, visible focus, the order of content in practice, or how a screen reader announces the page. It also cannot see content built by scripts after loading. Many serious problems fall into those groups, so a person should test the page as well.
Is a clean result the same as being accessible?
No. A clean result means none of these automatic checks found a problem. Automated tools find only part of all accessibility issues, so a page can pass every check here and still be hard to use. Treat it as a good first step before testing with real assistive technology.
What do the severity levels mean?
High means a problem that can stop someone completing a task, such as a button with no name or a form field with no label. Medium means it is likely to cause difficulty. Low covers advice and best practice, such as vague link text. Fix high items first, then work down.
Which WCAG version is used?
The criteria numbers refer to WCAG 2.2. Where a check relates to a best practice rather than a strict requirement, such as using only one main heading, the finding says so. The old parsing criterion was removed in 2.2, so duplicate ids are tied to name, role and value instead.
Why does a page built with scripts show very little?
The check reads the code the server delivers. If a page is mostly built by scripts after it loads, the delivered code can be almost empty, and the result will say that little content was found. In that case a test in a real browser with assistive tools will give a better picture.