Website Accessibility Checker (WCAG 2.2)
Automated WCAG 2.2 checks on the rendered page, grouped by success criterion, with fixes.
Free preview.
- Free preview: the summary counts, with the first problems and items to review in full (up to 10 each) and the rest counted.
- Locked until you unlock it: download and copy.
- Unlock: Premium pass, ₹799 for 30 days, a one-time payment that never renews.
Ways to unlock shows how to get the full result.
Printing this result is locked in the free preview.
Check a page’s accessibility
Accessibility report
Automated checks find only some accessibility problems. Keyboard use, focus order, meaningful alt text, captions and clear error messages need a person to judge. This report is not a certificate of WCAG or ADA conformance.
Problems
To review by hand
axe-core could not decide these on its own (for example text over an image). Check each one in the browser.
Checks that found nothing
The page as audited
Rendered in MySmartCoPilot’s isolated sandbox without the page’s scripts, at the width you chose. A picture of the page: it is not interactive.
Locked in the free preview. Opens the ways to unlock this result.
Locked in the free preview. Batch runs unlock with a pass.
Locked in the free preview. Query results unlock with a pass.
About the Website Accessibility Checker (WCAG 2.2)
Enter a page address, or paste its HTML, and get an automated accessibility audit against WCAG 2.2 level A and AA. The page is rendered for real — with its stylesheets, so colour contrast can be measured — in an isolated sandbox, and checked with axe-core, the open-source accessibility engine from Deque Systems: missing alt text, form fields without labels, buttons and links without names, ARIA misuse, missing page language and title, low contrast, heading order and landmarks, list and table structure, small touch targets, zoom blocked by the viewport tag, duplicate ids and timed refreshes.
Results are grouped by WCAG success criterion, most serious first, with the elements affected, their HTML and selector, why each one fails, a plain-language fix and links to W3C’s explanation of the criterion. Items axe-core cannot decide are listed separately for a person to review.
Automated checks find only some problems. W3C says tools “cannot check all accessibility aspects automatically” and that human judgement is required: whether alt text is meaningful, whether the page works by keyboard, captions, focus order and clear error messages need a person. This report is not a certificate of WCAG or ADA conformance; use it to fix what it finds and plan a manual review.
How to use it
- Enter the page address in Page URL, or switch to Paste HTML and paste the page source (in the browser: View page source, select all, copy). For pasted HTML, add the page address so its stylesheets and images can load.
- Choose the screen width to check at (desktop or phone) and whether to load the page’s stylesheets and images (needed for colour contrast), then press Check accessibility.
- The page renders in the preview below, without its scripts, and the checks run. Large pages can take some seconds.
- Work through Problems criterion by criterion: each lists the elements, why they fail and how to fix them. Then look at To review by hand, where axe-core needs a person to decide (for example text on a background image).
- Without a pass the report is a free preview: every count, and the first half of the problems and review items in full. With a Premium pass you see all of them and can copy the report or download it as text, the elements as CSV or the raw results as JSON. Re-check after fixing.
Examples
<button><svg viewBox="0 0 24 24">…</svg></button>
4.1.2 Name, Role, Value (Level A) Buttons must have discernible text · critical Fix: Give the button visible text. An icon-only button needs aria-label (aria-label="Close") or visually hidden text.
<p style="color:#999">Order before 2 pm for next-day delivery</p>
1.4.3 Contrast (Minimum) (Level AA) 2.85:1, needs 4.5:1 · #999999 on #ffffff
Contrast is measured on the rendered page, with the page’s own stylesheets.
Common uses
- Checking a page before launch, or after a redesign, for the problems automated tools can find reliably.
- Giving developers a prioritised list of failures with the selector and HTML of every element.
- Checking a component, template or email snippet by pasting its HTML.
- Preparing for a manual accessibility review or user testing, so the obvious failures are fixed first.
What is checked
axe-core’s rules tagged for WCAG 2.0, 2.1 and 2.2 at level A and AA, plus its best-practice rules unless you switch them off. They cover, among others: text alternatives for images, image buttons, SVG and objects (1.1.1); structure — lists, tables and ARIA parent and child roles (1.3.1); colour contrast of text (1.4.3) and links told apart only by colour (1.4.1); zoom not blocked by the viewport tag (1.4.4); keyboard access to scrollable areas and frames (2.1.1); timed refreshes (2.2.1); bypass blocks and page titles (2.4.1, 2.4.2); link names (2.4.4); touch-target size (2.5.8, new in WCAG 2.2); page and part languages (3.1.1, 3.1.2); form labels (4.1.2) and fields with several labels (3.3.2); and names, roles and values of buttons, links, fields and ARIA widgets (4.1.2). Best practices include one main landmark, heading order, empty headings and tabindex. MySmartCoPilot adds a check for duplicate ids, which WCAG 2.2 no longer lists (4.1.1 was removed) but which still breaks labels and ARIA references.
How the page is checked
The HTML (fetched by MySmartCoPilot’s server in URL mode, or pasted) has its scripts, inline event handlers, meta refresh, autoplay and the addresses of embedded frames removed, and is rendered in your browser inside MySmartCoPilot’s isolated code sandbox, a separate site with no access to this one (how the sandbox works). There axe-core runs on the rendered page at the screen width you chose. So the audit sees the page as the server sends it, styled by its stylesheets: content that scripts build after loading is not there, and embedded frames are not audited.
Sources
WCAG 2.2 and W3C’s Understanding WCAG 2.2 for every criterion; axe-core (MPL-2.0) by Deque Systems, whose rule pages are linked from each problem; W3C WAI on the limits of evaluation tools.
Limitations
- Automated checks cover only part of WCAG. Keyboard use, focus order and visibility, meaningful alt text and link text, captions and audio description, error messages and much more need a manual review, ideally with people who use assistive technology.
- Scripts are not run, so pages that build their content with JavaScript (single-page apps) look nearly empty; check those with an accessibility extension in your own browser instead. Menus, dialogs and other states that appear on interaction are not checked either.
- Contrast needs the page’s stylesheets: if they cannot load (blocked by the website, http:// on an https page, or switched off here), contrast results are incomplete or missing, and text over images is listed for review.
- One page at one screen width is checked; other pages and widths can differ.
- A site can answer MySmartCoPilot’s server differently from a browser (bot protection, sign-in, country rules), and the server reads at most 2 MiB of HTML. Each visitor can run a limited number of fetches per hour; pasted HTML has no limit.
- This is not a certificate or legal assessment of WCAG, ADA, EN 301 549 or Section 508 conformance.
Privacy
In Page URL mode the address is sent to MySmartCoPilot’s server, which fetches the page; MySmartCoPilot does not store the address, the HTML or the result, and the server log records only the host name, status code and time of each request. The HTML is then rendered in your browser, in MySmartCoPilot’s sandbox frame; with “Load the page’s stylesheets and images” on, your browser requests those files from the website, as a visit would. Pasted HTML is not sent to MySmartCoPilot’s server.
Frequently asked questions
What do I get without a pass?
Without a pass, Website Accessibility Checker (WCAG 2.2) shows the summary counts, with the first problems and items to review in full (up to 10 each) and the rest counted. Until you unlock it, the result can’t be downloaded or copied. A Premium pass, a one-time payment that never renews, unlocks the full result. The pricing page lists the passes and their prices.
Does passing this check mean my site is WCAG or ADA compliant?
No. Automated tools find a subset of accessibility problems; W3C says they cannot check all aspects and that human judgement is required. A page with no automated failures can still be impossible to use by keyboard or screen reader. Use the report to fix what it finds, then review the page manually against WCAG 2.2 (and with users of assistive technology where you can). Conformance is a judgement about the whole page or process, not a tool result.
What do critical, serious, moderate and minor mean?
They are axe-core’s impact ratings: how much the problem is likely to get in people’s way, from blocking (critical: for example an unlabelled button) to annoying (minor). They help you order the work. Every WCAG failure needs fixing for conformance, whatever its impact.
What is “To review by hand”?
Cases axe-core cannot decide on its own: text over a background image or gradient whose contrast cannot be computed, elements partly hidden, and similar. Look at each one in the browser and decide.
Why do best practices appear separately?
They are good practice that WCAG does not strictly require, such as having one main landmark, headings that go down one level at a time, or unique ids. Fixing them makes pages easier to use with screen readers. Switch them off if you only want WCAG failures.
Why is my JavaScript-built page nearly empty?
For safety, the page’s scripts are not run: the audit checks the HTML the server sends, rendered with its stylesheets. For a single-page app, run axe-core in your own browser (for example with Deque’s axe DevTools extension) on the running app, or paste the rendered HTML (in the browser’s developer tools: copy the <html> element’s outer HTML) here.