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

Robust4.1 CompatibleLevel AWCAG 2.0

4.1.2: Name, Role, Value

For all user interface components, the name and role can be programmatically determined; states, properties, and values can be programmatically set; and notification of changes is available to user agents.

Why this matters

Assistive technologies need to know what each element is (role), what it's called (name), and its current state (expanded, checked, selected). Without this, custom widgets are opaque black boxes to screen reader users.

Common failures

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

Custom buttons implemented as <div> or <span> without role='button'
ARIA attributes used incorrectly or on wrong elements
Missing accessible names on interactive elements
State changes not communicated (e.g. accordion expanded but no aria-expanded)
Custom select/dropdown without proper ARIA roles

How to fix

Prefer native HTML elements that have built-in roles and states
When using ARIA, follow the ARIA Authoring Practices patterns exactly
Ensure every interactive element has an accessible name (aria-label, aria-labelledby, or visible label)
Update aria-expanded, aria-selected, aria-checked etc. when state changes
Test with a screen reader to verify announcements

Related axe-core rules

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

aria-allowed-attr
aria-allowed-role
aria-hidden-body
aria-hidden-focus
aria-required-attr
aria-required-children
aria-required-parent
aria-roles
aria-valid-attr
aria-valid-attr-value
button-name
frame-title
frame-title-unique

Check your site for 4.1.2 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 4.1.2: Name, Role, Value (W3C)