URL Accessibility Auditor

What the URL Accessibility Auditor Does

The auditor opens the URL you give it in a headless Chromium browser on our server, waits for the page to load at a 1920 by 1080 desktop viewport, and runs axe-core, the open-source rules engine behind most automated accessibility checkers. Every violation axe reports is stored with its impact level, the WCAG tags axe assigns to the rule, the CSS selector and HTML of the first offending element, and a link to the rule documentation.

Two layers sit on top of the raw scan. A weighted score turns the violation counts into a single number for tracking progress between runs, and a language model writes a short business-oriented summary, with quick wins, from the score, the counts, and the top three findings. Both are conveniences for reading the results; the findings table is the audit.

How to Use It

1. Sign in. Audits cost five credits and are saved to your account. New accounts start with free credits.
2. Enter a full public URL. Include the scheme, for example https://example.com/pricing. Pick the page you actually want to test; the scan does not follow links.
3. Wait for the three stages. Page load and axe scan, AI summary, then report assembly. Most pages finish in under a minute; the page load itself times out after 30 seconds, so a very slow site fails rather than hanging.
4. Work the findings table. Sort by impact, open each rule's help link, and locate the element with the selector. Re-run after fixing to confirm the count drops, and use Audit History to compare runs.

What It Checks and the WCAG 2.2 Criteria It Maps To

The scan runs the axe-core rules tagged wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa, and best-practice. Each violation carries the criterion tags axe attaches to the rule, which is where the WCAG mapping in the table comes from. The rules that fire most often on real sites, and the criteria they map to, include:

• Missing alternative text on images and inputs: 1.1.1 Non-text Content.
• Insufficient text contrast: 1.4.3 Contrast (Minimum).
• Form fields, buttons, and links without an accessible name, and invalid ARIA attributes or roles: 4.1.2 Name, Role, Value, with link text also mapped to 2.4.4 Link Purpose (In Context).
• Broken list and table structure: 1.3.1 Info and Relationships.
• Missing or invalid page language: 3.1.1 Language of Page; missing document title: 2.4.2 Page Titled; no skip link or landmarks: 2.4.1 Bypass Blocks.
• Small click targets under the WCAG 2.2 rule set: 2.5.8 Target Size (Minimum).

Best-practice rules, such as heading order and landmark conventions, appear in the results without a WCAG tag. They are worth fixing but are not conformance failures on their own.

What It Cannot Check

Automated rules detect a minority of WCAG failures, and this scan has specific blind spots you should plan around:

• Only the initial page state. Nothing is clicked, typed, or scrolled. Menus, modals, form validation, and anything revealed by interaction are not examined, so 3.3.1 Error Identification and dialog focus behaviour are out of reach.
• No keyboard or focus testing. 2.1.1 Keyboard, 2.4.3 Focus Order, and 2.4.7 Focus Visible need a person at a keyboard.
• Presence, not quality. The scan can tell that an image has alt text, not whether the text is meaningful, and that a video element exists, not whether its captions are accurate.
• Desktop viewport only. Reflow at 320 CSS pixels wide (1.4.10 Reflow) and mobile layouts are not exercised.
• One page, no login. Cross-page criteria such as 3.2.3 Consistent Navigation and anything behind authentication are outside the scan.
• Needs-review results are not shown. axe also returns checks it could not decide, for instance contrast on text over a background image. The report lists only confirmed violations, so those items are silently absent.

A clean scan is the point where manual testing starts, not where it ends. The automated versus manual testing guide explains what each method catches, and the step-by-step audit guide walks through the manual checks.

Reading the Output

Impact levels come straight from axe-core: critical and serious findings usually block a task for someone, moderate findings make a task harder, and minor findings are polish. The score subtracts 10, 5, 2, and 1 points respectively per finding from 100 and stops at 0, so a single page with ten critical issues scores zero, and a score of 90 or above is labelled Excellent in the interface. Use the number to compare the same page over time, not to compare different pages, which have different amounts of content to fail.

Each row in the findings table names the axe rule, its description, the WCAG tags, the selector of the first element that failed, and the fix suggestion from the rule's help text. Only the first matching element is stored per rule, so a rule that fired on forty images shows one selector; fix the pattern, not the instance. The AI Intelligence Analysis panel is generated from the score, the counts, and the top three findings only, which makes it a readable narrative for stakeholders rather than a complete plan.

Frequently Asked Questions