WCAG 2.1 · Levels A and AA · No account
Free Accessibility Checker
Paste a URL and see which WCAG checks fail, which success criterion each one maps to, and the element that caused it.
Automated checks find some accessibility problems, not all of them. Several WCAG criteria need human judgement. AccessCheck does not make a site compliant, and is not a substitute for a manual audit or for testing with assistive technology.
Works on sites built with
Scans any public page, whatever it's built with. These are simply the platforms we see most often.
Start here
Find what is broken before someone reports it
Most teams don't need an audit programme on day one. They need to know which pages are failing, what specifically is wrong, and what to fix first.
Seconds to scan any page
Paste a URL. No account, no install, no configuration.
Clear severity and impact labeling
Prioritize fixes based on real user impact, from critical to minor issues.
Rescan to confirm a fix landed
Run the page again after a change and see the finding disappear.
How It Works
Scan → Fix → Rescan
Paste your URL
Enter any website address
Run the scan
Checked in a real browser
Review issues
Sorted by severity level
Fix problems
With actionable guidance
Verify fixes
Rescan to confirm
WCAG 2.1 A/AA
What a scan gives you
Each finding names the rule, the success criterion it maps to, and the element that failed.
WCAG 2.1 A/AA checks
Tests your pages against the WCAG 2.1 A and AA success criteria that automated tooling can detect, and tells you which criterion each finding maps to.
Findings you can act on
Every issue comes with the failing HTML, a CSS selector, the rule that failed, and the WCAG success criterion it maps to, so a developer doesn't have to go looking.
A dated record of your testing
Each scan is kept with its date and results, so you have a history of what was tested and when, and can show how issue counts changed over time.
Wider audience reach
Fixing accessibility issues improves the experience for people using screen readers, keyboards and magnification, and generally for everyone else too.
Overlaps with SEO
Several of the things automated checks look for are also things search engines read: alt text, heading structure, link names, page titles.
Evidence a developer can act on
Every finding carries the failing element's HTML, a selector to reach it, and a screenshot. Copy any issue as ready-made GitHub markdown.
The state of the web
The problem is ordinary, not exotic
Most websites have accessibility problems, and most of them are ordinary and fixable. Automated testing finds a meaningful share of them quickly. The rest still needs a human.
of home pages had detectable WCAG 2 failures
WebAIM Million, 2025
detected errors per home page, on average
WebAIM Million, 2025
US adults live with a disability
CDC
of issue instances automated testing can detect
Deque, self-reported
Background
How the standards got here
WCAG has been revised three times since 2008. Each revision added criteria rather than replacing them, which is why “WCAG 2.1 AA” is still the level most teams aim at.
WCAG 1.0
The first formal guidelines for web accessibility were published.
WCAG 2.0
A major update introduced the four principles of accessibility.
WCAG 2.1
Extended guidelines to better address mobile accessibility and cognitive disabilities.
WCAG 2.2
Added new success criteria focusing on mobile and cognitive accommodations.
Most common findings
The findings that come up again and again
Learn about the most frequent accessibility problems and their solutions
Missing Alt Text
Images without alternative text are not accessible to screen reader users.
Add descriptive alt text to all images using the alt attribute. For decorative images, use alt="".
Color Contrast
Insufficient contrast between text and background makes content difficult to read.
Ensure text has a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
Missing Form Labels
Form fields without proper labels are difficult for screen reader users to understand and navigate.
Associate each form input with a label element using the for attribute, or use aria-label/aria-labelledby.
Keyboard Navigation
Elements that can't be accessed using a keyboard exclude users who can't use a mouse.
Ensure all interactive elements can be reached and operated with the Tab, Enter, Space, and Arrow keys.
Heading Structure
Improper heading structure makes navigation difficult for screen reader users.
Use semantic headings (h1-h6) in a logical hierarchy without skipping levels. Each page should have one h1.
Why bother
Why this is worth doing
people worldwide live with a significant disability
WHO
annual disposable income of working-age Americans with disabilities
American Institutes for Research
The case that does not depend on regulation
Most of this work makes the site better for everyone, and a lot of it overlaps with things you were going to do anyway.
- Reach the people who currently can't use your site with a screen reader, a keyboard, or magnification
- Fix the things SEO cares about too: alt text, headings, link names, page titles
- Catch regressions before your users report them
- Keep a dated record of the testing you've actually run
- Make the site easier to use for everyone, including people who never touch a screen reader
Monthly · Cancel any time
Monitoring, not one-off scans
The checker on the homepage is free and always will be. Paid plans watch whole sites on a schedule and keep the history, so a regression shows up on its own.
Automated checks find a share of accessibility problems, not all of them. AccessCheck does not make a site compliant and is not a substitute for a manual audit or for testing with assistive technology.
Starter
One site, watched properly.
- Sites
- 1
- Pages monitored
- 50
- Page-scans / 30 days
- 300
- Up to 50 pages crawled from your homepage
- Re-scanned every week, so regressions surface on their own
- Findings grouped by WCAG success criterion, with severity
- The failing HTML, a selector, and a screenshot of the element
- A separate “needs review” list for checks a machine cannot judge
- Copy any issue as GitHub-ready markdown
- CSV export with one row per failing element
- Optional email when a scan finishes, or a weekly summary
Pro
Several sites, or one large one.
- Sites
- 5
- Pages monitored
- 200
- Page-scans / 30 days
- 1200
- Everything in Starter
- 200 pages pooled across sites, split however you like
- Compare any two scans to see what moved
- Trend chart of findings over time
- Mark a rule fixed, or ignore it with a reason
- Issues clustered by rule across every page, worst first
Agency
Client work.
- Sites
- 10
- Pages monitored
- 500
- Page-scans / 30 days
- 3000
- Everything in Pro
- 10 client sites under one login, each with its own report
- 500 pages pooled, for larger or busier sites
- Printable report per scan, for handing to a client
On every plan
- You are not billed for pages we didn't scan
- Allowance is reserved when a scan starts and the unused part is returned when it finishes. A crawl that finds 8 pages of a 25-page budget costs 8.
- The score formula is published
- Severity-weighted, ratio-based, and versioned so a change to the maths never silently re-baselines your history.
- The crawler identifies itself
- One request at a time, with a delay, from a documented user-agent you can allowlist or block at your WAF.
- Your data comes out again
- Full JSON export of everything we hold, and account deletion you run yourself.
More than 10 sites, or need invoicing and a purchase order? Tell us what you're monitoring and we'll quote it.
Prices in USD, billed monthly, cancel any time. 30-day money-back guarantee. Currently available to customers in the United States only. Scores and scan history are kept for as long as your account exists; the heavier evidence (screenshots and captured HTML) is kept for six months.
Questions
Questions worth asking before you buy
What the scanner does, what it cannot do, and how to read the results.
Make accessibility part of your normal workflow
Run a scan, fix what matters, and ship knowing which problems you have and which ones you don't.