♿

Accessibility / WCAG Compliance Report

Scan any page against WCAG 2.1 checks — images, forms, headings, ARIA, landmarks, tables and more — and get an overall score, a Perceivable / Operable / Understandable / Robust breakdown, and a prioritized fix list. An automated report, not a legal certification, and never an auto-fix overlay.

⚡ Interactive demo — sample data

82/100 (Grade B) — 1 blocking error, 3 items flagged for manual review.

Perceivable 3 images missing alt attributes Issue

Perceivable Color contrast — 12 elements need manual review Warning

Operable No skip-to-content link found Warning

Operable All form fields have associated labels Looks good

Understandable Exactly one H1, no skipped heading levels Looks good

Robust 1 ARIA role missing a required attribute Warning

This is a sample. Run the real check on your own URL above ↑

About this tool

How it works

Enter your page URL

Paste any public URL and run the check. We fetch the page's live HTML and run it through the same accessibility detection engine used in our full site audits — no separate crawler, no different rules.

Get a WCAG 2.1 compliance report

You get an overall score and letter grade, a breakdown across the four WCAG 2.1 principles (Perceivable, Operable, Understandable, Robust), and a full per-category pass/fail list — images, forms, headings, ARIA, tables, iframes, and more.

Work the prioritized fix list

Findings are ranked blocking errors first, then items that need manual review, each tagged with its impact level and which WCAG principle it falls under — so you know what to fix first and why it matters.

What we check

Images & media — Missing alt attributes, unlabeled role=img elements, image-map areas without alt text, SVGs without accessible names, videos without captions, and autoplaying audio/video.
Forms & inputs — Form fields without labels (via <label>, aria-label, or aria-labelledby), positive tabindex values that break natural tab order, and input buttons missing visible text.
Headings & document structure — Missing or duplicate H1s, skipped heading levels, empty headings, missing document title, missing lang attribute, and disabled pinch-zoom in the viewport meta tag.
Landmarks — Presence and uniqueness of main, banner (header), contentinfo (footer), and navigation landmarks — the regions assistive tech users rely on to jump around a page.
Buttons & links — Links and buttons without discernible text, missing skip-to-content links, and lists/list-items with invalid structure.
ARIA usage — Invalid ARIA attribute values, aria-hidden containers that still hold focusable elements, ARIA roles missing their required attributes, duplicate ARIA ID references, and aria-hidden mistakenly applied to <body>.
Tables — Data tables missing header cells, empty <th> elements, and invalid or misused scope attributes.
Deprecated & risky elements — Legacy tags like <blink>, <marquee>, <font>, and <center>, plus meta-refresh redirects that can disorient users relying on assistive technology.
Manual-review flags — Color contrast and touch-target sizing can't be fully verified from static HTML alone (they depend on rendered/computed styles), so these are explicitly called out as needing a manual pass with a contrast or measurement tool — never silently scored as passing.

Common issues we catch

Images without alt text — The single most common finding on real-world sites. Missing alt attributes mean screen reader users get no information about what an image shows — or hear the raw filename instead.
Form fields with no accessible label — Placeholder text is not a substitute for a real <label>. When a field only has a placeholder, screen reader users often can't tell what the field is for once they start typing and the placeholder disappears.
Color contrast that fails WCAG AA — Light gray text on white backgrounds, low-contrast buttons, and thin decorative fonts are extremely common and are one of the top accessibility complaints — and one of the top targets in ADA web-accessibility demand letters.
No skip-to-content link — Keyboard and screen-reader users without a skip link have to tab through your entire header and navigation on every single page before reaching the actual content.
Heading levels used for font size, not structure — Picking an H4 because it 'looks the right size' rather than because it's a fourth-level subsection breaks the outline assistive tech uses to navigate the page.
Icon-only buttons with no accessible name — A button that's just an icon (hamburger menu, close 'X', cart icon) with no aria-label, title, or visible text is invisible to a screen reader — it announces as just 'button'.
Overlay/auto-fix accessibility widgets — A number of vendors sell a JavaScript 'accessibility overlay' that claims to auto-fix a site's accessibility with one script tag. Disability advocates and the FTC have both pushed back hard on these claims — the FTC brought a $1,000,000 enforcement action against one overlay vendor in 2023 for deceptive accessibility claims. We deliberately do not sell or recommend that approach; this report tells you what's wrong in your own code so your team can fix it properly.

