UtilibyWritten by the Utiliby editorial team · Last updated October 13, 2026 · Rules and formulas reviewed October 2026
What this free HTML accessibility checker does
This free online HTML accessibility checker reads the HTML you paste and tells you what is likely to stop people using screen readers, keyboards and other assistive technology. It finds images without alt text, form fields without labels, empty buttons and links, skipped heading levels, a missing page language or title, invalid ARIA, blocked zoom, unnamed iframes, tables without headers and more. Every finding is mapped to a WCAG 2.2 success criterion and level, and comes with a plain-language fix and the offending code.
The results are sorted by severity and shown with a score, a donut chart of errors, warnings and notices, and a breakdown by the four WCAG principles. A built-in rules list and a manual-checks list show what the tool cannot test. Your HTML is parsed in your browser and never uploaded, so it is safe for unreleased pages and client work.
How to use the HTML accessibility checker
- Paste your HTML. A full page works best, but a template, component or snippet is fine. You can also open an .html file.
- Read the score and summary. The tiles show errors, warnings and notices and how many rules passed.
- Fix errors first. Each issue card gives the rule, the WCAG criterion, a description, how to fix it and up to four code examples.
- Filter. Show errors only to focus, or notices only to polish.
- Re-check. The page re-runs as you edit. Watch the score rise.
- Test the rest by hand. Open the Manual checks tab for keyboard, zoom, screen reader and captions tests.
- Export. Print to PDF, download the CSV or copy the summary for a ticket or report.
What the checker tests, with WCAG references
| Area | Examples of what is flagged | WCAG |
|---|---|---|
| Text alternatives | Missing alt, linked image with empty alt, file-name alt, SVG without a name, image map areas | 1.1.1 |
| Forms | Fields without labels, placeholder-only labels, ungrouped radio buttons, missing autocomplete | 1.3.1, 1.3.5, 3.3.2, 4.1.2 |
| Names for controls | Empty buttons and links, generic link text, unnamed iframes | 2.4.4, 4.1.2 |
| Structure | Skipped or empty headings, missing h1, list items outside lists, no main landmark | 1.3.1, 2.4.1 |
| Page | Missing lang or title, blocked zoom, meta refresh, missing doctype | 2.4.2, 3.1.1, 1.4.4, 2.2.1 |
| ARIA | Invalid role, unknown aria attribute, broken id reference, focusable aria-hidden | 1.3.1, 4.1.2 |
| Keyboard and focus | Positive tabindex, click handlers on divs, accesskey | 2.1.1, 2.4.3, 2.1.4 |
| Media and motion | Autoplay, no controls, no captions track, marquee and blink | 1.2.2, 1.4.2, 2.2.2 |
| Tables | Data tables without th, no caption | 1.3.1 |
The Rules tab lists all of them with their severity, so you can see exactly what is covered.
Alt text: the most common failure
Missing image alternatives are among the most common automated findings on the web. Screen readers announce an image with no alt attribute by reading its file name, such as IMG 2041 dot jpg, which is noise. The fix depends on the image: an informative image needs a short description of what matters in context, a functional image such as a linked logo or an icon button needs text that says what it does, and a decorative image should have an empty alt attribute (alt="") so it is skipped.
| Image | Good alt text | Poor alt text |
|---|---|---|
| Product photo | Blue ceramic mug with a wooden handle | IMG_2041.jpg |
| Logo linking home | Utiliby home | logo |
| Decorative divider | (empty alt) | divider image |
| Chart | Sales rose 20% from 2024 to 2025 (details in the table below) | chart |
The checker detects missing alt, empty-alt images inside links, file-name or filler alt text and very long alt text. It cannot tell whether the text is correct, so review it yourself.
Forms: labels, groups and autocomplete
A form control needs an accessible name. The best way is a visible <label for="id"> that matches the field's id, or a label that wraps the field. aria-label and aria-labelledby can name a control that has no visible label, such as a search box with only an icon. A placeholder alone is not enough. Related radio buttons and checkboxes should sit in a fieldset with a legend so the question is read before each option. Fields collecting personal data should use the autocomplete attribute (name, email, tel, street-address, postal-code) so browsers and password managers can help, which is required by WCAG 1.3.5 at level AA.
Headings, landmarks and page structure
Screen reader users move around a page by headings and landmarks. A single h1 names the page, h2 to h6 make an outline without skipping levels, and landmark elements (header, nav, main, footer) let people jump to the part they want. Several nav elements should each have a name, such as aria-label="Footer". The page itself needs a lang attribute so that the screen reader pronounces text correctly and a unique title that appears in tabs, history and search results.
ARIA: use it carefully
ARIA (Accessible Rich Internet Applications) adds roles, states and properties for custom components. The first rule of ARIA use is: if a native HTML element does the job, use it. A button element is a button for everyone; a div with role="button" must also be focusable and respond to Enter and Space. The checker finds the common ARIA errors that break things: roles that do not exist (often a typo), unknown aria- attributes, aria-labelledby and aria-controls that point to ids that are not there, and aria-hidden on content that can still receive focus, which creates a keyboard trap that screen readers cannot see.
Bad ARIA is often worse than no ARIA. If you are not sure, remove it and use native elements first.
How the score works
The score is a simple progress meter: it starts at 100 and subtracts 4 for each error, 2 for each warning and half a point for each notice. It is useful for comparing two versions of the same page and for seeing the effect of a fix, but it is not a WCAG conformance rating. Two pages with the same score can differ enormously in how usable they are, and a score of 100 only means that none of these automated rules fired.
What automated checking cannot do
Studies of accessibility testing tools consistently find that automated rules catch a minority to about half of barriers. They cannot decide whether alt text is meaningful, whether the reading order makes sense, whether focus is visible, whether a custom widget works with a keyboard, or whether captions are accurate. Rendered colour contrast, target size, motion and content clarity also need other checks. Use this tool as a quick first pass, and then complete the Manual checks list, test with a keyboard and a screen reader and, where possible, with disabled users.
Manual tests to do next
- Unplug the mouse. Tab, Shift+Tab, Enter, Space and arrow keys should do everything.
- Zoom to 200% and 400%. Content should reflow with no sideways scrolling.
- Turn on a screen reader. NVDA (free) on Windows, VoiceOver on Mac and iOS, TalkBack on Android.
- Check colour contrast of text and controls with the colour contrast checker.
- Check captions on every video.
- Read error messages in forms; they should say what went wrong and how to fix it.
Accessibility law and standards
Many laws point to WCAG: the Americans with Disabilities Act (through court decisions and Department of Justice guidance), Section 508 in the United States, the European Accessibility Act and EN 301 549 in the EU, the Accessibility for Ontarians with Disabilities Act, the UK Equality Act and Public Sector Bodies Accessibility Regulations. WCAG 2.2 Level AA is the most common target. This tool does not decide legal compliance. Treat it as a developer aid.
Privacy
Your HTML is processed by your browser's own parser. It is not uploaded, logged or shared, and scripts or external resources in the code are never loaded. Reloading the page returns the sample.
Related free tools
Use these free online tools together with this one:
- Check text and background colors with the color contrast checker.
- Write and check image descriptions with the alt text checker.
- Publish your accessibility commitments with the accessibility statement generator.
- Add structured data to your page with the schema markup generator.
- Make minified code readable before you test it with the code unminifier.
- Track the fixes you find on a kanban board.
Frequently asked questions
What does this HTML accessibility checker test?
It parses the HTML you paste and tests it against 48 rules covering text alternatives, form labels, button and link names, headings, page language and title, landmarks, ARIA, tables, media, frames, zoom blocking, focus order and more. Each finding is linked to the relevant WCAG 2.2 success criterion and comes with a suggested fix.
Is a clean result proof that my page is accessible?
No. Automated rules can find only a share of accessibility barriers. They cannot judge colour contrast of rendered styles, keyboard use, focus order, the quality of alt text and captions, or how a screen reader actually sounds. Use the Manual checks tab and test with real users.
Is my HTML uploaded?
No. The code is parsed in your browser with the built-in DOMParser. Scripts in the pasted code are never run, and nothing is sent to a server.
Can I check a live URL?
Not directly, because a browser tool cannot fetch other sites. Open the page, choose View Source or Save as, copy the HTML and paste it here. For pages built by JavaScript, copy the rendered HTML from the developer tools Elements panel.
What is the difference between errors, warnings and notices?
Errors are clear failures of a WCAG success criterion, such as an image with no alt attribute. Warnings are likely problems that need a human decision, such as generic link text. Notices are best-practice suggestions or things to review.
How is the score calculated?
The score starts at 100 and subtracts 4 points per error, 2 per warning and half a point per notice, down to zero. It is a quick guide to progress as you fix things, not a WCAG conformance rating.
What is the difference between this and tools like axe, WAVE or Lighthouse?
Those tools run in a live browser and can test rendered colours, visibility and computed accessible names. This tool is a lightweight static check of the code you paste, which makes it fast, private and good for templates, snippets, emails and CMS output. Use both.
Which WCAG version does it use?
WCAG 2.2, the current W3C Recommendation. It lists the success criterion number and level (A, AA or AAA) beside every rule.
Why does it say my fragment skipped page-level rules?
If your code has no html element, the tool treats it as a fragment and does not test the page language, title, viewport, doctype, main landmark or h1, because those belong to a full page.
What is alt text and when should it be empty?
Alt text is the text alternative for an image. Informative images need a short description. Purely decorative images should have alt="" so screen readers skip them. A missing alt attribute is different: the screen reader may read the file name.
Why are placeholders not enough as labels?
Placeholders vanish as soon as you type, often have low contrast and are not reliably announced. A visible label stays on screen and is the best accessible name for a form field.
What does 'Heading levels are skipped' mean?
It means a heading jumps down more than one level, such as an h2 followed by an h4. Screen reader users navigate by heading level, so a logical outline helps them. Style headings with CSS rather than choosing a level for its size.
Does it check colour contrast?
No, because contrast depends on rendered styles. Use the free colour contrast checker on this site for text and background colours.
What are ARIA rules and should I add ARIA everywhere?
ARIA adds roles and properties for custom widgets. The first rule of ARIA is to use native HTML when you can. The checker flags invalid roles, unknown aria- attributes, broken id references and focusable content hidden with aria-hidden.
Can it check an HTML email or a CMS template?
Yes. Paste the markup and check alt text, link text, headings, tables and language. Email clients limit some features, so keep structure simple.
Can I use the results in an audit or accessibility statement?
Use them as one input. A formal audit also needs manual and assistive technology testing, and an accessibility statement should describe your real conformance status.
What can I print or save?
Print / save as PDF, CSV and Copy summary work on the tab you are viewing. The CSV lists every issue with its WCAG criterion, code snippet and suggested fix.
Sources and further reading
- W3C Web Content Accessibility Guidelines (WCAG) 2.2, for success criteria numbers, levels and techniques.
- W3C WAI-ARIA 1.2 specification and the ARIA Authoring Practices Guide, for valid roles, states and properties.
- WHATWG HTML Living Standard, for element semantics such as label, fieldset, table headers and landmarks.
- W3C Accessibility Conformance Testing (ACT) rules, which guide how automated checks map to success criteria.
Sources were consulted in October 2026. Standards and rules can change, so always check the official page for your situation.