Full page HTML or a snippet — the scanner checks tags, attributes, and structure
Paste HTML to audit
Issues will appear grouped by severity// scan markup for a11y issues in one click
Instantly scan HTML markup for missing alt text, duplicate IDs, empty links, and missing landmark roles. Free browser-based accessibility checker.
Paste HTML to audit
Issues will appear grouped by severityCopy your full page source or any HTML snippet into the input area.
Toggle the checks you want to run — alt text, IDs, links, landmarks, forms, headings.
Issues appear grouped by severity. Copy the full report to share with your team.
This tool parses your HTML in-browser and runs a series of automated accessibility checks based on WCAG 2.1 guidelines. It flags issues that affect screen readers, keyboard navigation, and assistive technologies — helping you catch problems before they reach production.
No. All processing happens entirely in your browser using JavaScript. Your HTML never leaves your device — nothing is sent to any server.
Images should have an alt attribute describing their content for screen reader users. An <img> with no alt attribute, or with alt="" on a non-decorative image, fails WCAG 1.1.1.
The id attribute must be unique per page. Duplicate IDs cause JavaScript, CSS, and assistive technology to behave unpredictably, and fail WCAG 4.1.1 (Parsing).
Landmark roles (<main>, <nav>, <header>, <footer>, <aside>) help screen reader users quickly navigate page regions. Pages missing these fail WCAG 1.3.1.
A link is considered empty if it has no visible text content, no aria-label, and no title attribute. Screen reader users have no way to understand the link's purpose.
No. Automated tools catch roughly 30–40% of accessibility issues. Always combine automated checks with manual keyboard navigation testing and screen reader evaluation for thorough coverage.
An HTML accessibility audit is the process of scanning your web page's markup for issues that would prevent users with disabilities from accessing your content effectively. This includes checking for missing image descriptions, broken navigation structures, non-unique element identifiers, and other markup-level problems that affect screen readers, keyboard navigation, and other assistive technologies.
Accessibility auditing is no longer optional. The Web Content Accessibility Guidelines (WCAG) are referenced in legal frameworks in the US (ADA, Section 508), the EU (European Accessibility Act), and many other jurisdictions. Beyond compliance, accessible websites are better for everyone — cleaner markup, faster parsing, and more robust code.
💡 Looking for premium HTML templates and themes? MonsterONE offers unlimited downloads of accessible, production-ready templates — worth checking out.
Alt text (the alt attribute on <img> elements) is arguably the single most common accessibility issue on the web. When a screen reader encounters an image without alt text, it may read the filename aloud — "banner_v2_final_USE_THIS.jpg" is not helpful to a visually impaired user. Worse, some screen readers skip the image entirely, causing users to miss content that may be critical to understanding the page.
There are two distinct cases to handle. Informative images — photographs, diagrams, charts, icons that carry meaning — must have a descriptive alt attribute. Decorative images that add no informational value should use alt="" (an empty alt attribute), which tells screen readers to skip them entirely. The mistake most developers make is omitting the attribute altogether, which leaves the browser to guess.
The id attribute is meant to be a unique identifier for a single element on the page. In practice, copy-paste development, component reuse, and template inheritance frequently produce pages with several elements sharing the same ID. The immediate problem is that JavaScript's document.getElementById() returns only one element — the first one — silently ignoring the rest. CSS targeting with #id behaves similarly.
For accessibility, the consequences are more severe. ARIA attributes like aria-labelledby and aria-describedby reference elements by their ID. If the target ID appears more than once, the association breaks unpredictably. <label for="..."> works the same way — duplicate IDs mean some form fields lose their programmatic labels entirely.
HTML5 semantic elements (<main>, <nav>, <header>, <footer>, <aside>, <section>) create landmark regions that screen reader users rely on for quick page navigation. In NVDA, JAWS, and VoiceOver, users can pull up a list of landmarks and jump directly to the main content, skipping navigation menus. This is the keyboard-accessible equivalent of "skip to content" links.
Pages built entirely from <div> and <span> elements force screen reader users to listen to the entire page sequentially to find the content they want. This dramatically increases the cognitive load and time required to use the page. Adding semantic landmarks is low-cost and high-impact — one of the easiest accessibility wins available.
A link or button is "empty" from an accessibility standpoint when it has no accessible name. An accessible name can come from visible text content, an aria-label attribute, an aria-labelledby reference, or (for images) the alt attribute of a child image. When none of these are present, screen readers announce the element as simply "link" or "button" with no context.
Common patterns that produce empty links include icon-only buttons without labels, social media icon links with no text, and navigation links that rely purely on background images. The fix is straightforward: add visually hidden text using a .sr-only CSS class, or add an aria-label directly to the element.
Every form input needs a programmatically associated label. This means using <label for="inputId"> with a matching id on the input, or wrapping the input inside the label element. Placeholder text does not count as a label — it disappears when the user starts typing, leaving the field unlabeled mid-interaction.
This matters for screen reader users who navigate forms field by field. Without a proper label association, the screen reader announces only the input type — "edit text" — with no indication of what the field is for. This accessibility audit checks that all <input>, <select>, and <textarea> elements have associated labels, either via for/id pairing or aria-label.
Headings (<h1> through <h6>) create an outline of your page that screen reader users navigate by heading level. Skipping levels — jumping from an <h1> directly to an <h4> — creates a confusing document structure that makes it difficult to understand the relationship between sections. Similarly, using heading tags purely for visual styling (making something big and bold with an <h2> when it is not actually a section header) pollutes the document outline.
Best practice is one <h1> per page (the main title), followed by <h2> for major sections, <h3> for subsections, and so on — without skipping levels. This tool checks for level skips and flags pages that have zero or multiple <h1> elements.
Not all accessibility issues are equal. The audit results are grouped into three severity levels. Errors are definitive WCAG failures that will directly impair assistive technology users — missing alt attributes, duplicate IDs, and empty links fall here. Warnings are likely problems that need manual verification — a suspiciously short alt text might be a real description or might be inadequate. Info items are best-practice recommendations that improve experience without being hard failures.
Start with errors, then warnings. A page with zero errors and a few warnings is already dramatically more accessible than the average website. Automated tools like this one are excellent for catching the structural, markup-level issues that are easy to miss in code review.