Preflight a public page before release
Run a rendered-browser check on a public marketing, documentation, or landing page and catch automated WCAG 2.2 A/AA rule violations before launch.
Accessibility Tester
Free, no signup. Audit a rendered page with axe-core for WCAG 2.2 A/AA patterns, then turn each finding into a targeted engineering fix.
Checks run from our server; we fetch the URL you enter and don't keep the results. This launches a metered browser audit. Stylesheets are allowed for computed accessibility checks; media and fonts are blocked. Automated checks catch only part of WCAG issues and never replace manual testing. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Illustrative example — axe rule output for fixed markup
CRITICAL · Images must have alternate text (1)
Add a meaningful alt value when the image conveys information, or alt="" when it is decorative.
img.hero
<img class="hero" src="product.jpg">Element does not have an alt attribute.
The example shows an automated rule result, not a judgment about what the correct alternative text should say.
How to use it
- Enter a public page URL and run the metered browser audit.
- Start with critical and serious violations, but review every rule and affected selector.
- Use the HTML excerpt, error summary, and targeted repair guidance to locate the component.
- Retest after fixing, then complete manual keyboard, screen-reader, zoom, content, and task-flow checks.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Rate this tool
What the results mean
Each card is one axe rule with an impact level and affected-node count. Selectors identify elements in the audited DOM; HTML and error summaries explain the observed pattern. A zero-violation run only means no enabled automated rule fired.
How it works
A metered browser loads the public page with stylesheets enabled for computed checks while media and fonts are blocked. It runs axe-core against WCAG 2.2 A/AA-tagged rules and returns bounded violations and nodes. The page formats severity and adds rule-specific repair guidance.
Features
- Rendered-browser axe-core audit.
- WCAG 2.2 A/AA rule selection.
- Impact, selectors, HTML excerpts, and error summaries.
- Targeted repair guidance for supported axe rules.
- Explicit not-evaluated state when the browser audit cannot complete.
Limitations
Automation catches only part of accessibility. The audit does not use your login, perform interactions, cover every application state, judge meaningful alt text, or replace testing with disabled users and assistive technologies. Blocked media/fonts and dynamic timing can also change the rendered state.
Frequently asked questions
Does passing axe mean a page is WCAG compliant?
No. Automated checks detect only a portion of accessibility barriersWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all.. WCAG conformance requires manual keyboard, screen-reader, content, focus, error, and task-flow testing in addition to automation.
Which WCAG level does this test?
The browser run uses axe-core rules tagged for WCAG 2.2 Level A and AA. The result is a rule-violation report, not a conformance certificate.
Why might the audit miss a modal or logged-in screen?
The metered browser loads the supplied public URL without your authenticated session or scripted interaction. Hidden states, personalized flows, consent choices, and components opened later may not be evaluated.
What does a violation severity mean?
Critical, serious, moderate, and minor are axe impact levels used to prioritize review. Impact does not replace the associated WCAG criterion, user context, or engineering investigation.
Feature requests for Accessibility Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Turn findings into engineering work
Use the affected selector, HTML excerpt, failure summary, and targeted repair guidance to locate the component and create a development ticket.
Prioritize a large accessibility backlog
Start with critical and serious findings, filter by impact when needed, and still retain every automated violation for review.
Verify a focused repair
Rerun the same public page after a code change and confirm whether the automated rule stopped firing before completing manual checks.
Plan the manual testing that automation cannot cover
Use the automated report as a starting point for keyboard, screen-reader, zoom, content, focus, error, and end-to-end task testing—not as a compliance certificate.
Watch the full workflow
Accessibility Tester walkthrough
Read the transcript
Accessibility Tester
This beginner walkthrough shows how Accessibility Tester checks one public page for common accessibility problems. We will cover practical use cases, the complete audit workflow, impact levels, selectors and repair guidance, filtering, ticket export, the main features, and the manual testing that automation cannot replace.
Step 1
Accessibility Tester loads one public page in a browser and runs axe core, an automated accessibility testing library. It looks for rule patterns from the Web Content Accessibility Guidelines, version two point two, levels A and double A. Think of it as a fast first pass. It finds some code and design problems, but it is not a compliance certificate.
Step 2
Use it before releasing a public page, when turning findings into engineering tickets, when prioritizing a large backlog, or when checking whether a focused repair stopped a rule from firing. My favorite use is the last card: use the report to plan the manual testing that automation cannot cover, instead of treating a clean scan as the finish line.
Step 3
Enter a public page address and choose the button labelled "Run accessibility audit". The disclosure explains what leaves your browser: the site fetches the public address you enter, then launches a metered browser audit. Stylesheets are allowed because color, visibility, and layout can affect checks. Media and fonts are blocked, and results are not kept as a user profile.
Step 4
The sample report shows one critical image rule. The short text alternative, often called alt text, should communicate the purpose of an informative image. A decorative image usually gets an empty alternative instead. Notice the warning beneath the example: automation can detect that the attribute is missing, but it cannot decide what the correct description should say.
Step 5
The workflow is straightforward. Run the public page. Start with critical and serious findings, but review every rule. Use the selector, markup excerpt, failure summary, and repair guidance to locate the component. After the fix, rerun the page, then finish with manual keyboard, screen-reader, zoom, content, focus, error, and task-flow testing.
Step 6
For the complete example, enter shop dot example dot test slash checkout. Dot-test is reserved for documentation, so this is not a customer or public website. The capture fulfills the accessibility endpoint locally with a fixed four-rule report, and every external response is blocked. That keeps the walkthrough safe and identical on every retake.
Step 7
Choose "Run accessibility audit". The button changes while the bounded browser check is pending, then the result opens below the workflow. A real result can change with page content, styles, timing, consent choices, and later-opened components. This fixed response lets us focus on how to read the report instead of pretending that a live third-party page never changes.
Step 8
The summary reports four axe rule violations in one thousand two hundred sixty-four milliseconds. That count is four rules, not five individual elements: the first rule affects two images, while the other three affect one element each. The cards are sorted by impact, and the controls above them let you export development tickets or filter the visible list.
Step 9
The critical image rule affects two elements. Each element shows a selector, which is the developer-facing address of the element, followed by a short markup excerpt and a failure summary. The suggested repair is to add concise alternative text when the image communicates information, or an empty alternative only when the image is truly decorative.
Step 10
The serious label finding points to the email field. A visible placeholder is not a reliable replacement for a label. The repair is to associate the input with visible label text or another accurate accessible name. After changing the component, test that the field has a useful name, purpose, instructions, error message, and keyboard focus in the real checkout flow.
Step 11
The next serious card identifies the price note and reports a contrast ratio of two point eight to one, below the expected four point five to one in this fixture. Adjust the foreground or background color, then rerun the computed check. Also review text size, hover and focus states, images of text, and any theme or disabled state the automated snapshot did not open.
Step 12
The moderate card flags a shipping heading at level four where the surrounding outline skipped a level. Repair the page structure so headings describe a logical hierarchy, not merely a visual size. Then navigate the real page by headings with a screen reader. The automated rule can flag the pattern, but a person must confirm that the outline makes sense.
Step 13
Use the control labelled "Filter violations by severity" and choose "Serious". The two serious cards remain visible while the critical and moderate cards are only hidden from this view; they are not deleted from the report. Impact is a prioritization aid from axe core. It does not replace the related accessibility requirement, the user’s task, or an engineering investigation.
Step 14
The button labelled "Download dev-ticket CSV" turns the current findings into a comma-separated file for engineering work. Each row keeps the rule title, mapped ticket severity, repair description, selector, and observed evidence. Treat the export as a starting handoff. Add the page state, reproduction steps, expected behavior, owner, manual-test plan, and the evidence that will close the issue.
Step 15
Each result card represents one automated rule, with an impact level and affected-element count. The selector, markup, and error summary explain the observed pattern. A zero-violation run has a very narrow meaning: no enabled automated rule fired in the state the browser checked. It does not mean the content, keyboard flow, screen-reader experience, or complete task is accessible.
Step 16
The main features are a rendered-browser axe core audit, the Web Content Accessibility Guidelines version two point two rule set for levels A and double A, impact sorting, selectors, markup excerpts, failure summaries, targeted repair guidance, severity filtering, development-ticket export, and an explicit not-evaluated state when the browser run cannot complete.
Step 17
Automation catches only part of accessibility. This public audit does not use your login, open every modal, complete interactions, cover personalized states, judge meaningful alternative text, or replace testing with disabled users and assistive technologies. Blocked media and fonts, plus dynamic timing, can change the captured state. Retest the repair, then verify the full task with a keyboard, screen reader, zoom, content review, focus checks, and useful error recovery.
Use automation to find patterns. Use people and assistive technology to judge the experience.
Keep the exact page address, check time, rule name, affected element, repair, and retest result with the work item. Then test the real task with a keyboard, screen reader, zoom, clear content, visible focus, and useful error handling. An automated report can guide the work. It cannot certify that the experience is accessible.
Common issues & how to fix them
- Error Image lacks an accessible text alternative Fix: Add concise alt text that conveys the image’s purpose, or alt="" when the image is purely decorative.
- Error Form control lacks a label Fix: Associate a visible label with the control using for/id, or supply an accurate accessible name with aria-label/aria-labelledby when no visible label fits.
- Error Link lacks an accessible name Fix: Give the link meaningful text or an accessible name that identifies its destination instead of relying on an unlabeled icon.
- Warning Heading levels are skipped Fix: Restructure headings into a logical outline without skipping levels merely for visual sizing; use CSS for appearance.
- Warning Document language is missing Fix: Set the root html lang attribute to the page’s primary BCP 47 language tag, and mark passages that switch language.
- Warning Duplicate element IDs are present Fix: Make every id unique and update labels, ARIA references, fragments, and scripts that referenced the renamed element.
- Error Text color contrast fails Fix: Adjust foreground or background colors until the measured ratio meets WCAG AA for the affected text size and state.
- Information Keyboard behavior requires manual verification Fix: Tab through every interactive control, test activation and focus order, and fix any unreachable, trapped, or invisible focus state before sign-off.