HTML Accessibility Checker — Automated WCAG 2.2 Checks for Your Markup

What is accessibility testing?

Accessibility testing checks whether people with disabilities can perceive, understand, navigate and operate a product — with a keyboard, a screen reader, magnification, captions or voice control. It combines automated rule checks, manual keyboard and screen reader passes and structured evaluation against WCAG 2.2 success criteria, because tools alone cannot determine whether a product is accessible.

Read the guide: Accessibility Testing

How to use HTML Accessibility Checker

Copy the page's HTML: View source for a server-rendered page, or for a page built by JavaScript, DevTools → Elements → right-click <html> → Copy outerHTML. A component's markup works too.
Paste it (or choose a saved .html file) and choose the contrast target, AA or AAA.
Press Check accessibility. Start with the FAIL rows of "Issues found"; each one says how to fix it.
Work through "Still to check by hand" with a keyboard and a screen reader — those barriers cannot be seen in markup.
Re-run after fixing, and keep the Markdown or JSON report with the test evidence.

HTML Accessibility Checker features

30 automated rules from WCAG 2.2 and the W3C ACT rules, each mapped to its success criterion or marked as best practice
Accessible names computed from the markup the way assistive technology does: aria-labelledby, aria-label, <label>, alt, legend, content, then title and placeholder
Text alternatives, form labels, button and link names, vague link text ("click here", "read more" — also in Arabic and Hindi), headings, IDs and references, ARIA roles and aria-hidden on focusable content
Page-level checks for full documents: language, dir="rtl" for Arabic and other right-to-left languages, title, main landmark, h1, zoom and timed refresh
Contrast ratio of text whose colours are set inline, against AA (4.5:1 / 3:1) or AAA (7:1 / 4.5:1), with large-text rules
Results by rule (PASS, FAIL, WARN, N/A), every issue with its element, detail and fix, the checks that still need a person, and Markdown and JSON reports

HTML Accessibility Checker example

An Arabic landing page with common mistakes

Input:

Example page: <html lang="ar"> without dir, viewport maximum-scale=1, a logo image without alt inside the home link, an icon-only menu button, an email field labelled only by its placeholder, a label for="phone-number" pointing to id="phone", two radio buttons without a fieldset, a clickable <div>, an untitled iframe and grey text #9aa0a6 on white

Output:

10 failures, 6 warnings. FAIL: zoom limited (1.4.4) · image without alt (1.1.1) · link without a name (2.4.4) · button without a name (4.1.2) · 3 fields without labels (1.3.1, 4.1.2) · label for="phone-number" — no element has this id · iframe without a title · contrast 2.64:1, needs 4.5:1 (1.4.3). WARN: lang="ar" without dir="rtl" · placeholder-only label (3.3.2) · "Read more" link text (2.4.4) · h1 followed by h3 · radio group not grouped · clickable div not keyboard operable (2.1.1)

When to use HTML Accessibility Checker

Checking a component or template before code review, without installing a browser extension
Triaging an accessibility bug report: confirming a missing label or a broken aria-labelledby reference in the delivered HTML
Teaching what common WCAG failures look like in markup, with the criterion and the fix next to each
Reviewing Arabic pages for the language and direction attributes that screen readers and layout depend on

Frequently asked questions about HTML Accessibility Checker

Does passing these checks make my page WCAG compliant?

No. Automated rules find only part of the barriers — a missing label, an empty button, an invalid role. Whether alt text is meaningful, whether everything works with a keyboard and a screen reader, and contrast set by stylesheets need a person. The report lists those manual checks after the results.

Which rules does the checker run?

30 rules: text alternatives, form labels and placeholder-only labels, button and link names, link purpose, page language and dir="rtl" for Arabic, page title, headings, duplicate IDs and broken references, ARIA roles, aria-hidden on focusable content, positive tabindex, frame titles, table headers, list structure, radio groups, zoom, timed refresh, autoplaying audio, mouse-only click handlers, blinking text and inline-colour contrast. Each maps to its WCAG 2.2 success criterion or is marked best practice.

How is colour contrast checked?

When an element's text colour and background colour are both set in inline style attributes (on the element or an ancestor), the checker computes the WCAG contrast ratio and compares it with 4.5:1 (3:1 for large text), or 7:1 and 4.5:1 for AAA. Colours from stylesheets are not visible in HTML alone, so those elements are counted as "not measured" rather than passed.

Can I check a page built by JavaScript?

Yes: open the page, wait until it has rendered, then in the browser's developer tools right-click the <html> element in the Elements panel and choose Copy → Copy outerHTML, and paste that. View source shows only the HTML before scripts ran.

Is my HTML sent anywhere?

No. It is parsed by your browser's own HTML parser in an inert document — scripts do not run and images do not load — and nothing is uploaded.

Technical notes

The HTML is parsed by the browser's own HTML parser (DOMParser) into an inert document: unquoted attributes, implied end tags and other real-world markup are read exactly as a browser reads them, scripts never run and images never load. Elements hidden with hidden, aria-hidden="true", display:none or visibility:hidden in inline styles are excluded from the rules about visible content.

Accessible names follow the order of the W3C Accessible Name computation, simplified: aria-labelledby, aria-label, the native label (<label for>, a wrapping <label>, alt, legend, value), the element's content for buttons, links and headings, then title and, for fields, the placeholder — which is reported, because it disappears when the visitor types.

Contrast uses the WCAG relative-luminance formula. It is computed only when both the text colour and the background are set in inline styles on the element or an ancestor, and the background is a solid colour; text is large at 24 px, or 18.66 px when bold. Everything else is counted as "not measured", never as a pass.

Limitations and methodology

Automated rules cannot decide whether a page is accessible or WCAG conformant. They cannot judge whether alt text is meaningful, test keyboard behaviour and focus, or hear what a screen reader announces.

Stylesheets, computed layout and scripts are not available from HTML alone, so contrast set in CSS, focus visibility, reflow at 320 px, target sizes and dynamic changes are listed as manual checks.

The accessible-name computation is a faithful simplification of the specification, not every edge case of it (for example, CSS-generated content and embedded controls inside names are not computed).

Security and privacy

The HTML is parsed and checked in your browser; nothing is uploaded. The document it builds is inert: no script in it runs and no resource it references is requested.

References

Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)W3C's entry point for accessibility evaluation: why to evaluate early and throughout development, and how manual checks, tools and user involvement fit together.
WCAG Evaluation Methodology (WCAG-EM) 2.0W3C · 2026The W3C method for evaluating a whole website against WCAG: define scope, explore, select a representative sample, audit it and report.