Your files never leave your device. All processing happens locally in your browser.
How do I check a page for accessibility (WCAG) problems without uploading it to a server?
Open AnyTool’s Accessibility Checker, open your page and copy its HTML source (View Source / Ctrl+U), and paste it in. It parses the HTML with your browser’s own DOMParser and runs the common automated WCAG checks — images missing alt text, links and buttons with no accessible name, form inputs without a label, missing <html lang> and <title>, heading structure (no H1 / multiple H1 / skipped levels), duplicate ids, positive tabindex, a viewport that disables zoom, data tables without header cells, and basic ARIA checks — then gives you a grouped report: a summary (errors / warnings / passed), issue cards with the WCAG success criterion, a count, example elements and a concrete fix, plus a passed-checks list. Everything runs in your browser, so your HTML is never uploaded — safe for staging or internal pages. Be honest with the result, though: automated static checks catch only a portion of accessibility issues (studies find roughly 30–57% of WCAG problems), and from static HTML the tool can’t measure real color contrast, keyboard navigation, focus order or the actual screen-reader experience — a pass here is not proof the page is accessible, so pair it with a full tool (axe DevTools, Lighthouse, WAVE) and manual testing.
Paste your page’s HTML source — runs the common automated WCAG / a11y checks locally
Checks alt text, link/button names, form labels, lang, title, heading order, ARIA basics and more
Grouped report: summary (errors / warnings / passed) + issue cards with WCAG ref, count and a fix hint
100% client-side — your HTML is never uploaded; safe for staging / internal pages
Honest: automated checks catch only ~30–57% of issues; a pass is not proof of accessibility
What is
Automated accessibility checking (a11y / WCAG)
Automated accessibility checking is running programmatic rules over a page’s markup to find likely WCAG (Web Content Accessibility Guidelines) violations — the “a11y” checks that engines like axe, Lighthouse and WAVE perform. From STATIC HTML a checker can reliably find structural problems: images without alt text, links and buttons with no accessible name, form controls without a label, a missing document language or title, broken heading order, duplicate ids, a positive tabindex, a zoom-disabling viewport and basic ARIA mistakes. It cannot, however, measure real color contrast, keyboard operability, focus order or the actual screen-reader experience, and it can’t judge whether alt text is meaningful — which is why automated testing catches only a portion (roughly 30–57%) of accessibility issues and must be combined with manual testing.
The structural ones automated tools catch: missing alt text, unlabeled form fields, empty links and buttons, missing lang or title, broken heading order, duplicate ids, positive tabindex, zoom-disabling viewport, tables without headers and basic ARIA mistakes.
It runs the common automated WCAG checks over your pasted HTML. It flags images with no alt attribute (decorative alt="" is treated as valid), image-only links with no text alternative, links and buttons with no accessible name, form inputs without an associated label or aria-label, a missing <html lang> or <title>, heading-structure problems (no H1, multiple H1 or skipped levels), duplicate id attributes, positive tabindex values, a viewport meta that disables pinch-to-zoom, data tables with no <th> header cells, and basic ARIA issues (an invalid role, an aria-labelledby / aria-describedby that points at an id that doesn’t exist, or aria-hidden="true" on a focusable element). Each issue comes with the WCAG success criterion, a count, example elements and a fix.
No. Automated checks catch only about 30–57% of WCAG issues. A clean report is a good first pass but not proof of accessibility — you still need manual testing.
A clean report means the automated, structural checks passed — but that is only part of accessibility. Industry studies put automated coverage at roughly 30–57% of WCAG issues; the rest require a human. From static HTML this tool cannot measure real color contrast, verify keyboard navigation or focus order, or judge the actual screen-reader experience, and it can’t tell whether your alt text or labels are genuinely meaningful. Treat this as a fast first pass, then run a full tool such as axe DevTools, Lighthouse or WAVE and, crucially, test manually with a keyboard and a screen reader before claiming a page is accessible.
Those need the rendered page, not just the HTML. Contrast depends on computed CSS colors and images; keyboard and focus order depend on live interaction — none of which are available from pasted static HTML.
This tool analyses the static HTML you paste, not a live, rendered page. Real color contrast depends on the computed colors after all CSS (and sometimes background images or gradients) are applied, which the raw HTML doesn’t contain. Keyboard operability and focus order can only be verified by actually tabbing through the running page and watching where focus goes. The screen-reader experience depends on how assistive tech interprets the rendered accessibility tree in real time. Because those require the live page and human interaction, they’re outside what any static-HTML checker can do — use a browser extension like axe DevTools or Lighthouse for the rendered checks, and test by hand.
Paste the HTML source. Your browser can’t fetch most live URLs (CORS) and there’s no server proxy, so the URL box only works for CORS-enabled or same-origin pages.
Because the tool is 100% client-side with no server proxy — which is what keeps your page private — your browser can only fetch pages that allow cross-origin requests (CORS) or are on the same origin. Almost all live sites block that, so the reliable path is to open your page, use View Source (Ctrl+U), copy the HTML and paste it in. The optional “try to fetch” box is there for the rare CORS-enabled case; when it fails it tells you to paste the source instead. Nothing you paste is ever uploaded, which makes the tool safe for staging or internal pages.
Detailed Explanation
📖How It Works
What the Accessibility Checker Checks
The Accessibility Checker is a 100% client-side tool that runs the common automated WCAG (Web Content Accessibility Guidelines) checks over a pasted page’s HTML. The user opens their page, copies its HTML source (View Source / Ctrl+U) and pastes it in; the tool parses it with the browser’s own DOMParser and applies a set of static rules — the same class of structural checks engines like axe, Lighthouse and WAVE run. It flags images without an alt attribute (decorative alt="" is treated as valid) and image-only links with no text alternative; links and buttons with no accessible name; form controls (input / select / textarea) with no associated <label>, aria-label or aria-labelledby; a missing <html lang> or missing / empty <title>; heading-structure problems (no H1, multiple H1, or skipped levels such as H2 → H4); duplicate id attributes; positive tabindex values; a <meta name="viewport"> that disables zoom (user-scalable=no or maximum-scale < 2); data tables with no <th> header cells; and basic ARIA problems (an invalid role token, an aria-labelledby / aria-describedby that references an id that doesn’t exist, or aria-hidden="true" on a focusable element), plus an info-level landmark-region check. The output is a grouped report: a summary (errors / warnings / info / passed), issue cards grouped by severity with the WCAG success criterion, a count, example elements and a fix hint, and a passed-checks list.
Paste your page HTML → common automated WCAG checks run locally via DOMParser
Alt text, image-links, link/button names, form labels, lang, title, heading order
All parsing and rule evaluation is pure client-side JavaScript — no server, no CDN, no upload
⚙️Methodology
How the Static Rules Are Evaluated
Each rule queries the parsed document. Accessible names for links and buttons are computed with a best-effort static approximation of the accessible-name algorithm: aria-label, then the text of aria-labelledby targets, then title, then visible text, then a descendant image’s alt, then an input’s value — a link or button resolving to an empty name is flagged. Form labelling accepts an explicit <label for="id">, a wrapping <label>, or aria-label / aria-labelledby / title, and explicitly notes that a placeholder is NOT a label. Heading structure is derived by reading the h1–h6 outline in document order: zero H1 or more than one H1 is a warning, and any jump of more than one level (e.g. H2 to H4) is flagged as a skipped level. Elements marked aria-hidden="true" or role="presentation"/"none" (or nested inside one) are skipped for name checks so decorative content isn’t falsely flagged. Rules that only apply to a full page (missing lang, missing title) run only when the pasted markup actually contains <html> / <head> / <title>, so pasting a fragment doesn’t produce misleading errors. Issues are sorted error → warning → info, each carries a WCAG success-criterion reference and up to a few truncated example element snippets, and rules that find no problem (when the relevant elements exist) are reported as explicit passes.
Accessible name = aria-label → aria-labelledby text → title → visible text → child img alt → input value
Form labels accept label[for], wrapping label, or aria-label/aria-labelledby/title (placeholder ≠ label)
Heading outline read in document order: no H1 / multiple H1 / skipped levels flagged
Page-only rules (lang, title) run only when full-page markup is present; issues sorted by severity
⚠️Limitations
Automated Checks Catch Only a Portion — a Pass Is Not “Accessible”
The tool is explicit that automated, static checks catch only a PORTION of accessibility issues. Industry research puts automated coverage at roughly 30–57% of WCAG problems (Deque reports axe reliably finds about 57% of issues by volume; other analyses cite 30–40%), so the majority still require a human. From STATIC HTML this tool fundamentally cannot do several things: it cannot measure real COLOR CONTRAST (that needs the computed colors after all CSS, backgrounds and images are rendered), it cannot verify KEYBOARD NAVIGATION or FOCUS ORDER (those require tabbing through the live page), it cannot judge the actual SCREEN-READER experience (that depends on the rendered accessibility tree in real time), and it cannot tell whether alt text or a label is genuinely MEANINGFUL rather than merely present. Consequently a clean report is NOT proof that a page is accessible — it means the automated structural checks passed. The tool advises using it as a fast first pass and then combining it with a full tool (axe DevTools, Lighthouse, WAVE, which also test the rendered page) AND manual testing with a keyboard and a screen reader. It also can’t fetch most live URLs — with no server proxy (which keeps your page private), the browser only fetches CORS-enabled or same-origin pages, so users paste their source.
Automated testing catches only ~30–57% of WCAG issues; the rest need manual testing
Cannot measure real color contrast (needs computed/rendered CSS), keyboard nav or focus order
Cannot judge the actual screen-reader experience or whether alt/labels are meaningful
A clean report is NOT proof of accessibility — combine with axe/Lighthouse/WAVE + manual testing
No server proxy: browser can’t fetch most live URLs (CORS), so paste the page source
🔒Privacy & Security
Why Checking a Page In-Browser Is a Privacy Win
Online accessibility scanners send your whole page — or a URL they crawl server-side — to a remote service. The Accessibility Checker instead runs entirely on the user’s device: the pasted HTML is parsed with the browser’s built-in DOMParser and evaluated with plain JavaScript, nothing is fetched, uploaded, logged or stored, and no page is crawled (there is deliberately no server proxy). That makes it safe to audit STAGING, UNRELEASED or INTERNAL pages whose source you don’t want to expose to a third-party service before launch — a meaningful advantage when checking accessibility for a site that isn’t public yet, or for a page behind a login. The tool works offline once cached as a PWA, and closing the tab discards everything entered. It adds no new dependency and no CDN — the rule engine is a small, self-contained, well-typed module (a11yEngine.ts) using only the browser’s DOMParser.
HTML is parsed locally with the browser’s DOMParser and never uploaded — no server, no CDN, no crawl
Works offline once cached; closing the tab discards your data
No new dependency — self-contained a11yEngine.ts using only the built-in DOMParser
Dark mode and mobile support with a sticky Check / Copy bar and a copyable text report
Accessibility checking: in-browser static checks (AnyTool) vs online scanners
Capability
AnyTool
Typical online scanners
Processing
Runs entirely in your browser (DOMParser)
Sends your page / URL to a server
Your page
HTML never uploaded, works offline
Page or URL crawled server-side
Staging / internal pages
Safe — nothing leaves the device
Exposed to a third-party service
Input
Paste your page HTML source (View Source)
Often a URL the tool crawls
Checks
Common static WCAG rules (alt, labels, lang, headings, ARIA…)
Varies
Report
Grouped by severity + WCAG ref, count, examples, fix
Varies
Color contrast / keyboard / screen reader
Not possible from static HTML (honestly stated)
Some do (rendered/browser-extension based)
Honesty about coverage
Clear that automation catches only ~30–57% of issues
Often implies a pass means “compliant”
Cost / signup
Free, no signup
Often gated or ad-heavy
AnyTool runs common automated WCAG checks locally from pasted HTML and uploads nothing, which is safe for staging or internal pages. Automated static checks catch only a portion of accessibility issues (studies find ~30–57% of WCAG problems) and cannot verify real color contrast, keyboard navigation, focus order or the screen-reader experience — a pass is not proof of accessibility, so combine with a full tool (axe DevTools, Lighthouse, WAVE) and manual testing. Comparison as of July 2026.
