Website accessibility checker

This website accessibility checker finds issues in source HTML and rendered content, with DOM evidence, WCAG references, and practical fixes.

Know what ran

What the website accessibility checker tests

This web accessibility checker evaluates a selected automated WCAG subset. Each finding keeps its evidence layer, rule identifier and next action; a missing observation stays unknown.

Image alternatives

Missing alt attributes and suspicious placeholder text in source; image-alt results after rendering.

Fix image alternatives

Form labels

Names for inputs, textareas and select controls. Source labels and rendered accessible names may differ.

Fix a label association

Buttons and links

Discernible names for buttons, input buttons and links with destinations.

Fix an icon-only button

Document language

Presence and language-tag syntax. Matching the actual language remains a human decision.

See a passing example

Headings and landmarks

Heading order, main landmark and rendered regions. Structural suggestions are advisory, not a conformance verdict.

Understand rule confidence

Rendered contrast

axe checks text contrast where it can compute the foreground and background. Incomplete checks need review.

See a review item

A useful report before you even run a scan

Illustrative sample only. These are examples, not results from your website.

FAIL

Image text alternative missing

Evidence: Source HTML, #product-photo

<img id="product-photo" src="bag.jpg">

Fix: Describe the informative image in alt text, or use an empty alt attribute if it is decorative.

WCAG 1.1.1: Non-text content

REVIEW

Keyboard focus needs a person

Evidence: Interactive keyboard navigation was not tested by this scan.

Next action: Tab through the page and open its dialogs. Verify visible focus, a sensible order and a way to leave every component.

WCAG 2.1.1: Keyboard

PASS

Document language is declared

Evidence: Source HTML includes a non-empty language attribute.

<html lang="en">

Boundary: A declared language does not prove that it matches the content or that language changes are marked.

WCAG 3.1.1: Language of page

How the accessibility test works

Enter. Choose one public URL and a desktop or mobile profile. No account or website installation is needed.
Analyze. We fetch source HTML, then load a fresh browser session with the same device user agent and run selected axe rules. Separate fetches may receive different content.
Fix and recheck. Inspect evidence, apply the relevant fix, complete the manual checklist, and rerun the same profile. Continue to a project when you need a crawl baseline.

Source HTML vs rendered DOM

Source HTML reveals what the server sent before JavaScript. Rendered DOM checks see the page after scripts have started running. A script can add a missing name or introduce a new unlabeled control. The report preserves both observations instead of hiding one behind a score.

The browser waits 500 ms after DOM content loads. It does not log in, submit forms, click controls or complete consent flows. Late content, shadow DOM, cross-origin frames and interactive states may need a local test. Matching selectors are evidence groups, not a claim of component identity across different DOM trees.

Standards, methodology and honest limits

Rule catalog 2026-09-19.1, substantively reviewed 19 September 2026. Source checks use the 2-UA source subset; the actual axe-core version is shown in each rendered report.

The rendered catalog includes image-alt, label, select-name, button-name, input-button-name, link-name, html-has-lang, html-lang-valid, heading-order, landmark-one-main, region and color-contrast. The source layer also flags generic or filename-like alternative text; region and contrast remain UNKNOWN in source.

FAIL: An automated rule found an issue in the observed layer. Inspect the node and context before making a change.
PASS: A particular applicable rule found no issue in that layer. This is not a WCAG certificate.
REVIEW: A human decision is needed, or the finding is an advisory structural suggestion.
UNKNOWN: The layer or check did not run reliably, or a limit was reached. It does not count as a pass.
N/A: No applicable elements were found for that rule.

Evidence is labelled observed or heuristic. We do not produce an overall accessibility score. WCAG references explain related criteria; heading and landmark advice alone does not establish a failed success criterion.

Read the WCAG 2.2 quick reference, axe-core methodology and limitations, and Accessibility Insights automated and tab-stop workflow.

Automated checks vs manual accessibility review

Automation does not judge whether alt text is meaningful, captions are accurate or a full purchase flow works with a keyboard and screen reader. Every report includes a manual backlog covering these gaps, visible labels, focus order, error recovery, sensory meaning, zoom, reflow and target sizes.

How to fix common accessibility issues

1. Give an informative image a useful alternative

Problem → evidence: An informative product photo has no alt attribute. Describe its relevant purpose, not its filename.

<img src="bag.jpg" alt="Blue canvas shoulder bag with a front pocket">

For a purely decorative image, use alt="". The checker cannot make that editorial decision for you.

2. Connect a visible label to its input

Problem → evidence: The email input has a placeholder but no associated label. A placeholder can disappear as the person types.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

3. Name an icon-only button

Problem → evidence: A button contains an unlabeled icon. Add a name that explains the action.

<button type="button" aria-label="Close dialog">
  <span aria-hidden="true">×</span>
</button>

Retest the complete dialog with a keyboard; an accessible name does not fix focus management.

Data, privacy and scan boundaries

This tool returns a transient report in the response to your request. It does not save a public report, full page HTML or screenshot. Evidence snippets are truncated and escaped. No report URL is added to the sitemap, and result responses use noindex and private, no-store caching.

We request the submitted public page and its allowed resources. The target site will see requests from our infrastructure. Source fetches allow up to 6 redirects and 2 MB of decoded HTML. The browser is limited to 40 seconds, 80 resource requests, 2 MB per resource and 10 MB total resource bytes; only GET requests to public HTTP(S) addresses on standard ports are allowed. Compressed browser resources are rejected if the server ignores identity encoding.

Blocked resources or a 100-node evidence cap produce a visible partial result. Browser sessions are fresh, with no supplied credentials or persisted cookies. Query strings are omitted from displayed report URLs. Do not scan password-reset links, authenticated pages or URLs containing secrets.

Validation errors may temporarily retain submitted form values in your session so you can correct them. Operational request metadata and product events follow the privacy policy. Choosing monitoring explicitly saves continuation context under your account; it does not automatically save this transient report.

Accessibility checker FAQ

Is this website accessibility checker free?

Yes. You can run a rate-limited public-page check without signing up. Project monitoring and crawl limits depend on your plan.

Does a pass mean my website meets WCAG?

No. A pass belongs to a selected automated rule and one observed page state. It is not certification, a legal opinion or complete WCAG conformance. Manual evaluation remains necessary.

What data is stored?

The scan does not persist page HTML, screenshots or a public report. The result lives in this response. Monitoring continuation saves the submitted URL and selected device context only when you choose that action. See the data boundaries above and the privacy policy for operational data.

What cannot be checked from a public URL?

Authenticated flows, states behind clicks, caption quality, the meaning of alt text, complete keyboard interaction and screen-reader usability are outside this automated scan. A consent banner or blocked resource can also change what the browser sees.

Why do source and rendered results differ?

Scripts, computed styles, visibility and device-specific markup can change the result. The source checker and axe also implement different checks. Compare the evidence and rule scope rather than assuming a source-only issue is resolved.

How often should I recheck?

Recheck after template, component, content, CSS or JavaScript changes, and before important releases. Use the same device profile and add manual regression checks for your critical user flows.

Can this replace WAVE, axe DevTools or a manual audit?

Use it as a server-side preflight with source and rendered evidence. A local tool is still useful for interactive states, inspecting the live page and working through manual checks. No single automated tool establishes full conformance.