Where this matters

WCAG 2.1 Level AA — The checks in this report map to WCAG 2.1 success criteria commonly cited in accessibility audits and legal demand letters — the version most ADA-related web accessibility guidance points to as the practical benchmark, though WCAG itself is a voluntary technical standard, not a law.
Screen readers (JAWS, NVDA, VoiceOver, TalkBack) — Missing labels, broken landmarks, and invalid ARIA usage are exactly the barriers that block screen reader users from using a site at all — these checks target that experience directly.
Keyboard-only navigation — Positive tabindex values, missing skip links, and focusable content trapped inside aria-hidden containers all break the experience for users who navigate by keyboard alone (motor impairments, or simply power users).
WordPress, Shopify, Wix & page builders — Page builders frequently generate empty headings, icon buttons with no label, and images uploaded without alt text by default — this report surfaces exactly that pattern regardless of platform.
Legal/demand-letter risk areas — Missing alt text, unlabeled forms, poor contrast, and missing skip links are consistently among the most-cited issues in ADA Title III web accessibility demand letters — this report is built to surface those first, as a starting point for remediation, not as legal advice.

Frequently asked questions

Is this an official ADA or WCAG compliance certification?

No. This is an automated report of potential issues detected by scanning your page's HTML. There is no official government 'certification' for WCAG or ADA web compliance — any vendor claiming to sell one is not being accurate. Full compliance confidence requires manual testing, including testing by people who use assistive technology.

Does this tool fix my accessibility issues automatically?

No, and we deliberately don't offer that. So-called 'accessibility overlay' widgets that claim to auto-fix a site with one script tag have drawn FTC enforcement action and strong pushback from disability advocates for overstating what they actually do. This report tells you exactly what to fix and where in your own code — real fixes happen in your markup, not through a third-party script layered on top.

What's the difference between an 'error' and a 'warning' in this report?

Errors are issues the scan can confirm directly from your HTML — like an image with no alt attribute at all. Warnings are things that need a human look, like color contrast (which depends on final computed/rendered styles) or touch target sizing — the scan flags them honestly instead of guessing pass or fail.

What are the four WCAG principles (POUR)?

Perceivable, Operable, Understandable, and Robust — the four core principles WCAG 2.1 organizes its success criteria under. We group our findings under these four so you can see, at a glance, which broad area of accessibility needs the most attention.

Can automated scanning catch every accessibility issue?

No tool can. Industry estimates commonly cited in the accessibility field put automated testing coverage at roughly 30-50% of WCAG success criteria — contrast on real rendered styles, meaningful reading order, and actual screen-reader usability all still need a human pass. This report is a strong, fast starting point, not a replacement for manual testing.

Does fixing these issues protect me from an ADA lawsuit?

We can't make that promise, and you should treat anyone who does with skepticism. Addressing the issues in this report reduces real, common barriers for disabled users and closes off some of the most frequently cited problems in demand letters — but legal risk should be assessed with an attorney, not a scanning tool.

Why does the report say some things need 'manual review' instead of just pass or fail?

Color contrast and clickable-element sizing depend on final rendered/computed CSS, not the raw HTML this scan reads. Rather than guess, we flag those honestly as needing a manual check with a contrast checker or browser dev tools.

How is this different from a full site audit?

This free report scans one page's HTML for WCAG-relevant issues. Our full site audit runs this same accessibility engine across your whole site alongside SEO, performance, security, and content analysis, and can be paired with manual remediation work.

This is one of several free SEO tools from Custom Web Audits. For a complete, prioritized analysis of your whole website, run a full audit.