HTML Accessibility Checker
Find the accessibility barriers that can be detected in a page’s code. The checker runs more than twenty rules mapped to WCAG 2.2 success criteria: images and image buttons without alt text, form fields without labels, buttons and links without an accessible name, empty headings and skipped levels, a missing lang attribute or title, duplicate IDs used by labels, positive tabindex values, focusable content hidden from screen readers, invalid ARIA roles, frames without titles, data tables without headers, disabled zoom, timed refreshes and autoplaying sound.
- Encrypted connection
- No sign-up
- Free to use
How to use HTML Accessibility Checker
- Enter a page URL (or paste its HTML).
- Click “Check accessibility”.
- Fix the failed checks with the examples shown.
- Test with a keyboard and a screen reader.
HTML Accessibility Checker features
WCAG mapping
Each rule names its criterion.
Examples
The offending HTML for each problem.
Accessible names
Buttons, links and fields.
ARIA checks
Roles, aria-hidden and labelledby.
Passed checks
Listed for the record.
Paste mode
Analyse HTML you paste, e.g. a staging page.
When to use HTML Accessibility Checker
- Quick checks during development.
- Reviewing templates and components.
- Preparing for a full accessibility audit.
- Checking pasted HTML from a CMS.
HTML Accessibility Checker FAQ
Does passing mean the page is accessible?
No. Automated checks find roughly a third of the barriers. Keyboard use, focus visibility, colour contrast, meaningful text and screen-reader behaviour need manual testing.
Why is a placeholder not a label?
It disappears while typing, is often low contrast and is not reliably announced. Use a visible label element.
Does it check colour contrast?
Not in the page, because that needs the rendered styles. Use the WCAG Contrast Checker for colour pairs.
Is this a legal compliance report?
No. It is a technical aid. Legal requirements such as the ADA or the European Accessibility Act need a full review.
Does passing all checks mean my site is WCAG compliant?
No. Automated checks cover only part of WCAG. Manual testing is needed for criteria such as meaningful alt text, focus order and understandable content.
Barriers you can find in code
The rules focus on failures that are both common and reliably detectable in HTML: missing text alternatives (1.1.1), missing structure (1.3.1), missing names for interactive elements (4.1.2), unhelpful link text (2.4.4), focus order (2.4.3), a page title and language (2.4.2, 3.1.1) and settings that stop people from zooming or controlling time and sound.
Each failed rule lists up to four example elements so you can find them in the source quickly. Fix the failures first; warnings such as a missing main landmark or skipped heading levels are worth fixing but do not always block access.
The checker reads the HTML as served; components that are built by JavaScript after loading are not included.
The checker runs more than twenty rules that can be detected in code and maps each to a WCAG 2.2 success criterion: missing alt text, form fields without labels, buttons and links without an accessible name, empty headings and skipped levels, a missing lang attribute, missing page title and more.
Each finding shows the element and how to fix it, which makes it easy to turn results into tasks. Fix the problems that block people completely first – unlabelled form fields, images that carry information without alt text, controls that cannot be named – then the structural issues.
Automated tools can only find a part of all accessibility problems; whether alt text is meaningful or the reading order makes sense needs a human. Combine this check with keyboard testing and, ideally, feedback from people who use assistive technology.