Find the accessibility issues on your page, and how to fix each one.
AccessHawk opens your page in a real browser, runs Lighthouse, then has Claude, Anthropic's AI model, review the screenshot, accessibility tree and HTML. Each issue comes with the element, the WCAG criterion and a fix. A scan takes 1 to 5 minutes.
2 free scans. No credit card.
From the report
Findings from a scan of our sample page at WCAG 2.2 Level AA.
| Number | Issue | WCAG | Fix |
|---|---|---|---|
| 1 | Critical Search box has no visible labelIts only label is the placeholder, which disappears as soon as someone starts typing. | 3.3.2 Labels or Instructions Level A header input | Add a visible label, such as <label for="q">Search products</label>. |
| 2 | High Button text is hard to readWhite on light blue is 2.4:1. Normal text needs 4.5:1. | 1.4.3 Contrast (Minimum) Level AA .hero .button | Use dark text on the button, or darken it to #1D5FAE (6.4:1 with white). |
| 3 | Medium Intro text is slightly too light
| 1.4.3 Contrast (Minimum) Level AA .hero p | Use #767676 or darker. |
Rule-based checks can't judge meaning
Lighthouse can tell you an image has alt text. It can't tell you whether that text describes the image. Some WCAG criteria need that kind of judgment, which is what the AI review adds. A manual audit still covers more, but you can't run one on every deploy.
| Check | Lighthouse | AI review |
|---|---|---|
| Alt text | “Image elements have [alt] attributes”: passes | alt="image1.jpg" doesn't describe the photo |
| Form labels | “Form elements have associated labels”: passes | The label “Field 1” doesn't say what to enter |
| Headings | “Heading elements appear in a sequentially-descending order”: passes | Bold text that looks like a heading is marked up as a paragraph |
| Reading order | “Visual order on the page follows DOM order”: manual check | The sidebar comes first in the HTML but appears after the main content |
How it works
Enter a URL
Paste the URL of any page that can be reached from the public internet.
Lighthouse and Claude review
Lighthouse runs its accessibility audit, then Claude reviews the screenshot, accessibility tree, HTML and Lighthouse results together.
Read the report
Each issue lists its severity, WCAG criterion, location and a suggested fix. The screenshot is marked up with boxes around the issues.
What's included
Every plan includes these unless the item says otherwise.
WCAG 2.0, 2.1 and 2.2
Pick a WCAG version and Level A, AA or AAA for each scan. Every issue names the success criterion it fails.
Reviewed by Claude
Every scan is reviewed by Claude, which reads both the screenshot and the code.
Visual issue highlighting
The full-page screenshot is marked up with boxes around the issues, colored by severity.
Project organization
Scans are saved to projects in your account, with the date and score of each.
Issue tracking
Mark issues as resolved and add a note, such as the pull request that fixed them.
Editable reports
Edit the report text before you send it, then print it or save it as a PDF from your browser.
Share links
On Pro and Team, create a public link to a report so a client can read it without an account.
Scheduled scans
On Hobby and above, scan a page daily, weekly or monthly at 6 AM UTC and get an email when it finishes.
CI/CD integration
On Hobby and above, start scans from your CI pipeline with the REST API and get results as JSON or by webhook.
Ways to use AccessHawk
Pre-launch review
Scan a staging page before you deploy. It has to be reachable from the internet, so use a public preview URL or, on Team, add a cookie or header to get past the login.
Development QA
Start scans from CI with the REST API (Hobby and above) and fail the build on the issues you choose.
Audit documentation
Keep a dated report of the WCAG issues found, with annotated screenshots, to attach to an audit.
Remediation planning
Hand developers a list of issues sorted by severity, each with a suggested code fix.
Scan one of your own pages
Or open the sample report first to see what a finished scan looks like.