HTML Accessibility Checker

Many accessibility failures are visible in the markup itself: an image with no alternative text, a field with no label, a button that says nothing to a screen reader. They keep some visitors from using a page, and they are cheap to fix when found early. This checker reads a page or a component’s HTML, applies 22 rules based on WCAG 2.2 and ARIA, and lists every problem with the criterion it breaks.

How the check works

The HTML you paste is parsed by the browser’s own parser, so it is repaired the way a real page would be. Rules then look at the resulting tree. Each finding shows whether it is an error, something that will block or mislead some users, or a warning, a likely problem or bad practice, plus a snippet of the element so you can find it. Rule names follow axe-core, the engine behind many accessibility tools, which makes them easy to look up.

Images, forms and controls

Images need an alt attribute: descriptive text when the image carries meaning and an empty alt="" when it is decoration. File names used as alt text, such as jacket.jpg, are flagged. Form fields need a programmatic label, either a label element linked with for and id, a wrapping label, aria-label or aria-labelledby; a placeholder alone does not count. Buttons and links need an accessible name from their text, image alt or ARIA label, and vague link text like “click here” is a warning because screen-reader users often browse a list of links out of context.

Structure and landmarks

Headings should not skip levels, so an h3 right after an h1 is flagged, and empty headings are errors. For a whole page, the rules expect a language on the html element, a title, an h1 and a single main landmark so assistive technology users can jump straight to the content. These page-level rules only run when the input includes an html element, so a pasted component is not blamed for lacking them.

ARIA and keyboard use

Invalid role names are errors, since a misspelled role is ignored or misread. An aria-hidden="true" element that contains something focusable hides it from screen readers while keyboard users can still reach it, which is reported. Positive tabindex values change the natural focus order and are a warning. Duplicate ids break label and ARIA references, and clickable div or span elements without a role and tabindex are flagged because they cannot be operated with a keyboard.

A worked example

The Sample is a small shop page with deliberate mistakes. It produces 10 errors and 6 warnings: the missing lang attribute, the logo image without alt, the file name used as alt text, an email field with only a placeholder, an empty button, an icon-only cart link, a clickable div, the h1-to-h3 jump, a missing main landmark, duplicate note ids, an iframe without a title, an invalid buton role on an aria-hidden block containing a link, a positive tabindex and a table without header cells. Each finding names the element.

What markup checks cannot find

Static analysis cannot judge whether alt text is meaningful, whether the reading order makes sense, whether colour contrast is sufficient, whether focus is visible, or what scripts do after load. Automated tools overall detect only a minority of accessibility issues. Treat a clean report as a starting point.

A practical routine

Fix the errors here, then tab through the page with a keyboard, check contrast with the Contrast Checker, zoom to 200 percent, and try a screen reader such as NVDA or VoiceOver on the main task. Repeat after changes to components, not just before launch.

Related tools

• Contrast Checker tests text and background colours against WCAG ratios.
• HTML to JSX converts the fixed markup for React.
• CSS Specificity Calculator explains styles that hide or show focus outlines.
• CSP Hash Generator hardens the same page against script injection.