Paste an HTML fragment or document to review its heading structure, landmarks, image alternatives, form labels, and estimated tab order. Checks that need rendering or human judgment stay clearly marked for manual testing. The markup is read by a parser that never renders it, and every finding comes with a rule ID, a source location and a suggested fix you can copy as a Markdown report.
HTML only. JSX, Vue and Svelte templates are outside the scope of this release. Your markup is analyzed in the browser and is never sent to a server.
Checks headings, images, forms, names, ARIA references and focusable elements inside the fragment. Page-level rules such as lang, title and main are not run.
An HTML accessibility checker finds repeatable markup problems before a page is fully deployed. It can inspect heading levels, image alt attributes, associations between controls and labels, name signals for buttons and links, ARIA references, landmarks, and the order suggested by tabindex. Running it before a pull request narrows the places that need correction and creates a practical checklist for QA.
Static HTML cannot establish full accessibility. It cannot confirm whether every feature works from a keyboard, whether focus indicators are visible, whether visual and DOM order match after CSS, or whether dynamic status messages reach assistive technology. This tool therefore separates high-confidence issues, items that require review, and checks that must be performed manually. It does not produce a conformance score.
Choose HTML fragment for a button, card, form section, or another piece that will be inserted into a larger page. Fragment scope checks headings, images, forms, names, ARIA references, and focusable elements inside that piece. It does not report missing page-level metadata such as a document language, a title, or a main landmark.
Choose Full document when the input represents a complete page. This adds checks for page language, title, primary landmarks, and ways to bypass repeated regions. The tool can suggest document scope when it sees a doctype or document elements, but it does not silently change the selection. Explicit scope prevents page-level rules from becoming false alarms in component reviews.
Headings are not merely large text. They communicate the organization of a document, and browsers and assistive technologies can use them for in-page navigation. A common hierarchy uses h1 for the main title, h2 for major sections, and h3 for subsections that belong to an h2.
Moving directly from h2 to h4 can imply a missing level. Moving from h4 back to h2 can be valid because it closes nested sections. The checker only flags jumps that move down by more than one level. A missing or repeated h1 is presented as a review item for full documents, not an automatic WCAG failure.
The wording of each heading must also describe its section, but source analysis cannot reliably judge that meaning. Review vague headings such as More, Other, or Details in their actual content context.
Elements such as header, nav, main, aside, and footer, along with ARIA landmark roles, divide a page into larger regions. Assistive-technology users can move to main content or navigation without traversing every link. A full document should be reviewed for a clear primary content region.
Repeated landmarks need distinct names. If a header and footer both contain a nav element, names such as Primary and Footer applied with aria-label help users distinguish them in a landmark list. Adding more landmarks is not the goal: use only meaningful regions and label repeated roles clearly.
A visible label is the text a person sees, while an accessible name is the name exposed by the browser through accessibility APIs. For a typical form field, an explicit association between a label's for attribute and the control's id is clear and maintainable. Wrapping a control inside a label can also create an implicit association.
A placeholder disappears when typing begins and is not a stable replacement for a label. An aria-label can name an icon-only control, but when visible text exists, the accessible name should contain that text. A button that visibly says Search but is named Find items can be difficult to operate with speech input because the spoken visible label does not match its programmatic name.
The checker estimates name signals from aria-labelledby, aria-label, associated labels, descendant text, and selected native fallbacks. The complete accessible-name algorithm also depends on host-language rules, hidden content, shadow DOM, and recursive references. Confirm complex custom controls in the browser accessibility tree.
An informative image needs a text alternative that serves the same purpose. If an image is the only content of a link or button, its alternative should describe the action or destination. A purely decorative image can correctly use an empty alt so assistive technology ignores it. The checker therefore treats a missing alt as a high-confidence issue and an empty alt as an item that requires context.
Values such as image, photo, or banner-final-v3.jpg rarely explain purpose. The checker warns when an alternative looks like a filename, URL, or generic word, but it does not score writing quality. The correct text depends on whether the same image appears in an article, product card, functional link, or decorative layout.
Complex charts and diagrams may need more than a short alt. Provide a concise summary and make detailed information available in nearby text or a data table when appropriate.
Attributes such as aria-labelledby, aria-describedby, and aria-controls point to element IDs. Copying a component or renaming an ID without updating every reference can remove a control's name, description, or relationship. The checker identifies missing targets and duplicate IDs.
ARIA is not a universal patch for missing native semantics. Prefer elements such as button, nav, main, and label when they match the intended role and behavior. This tool does not validate every required state and keyboard interaction for custom widgets. Use the WAI-ARIA Authoring Practices and test complex controls with actual assistive technology.
Interfaces are usually easier to maintain when DOM order and native focus behavior provide the sequence. Positive tabindex values move those elements before the regular sequence and create a separate ordering system that can become inconsistent as the page changes. The checker marks positive values for review and estimates their order before native focusable elements and elements with tabindex zero.
The list is not a substitute for browser testing. Pasted HTML does not reveal every CSS-hidden element, flex or grid reordering, script-opened dialog, disabled state, shadow root, or focus trap. Use the result to locate suspicious markup, then test Tab and Shift+Tab in the implemented interface.
A tabindex of -1 can be intentional for an element that receives programmatic focus but should not appear in sequential keyboard navigation. When it is added to a native button or link, review whether keyboard users can still reach the feature.
High-confidence issue covers cases with a relatively clear source location, such as a missing alt, a broken label association, or a native button without a name. Needs review covers cases that depend on context, such as whether an empty alt is truly decorative or whether a heading jump reflects the intended structure. Manual test covers focus visibility, keyboard traps, visual order, contrast, and dynamic updates that require a running page.
Zero automatic findings do not mean the interface is accessible. Automated checks reduce the area a person needs to inspect. W3C guidance also notes that evaluation tools can quickly identify potential issues but cannot test every accessibility aspect and can produce inaccurate or misleading results.
Start by pasting the component HTML and fixing high-confidence issues first. Review the heading tree and landmark list for meaningful structure and names, then inspect the estimated tab order for positive tabindex values and unnamed controls. When the markup is clean, copy the Markdown report into the pull request or QA ticket.
Finish in the running interface. Test keyboard operation, focus visibility, visual order, and dynamic updates, and measure rendered text, icon, and component colors in the contrast checker. Capture states and charts in the color blindness simulator to find information conveyed by color alone.
The 8 manual checks are always listed regardless of the findings, so the areas automation cannot reach stay in view.
A lone h4 is not reported as a skipped level, because there is no earlier heading to compare it with. Fragment scope also skips the page-level lang, title and main rules.
The help link is last in the DOM but second in the tab sequence. Removing both positive values restores an order that matches the source.
Last verified:
What it is, who it's for, how it works and why you'd use it.
An HTML accessibility checker statically analyzes pasted markup for structure, text alternatives, form labels, name signals, ARIA references, and focus order.
It is for front-end developers, HTML authors, QA testers, designers, and product managers reviewing markup before a pull request or accessibility QA.
It parses HTML without rendering it and reports each issue with its source location, related WCAG criterion, suggested fix, and a separate manual-test list.
It helps teams find repeatable markup problems before deployment while keeping checks that require rendering or human judgment outside the automatic result.