Accessibility Module

Accessibility is RabbitQA's WCAG 2.2 auditing module for web pages.

It runs Lighthouse-based accessibility analysis against the URLs you define, stores every run as a versioned result, and shows each failing element with its selector, code snippet, explanation, and screenshot.

What the module does

• Lighthouse-based audits — public pages are analyzed through the Google PageSpeed/Lighthouse API; an external audit runner is used as a fallback.
• Authenticated audits — pages behind a login are analyzed through the audit runner, using either a basic form-login configuration or a Puppeteer script built in the plan.
• Plan-based organization — a plan holds a base URL, an optional authentication configuration, and all of its audits.
• Batched audits — one audit request creates a group of audits that share a title, a device type, and a run history.
• Versioned run history — every analysis is stored as a numbered run so you can compare a page over time.
• AI fix suggestions — a failed finding can be sent to the AI service, which returns the problem, a fix, and a verification step.
• Issue creation — a finding can be turned into an issue and pushed to Jira or Azure DevOps.
• WCAG 2.2 reference — a built-in, searchable copy of the WCAG 2.2 principles, guidelines, success criteria, and conformance rules.

Scores

Each completed audit produces an accessibility score from 0 to 100, alongside performance, best practices, and SEO scores from the same Lighthouse run.

A plan carries an overall score, and each audit group carries an average of the scores of its audits.

Score	Rating
90-100	Excellent accessibility compliance
75-89	Good accessibility compliance
60-74	Fair accessibility, improvements needed
0-59	Critical accessibility issues detected

The accessibility score is a weighted average of individual Lighthouse accessibility checks, weighted by axe user impact. Each check is pass or fail with no partial credit. The full weight table is in the WCAG Compliance reference, on the Scoring tab.

Check results

Within an audit, every Lighthouse accessibility check lands in one of four states.

State	Meaning
Passed	The page meets the check.
Failed	The page violates the check; elements are listed.
Manual	The check cannot be automated and needs a human review.
Not applicable	Nothing on the page is subject to the check.

Only failed checks list elements, and only failed elements with an explanation offer AI fix suggestions and issue creation.

Navigation

Page	Route	Purpose
Dashboard	/accessibility/dashboard	Module totals, score distribution, and project shortcuts.
Plans	/accessibility/projects	Create and manage plans, including authentication settings.
Audits	/accessibility/audits	Run audits for a plan and read audit reports.
WCAG Compliance	/accessibility/compliance	Static WCAG 2.2 standards reference.
Issue Tracker	/accessibility/issue-tracker	The shared RabbitQA issue tracker.
Reports	/accessibility/reports	Every audit across every plan, with filters.

Opening /accessibility redirects to the dashboard.

Getting started

1. Create a plan in Plans with the base URL of the site you want to audit.
2. If the pages need a login, configure authentication on the same plan.
3. Open the plan and create an audit for one or more paths, as described in Audits.
4. Read the report, then use Refine with AI or Create Issue on the findings you want to act on.
5. Track everything across plans from Reports.

Permissions

Access is controlled by the accessibility:plan:*, accessibility:audit:*, and accessibility:report:* permission keys.

Key	Controls
accessibility:plan:read	Viewing plans and their statistics.
accessibility:plan:create	The New Plan button.
accessibility:plan:update	Editing a plan.
accessibility:plan:delete	Deleting a plan.
accessibility:audit:read	Viewing a plan's audits and their run history.
accessibility:audit:create	The New Audit button, starting or re-running an analysis, and retrying a failed audit.
accessibility:audit:update	Editing an audit group.
accessibility:audit:delete	Deleting an audit.
accessibility:report:read	The Reports page, an audit report, and the WCAG Compliance reference.

Creating an issue from a finding is gated separately, on the tracker's own integration:issue:create key rather than on an accessibility key.

Controls you do not have permission to use are hidden rather than disabled.

Related modules

• TestPilot — the Issue Tracker page in this module is TestPilot's tracker, and issues you create from an audit report appear there.
• MobileHub — MobileHub has its own, separate device-level accessibility auditing at /devicer/accessibility, for apps running on real devices rather than web pages.

note

This module audits web pages only. There is no CI/CD quality gate, no screen-reader execution, and no automatic regulation mapping.