xsbl is an AI-powered web accessibility scanner that checks your website against WCAG 2.2 AA and AAA criteria. It scans your rendered pages in a real browser, identifies violations like missing alt text, contrast failures, broken ARIA, and keyboard traps, and generates specific code fix suggestions for your actual markup.

How is xsbl different from accessibility overlays?

Unlike overlays that inject JavaScript and only detect about 30% of WCAG issues, xsbl scans your actual rendered DOM in a real Chromium browser. It provides real code fixes instead of cosmetic patches, works with screen readers rather than against them, and produces exportable compliance evidence accepted by courts and auditors.

Does xsbl support WCAG 2.2?

Yes. xsbl covers 90+ rules across WCAG 2.2 AA and AAA criteria, including contrast, alt text, ARIA, keyboard navigation, forms, headings, landmarks, and more. Each issue is mapped to the specific WCAG success criterion it violates.

Can xsbl create GitHub pull requests with accessibility fixes?

Yes. Connect your GitHub repository and xsbl can generate pull requests with AI-suggested code fixes for accessibility issues. You can fix individual issues or use bulk fix to address multiple issues in a single PR.

How much does xsbl cost?

xsbl offers a free tier with 1 site and 3 scans per month. Paid plans start at $19/month for Starter, $69/month for Pro with unlimited sites and 100 scans, and $249/month for Agency with white-label reports, VPAT generation, and dedicated support.

All WCAG criteria

Understandable3.3 Input AssistanceLevel AWCAG 2.0

3.3.1: Error Identification

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Why this matters

When form validation fails, users need to know which field has an error and what went wrong. Relying on color alone (a red border) is invisible to screen reader users and people with color blindness.

Common failures

These are the most frequent ways this criterion is violated in real-world websites:

Error messages not associated with the input field
Errors indicated only by color change
Generic messages like 'There was an error' without specifics
Error messages that disappear before the user can read them

How to fix

Use aria-describedby to associate error messages with inputs
Set aria-invalid='true' on fields with errors
Provide specific error text: 'Email address must include @' not just 'Invalid input'
Use role='alert' or aria-live='polite' for dynamically displayed errors

Related axe-core rules

xsbl uses axe-core to automatically detect violations of this criterion. The following rules are checked:

aria-input-field-name

Check your site for 3.3.1 violations

xsbl scans your rendered pages in a real browser and finds violations of this criterion automatically.

Scan your site free

Official reference: Understanding WCAG 3.3.1: Error Identification (W3C)