Audits
An audit is one URL analyzed with one device type.
Audits belong to a plan, and they are always created and listed in groups.
Open a plan from Plans to reach its audits at /accessibility/audits?projectId=<id>.
Plan overview
The top of the page summarizes the plan.
| Metric | Shows |
|---|---|
| Total Audits | Audits created for this plan. |
| Success | Passed check runs across the plan. |
| Failed | Failed check runs across the plan. |
| Accessibility Score | The plan's overall score, with a plain-language rating. |
Total Audits, Success, and Failed sit together on the plan's information card; Accessibility Score has its own card beside it.
A plan with no completed audit shows Not Scored.
Creating an audit
- Select New Audit.
- Give the group a Title, or leave it empty.
- Choose a Device Type: Web, Mobile, or Desktop.
- Add the URLs to test.
- Select Save to create the audits without running them, or Save and Start Audit to create and analyze them at once.
The New Audit button requires accessibility:audit:create.
URLs
Each row combines the plan's base URL, which is fixed, with a path you type, such as /, /about, or /contact.
The full URL is previewed under the row as you type.
An empty path is treated as /, and duplicate URLs are rejected.
Each row has a Public checkbox, and an All Public toggle sets every row at once.
- Public — the page is reachable without signing in, so it is analyzed through the PageSpeed/Lighthouse API.
- Not public — the page requires the plan's authentication configuration, so it is analyzed through the audit runner.
Marking a URL as not public only works if the plan has authentication enabled. See Plans for how to configure it.
Audit groups
Everything you create in one New Audit submission becomes a single group, also called a batch.
A group shares a title, a device type, and a run history, and it carries average scores for its audits. A group with no title is shown as Untitled Audit.
Choosing Save and Start Audit opens the audit report right away, with one tab per URL.
Audit history
The Audit History table lists groups as collapsible rows, with the audits inside each group.
The columns are URL, Status, Accessibility, Performance, Timeline, and Actions.
Performance and accessibility are separate Lighthouse metrics. Performance measures page speed; accessibility measures compliance with accessibility checks.
A WCAG 2.2 button opens a quick-reference drawer without leaving the page.
Group actions
| Action | Effect | Permission |
|---|---|---|
| View All Runs | Opens the group's batch run history. | — |
| Edit Audit | Changes the group's title, device type, URLs, and per-URL public flags. | accessibility:audit:update |
| Start All Audits | Re-analyzes every audit in the group in one request. | accessibility:audit:create |
Audit actions
| Action | Effect | Permission |
|---|---|---|
| View Runs | Opens the run history for that single audit. | — |
| Start Audit | Re-analyzes that audit, creating a new run. | accessibility:audit:create |
| Delete | Removes the audit and all of its results. | accessibility:audit:delete |
Selecting an audit row opens its report.
Status and live updates
| Status | Meaning |
|---|---|
| Not Analyzed | The audit was saved but never run. |
| Pending | Queued for analysis. |
| Analyzing | Analysis is in progress. |
| Completed | Results are available. |
| Failed | The analysis could not be completed. |
While any audit in the list is pending or analyzing, the table refreshes every five seconds and stops polling once everything reaches a final state. It also refreshes when you return to the browser tab.
An audit report opened on a running audit shows a progress screen with an elapsed timer, cycling through the analysis stages: initializing the audit, loading the page, running the WCAG 2.2 checks, capturing screenshots, and generating the report. That screen polls every five seconds and switches to the report as soon as the audit finishes.
If an audit fails, the report page explains that the failure may be caused by network problems, page loading problems, or an invalid URL, and offers Try Again, which requires accessibility:audit:create.
Reading an audit report
The report at /accessibility/audit-report shows one audit, or a tab per URL when several audits were started together.
The header carries the accessibility score gauge, the device badge, the audited URL, the plan name, the analysis start time, and the engine version.
Below it, five counters break down the checks: Total Audits, Passed, Failed, Manual, and Not Applicable.
Findings
Results are grouped by the check categories Lighthouse reports for the page; anything it does not recognize is collected under Other.
Groups with failures are expanded by default. Within a group, failed checks are listed first, then the passed checks, collapsed behind a count you can expand, and then the manual checks.
Expanding a failed check lists each offending element with:
- the CSS selector,
- the HTML snippet,
- the explanation of what is wrong,
- the element's text content,
- a screenshot of the element, cropped from the page screenshot.
An element that falls outside the captured viewport is labeled Element outside screenshot viewport instead of shown.
When the run produced manual checks, an Items to Manually Check panel at the foot of the report gathers them all in one place.
Refine with AI
Failed elements that carry an explanation have a Refine with AI button.
It sends the check title, description, selector, snippet, and explanation to the AI service and returns three sections you can copy individually:
| Section | Content |
|---|---|
| Problem | What is wrong with the element. |
| How to Fix | The recommended remediation. |
| WCAG Criteria & Testing | The WCAG reference and a simple step to verify the fix. |
A group that has suggestions available is marked with a sparkle icon next to its failure count.
Requesting a suggestion consumes an accessibility fix credit, which is refunded if generation fails. Suggestions are cached per audit and per finding, and the cache is cleared when the audit is re-analyzed.
Create Issue
Create Issue on a failed element opens the issue form pre-filled with the check title, description, selector, snippet, and explanation.
From there the issue can be saved in RabbitQA or sent to Jira or Azure DevOps. See Issue Tracker for the details.
Run history and versions
Every analysis is stored as a numbered run, so results are never overwritten.
Single audit
/accessibility/audits/<auditId>/runs lists every run for one audit.
| Column | Shows |
|---|---|
| Run Date | When the analysis started. |
| Status | The run's final state. |
| Accessibility | Accessibility score for that run. |
| Performance | Performance score for that run. |
| Best Practices | Best practices score for that run. |
| SEO | SEO score for that run. |
| Duration | How long the analysis took. |
The newest run is badged Latest.
Opening a run shows that version exactly as it was executed, including the device type it ran with, even if the audit has been edited since.
Audit group
/accessibility/batch-runs?batchId=<id> lists the runs for a whole group, organized by URL.
Each URL expands into its own run table with the version number, status, and the accessibility, performance, best practices, and SEO scores, with a shortcut to open the report for that run.
Related pages
- Plans — where audits and authentication are configured.
- Reports — every audit across every plan in one list.
- WCAG Compliance — what the checks map to, and how the score is weighted.
