WattShed.

WattShed Conform

Catch the mechanical accessibility misses before the audit does.

Paste a page's HTML, a full document or a fragment, and this runs eight mechanical checks against the markup: the kind of misses a linter can catch without ever rendering the page. Everything runs in this browser tab. Nothing is uploaded, sent to a server, or stored.

There is no URL field here, and there never will be. Fetching another site's markup from this tool is deliberately not offered. Copy the HTML you want checked, from view-source, your build output, or wherever it actually lives, and paste it below instead.

Be honest with yourself about what a clean report means here. These are static checks on pasted markup, a subset of accessibility guidance. Passing every check on this page is not WCAG conformance, and it says nothing about color contrast, focus order, script behavior, or how the page actually renders. Use this to catch the mechanical misses before a real audit, not instead of one.

1. Paste markup

Paste HTML to check

A full page source or a smaller fragment both work. This never fetches a URL; paste the markup itself.

Document type

Auto-detected as a fragment, from whether the pasted markup contains an <html>tag. Override it if that's wrong.

Parsed and checked entirely in this browser, via DOMParser. The markup never leaves this tab, is never uploaded, and is never rendered live on this page.

Paste HTML and run the checks to see a report here.

No markup handy? Load the example fragment to see five seeded issues, and a couple of correctly marked-up elements, at once.

Related tools

What it checks and what it cannot

Eight rules a machine can check. Everything else still needs a person.

The eight mechanical rules

  • Images without alt text

    Every <img> element missing an alt attribute at all. Empty alt="" for a decorative image still passes.

  • Unlabeled form inputs

    Inputs, selects, and textareas with no label, aria-label, aria-labelledby, or wrapping <label>. Hidden, submit, and button inputs are exempt.

  • Empty links and buttons

    Links and buttons with no visible text, no aria-label, and no image with alt text inside: nothing for a screen reader to announce.

  • Heading level and h1 order

    A heading that jumps more than one level, like h2 straight to h4, and, in a full document, more than one h1.

  • Tables without header cells

    A <table> with no <th> anywhere inside it, so its rows and columns have no announced headers.

  • Duplicate id attributes

    The same id value assigned to more than one element, which breaks label associations and in-page links.

  • Positive tabindex values

    Any tabindex greater than zero, which overrides the page's natural reading order with a manual one.

  • Missing document language

    A full document with no lang attribute on <html>, so assistive tech can't pick the right pronunciation rules. Not evaluated on a fragment.

What needs a real audit

  • Color contrast

    Whether text actually reads against its background at the size and weight it renders at.

  • Focus order and keyboard traps

    Whether tabbing through the live page follows a sane path and never gets stuck.

  • ARIA correctness beyond presence

    A role or state that is there but wrong, contradictory, or unsupported by the element carrying it.

  • Script-driven behavior

    Modals, live regions, and anything else that only exists once JavaScript runs against the DOM.

  • How the page actually renders

    Layout, reflow, and zoom behavior in a real browser, on a real screen.

  • Real assistive technology

    How a screen reader, switch device, or magnifier actually experiences the page, not just its markup.

Each finding reports pass or flag, and each signal reports pass, flag, or absent. A flag means worth a second look, not a violation on its own. Use this alongside a real accessibility audit, not instead of one.