Check HTML accessibility online with Calzyra's free Accessibility Checker. Find common accessibility issues, review affected markup, and get practical suggestions for improvement.
This checker reads the markup, so it cannot measure colour contrast or keyboard behaviour — for contrast ratios use the WCAG contrast checker. Paste the page source (View Source, then copy) — this tool checks the HTML you provide and does not fetch URLs. Everything runs in your browser; nothing is uploaded.
What this tool can do
Image Alt Text
Flags <img> elements with no alt attribute
Form Labels
Finds inputs, selects and textareas with no accessible name
Empty Links & Buttons
Interactive elements with nothing to announce
Heading Structure
Empty headings and skipped heading levels
Language & Title
Missing lang attribute and missing document title
ARIA & Landmarks
Misused aria-label, duplicate ids and unnamed landmarks
Score & Severity
Errors and warnings with line, column and a fix for each
Filter by Rule
Show or hide findings rule by rule
Methodology and approach
The checker parses the HTML with an HTML-aware parser, then walks the tree applying a fixed set of accessibility rules: missing image alt text, unlabeled form controls, empty links and buttons, empty or skipped headings, a missing document language or title, duplicate ids, unnamed landmarks, misuse of aria-label, tables without header cells and autoplaying media. Each finding carries its severity, its line and column, and a concrete fix, and the score is computed from the distinct rules that fired.
An HTML accessibility checker examines markup for the barriers that commonly stop people using assistive technologies - screen readers, magnifiers, voice control and keyboard-only navigation - from using a page. It looks for the problems the document states outright: an image with no alt text describing it, a form field with no label, a button with nothing to announce, a heading structure that skips a level, a missing document language.
This checker parses your HTML with a real HTML-aware parser and walks the resulting tree, applying a fixed set of rules to each element it finds. Every finding names the rule that fired, the line and column it sits on, whether it is an error or a warning, and a concrete way to fix it. The analysis runs entirely in your browser; the markup is never uploaded.
Paste the HTML you want to check into the editor - the full page source or a fragment both work. Press Check Accessibility, or Ctrl+Enter, to run the analysis. The summary shows a score out of 100 with a letter grade, then three counts: accessibility errors, accessibility warnings, and the total number of issues including ordinary HTML validity problems.
Open the findings list to review each problem with its exact position and a suggested fix. The Show/hide rules control filters the list rule by rule, so you can work through one pattern at a time - every missing alt attribute, for instance, without the other findings in the way. If the markup cannot be parsed at all, the tool reports where the parser stopped and keeps your input untouched so you can fix it in place.
To check a live page, open its source in the browser (View Source), copy the HTML and paste it here. The checker deliberately does not fetch URLs: it analyses the markup you give it, which also means nothing you paste leaves your device.
Missing image alternatives are the most frequent finding. An <img> with no alt attribute leaves a screen reader to announce the file name, so the information the image carries never reaches the reader. An empty alt="" is correct for a decorative image; a missing alt is not.
Unlabeled form controls are the second. An <input>, <select> or <textarea> with no associated <label>, aria-label or title is announced by its type alone - "edit text" - so the reader cannot tell which field they are in. Buttons and links with no accessible text have the same effect on actions and navigation.
Structure problems come next: an empty heading that appears in the outline announcing nothing, a heading level that jumps from h1 to h3, a document with no lang attribute so the screen reader cannot pick a voice, a page with no title, duplicate ids that break label associations, landmarks with no unique name, aria-label placed on a plain div where nothing will announce it, a table with data cells but no header cells, and video or audio that starts playing on its own.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<header>
<nav><a href="/">Home</a></nav>
</header>
<main>
<h1>Welcome</h1>
<h3>Getting started</h3>
<img src="hero.jpg">
<p><a href="/docs"><img src="icon.png" alt=""></a></p>
<input type="text" name="email">
<button type="submit">Send</button>
<button></button>
<iframe src="https://example.com/embed"></iframe>
<table>
<tr><td>42</td></tr>
</table>
</main>
</body>
</html>Score: 37/100 (grade D)
4 errors, 5 warnings, 1 additional HTML validity issue
21 elements checked.
Warning Line 2, column 1 [missing-lang]
The <html> element has no lang attribute, so a screen reader cannot choose a voice for the page (WCAG 3.1.1).
How to fix: Add the document language to the root element, for example <html lang="en">.
Error Line 2, column 1 [missing-title]
The document has no <title> with text content. The title is the first thing a screen reader announces and the name a browser tab and a bookmark show.
How to fix: Add <title>Descriptive page name</title> inside the <head> of the document.
Warning Line 12, column 5 [heading-level]
The heading level jumps from h1 to h3. A screen reader uses the heading outline to navigate the page, and a skipped level breaks that outline (WCAG 1.3.1, 2.4.10).
How to fix: Change this heading to h2, or add the missing intermediate heading level if the section really is deeper.
Error Line 13, column 5 [wcag/h37]
<img> is missing the required alt attribute. Without it a screen reader announces the file name, and the description the image carries is lost (WCAG 1.1.1).
How to fix: Describe the image in alt="...", or write alt="" when the image is purely decorative.
Error Line 14, column 8 [wcag/h30]
This link has no discernible text. An anchor whose accessible name is empty is announced as an unlabelled link, so the reader cannot know where it goes (WCAG 2.4.4, 4.1.2).
How to fix: Put descriptive text between the tags, or name an icon-only link with aria-label.
Warning Line 15, column 5 [input-missing-label]
<input> has no associated label, aria-label or title, so a screen reader announces it with no name - often just its type, such as "edit text".
How to fix: Associate a <label for="..."> with the control's id, wrap the control in a <label>, or add an aria-label describing the field.
Error Line 17, column 5 [text-content]
This button has no accessible text. A screen reader announces only "button", so the reader cannot tell what it does (WCAG 4.1.2).
How to fix: Put a text label between the tags, or give an icon-only button an aria-label.
Warning Line 18, column 5 [frame-missing-title]
<iframe> has no title attribute, so a screen-reader user hears only "frame" with no hint of what it contains (WCAG 4.1.2).
How to fix: Add a short descriptive title to the frame, for example title="Payment form".
Warning Line 19, column 5 [wcag/h63]
This table has data cells but no <th> header cells, so a screen reader cannot announce which column or row a value belongs to (WCAG 1.3.1).
How to fix: Mark the header row or column with <th>, and add scope="col" or scope="row" where the table is two-dimensional.Accessibility decides whether people can actually use a page. A meaningful share of visitors navigate with a keyboard, zoom the page, use a screen reader or depend on predictable structure; a missing label or an unannounced button is not an edge case for them, it is a dead end. The fixes are usually small - an alt attribute, a label element, a type attribute - and they tend to overlap with the structure search engines and other automated tools already reward: real headings, descriptive link text, labelled forms.
Automated checking is the fast first pass, not the whole job. It catches the mechanical problems in seconds, on every page, for free - which means they get caught before release rather than after a complaint. What it cannot do is judge whether the alt text is accurate, whether the reading order makes sense, or whether a keyboard user can reach the modal: those still need human testing. This tool reports exactly what it checks and claims nothing beyond it.
Common questions about this tool