Accessibility testing and WCAG reports

Understand page-level axe-core findings and generate a separate WCAG 2.2 A/AA evidence report from a completed, authenticated scan.

AegisRunner provides two related accessibility views:

Page-level accessibility findings collected during a normal scan.
WCAG reports, a separate evidence phase you run from a completed web scan.

They answer different questions. Page findings help developers fix individual elements. A WCAG report records the scope, sample, authenticated reach, detected failures, exclusions, and limitations in one printable document.

Page-level accessibility findings

During a web scan, AegisRunner runs axe-core against rendered pages it reaches. Open Overview, select a page, then choose Accessibility to see:

the axe-core rule and impact;
the number of affected elements;
the rule description;
a link to the rule guidance;
the page on which the issue was observed.

The Issues and Issue families views help group repeated findings across pages, such as one shared component causing the same accessible-name failure throughout an app.

Generate a WCAG report

Complete a web scan with a useful page inventory.
Open the project and select WCAG reports in the project navigation.
Choose the completed scan from the scan picker.
Confirm the App access status shown at the top of the page.
Select Generate WCAG report.

The report runs as a separate browser phase. You may leave the page while it continues.

Saved App access is reused

Do not enter the same login again in the report screen. A WCAG report automatically reuses either:

saved session cookies; or
a saved web password login.

If saved cookies no longer reach the protected pages and a password login is also available, AegisRunner establishes a fresh session and retries those pages. The report records how many protected pages were selected and how many were actually audited.

Configure or review access under App access. Without supported saved access, the report checks public pages only and may refuse to produce an artifact when important protected pages are missing.

What the report contains

The printable HTML artifact leads with coverage:

total pages discovered by the completed scan;
structured and random sample sizes;
pages successfully audited;
pages reached behind sign-in;
pages excluded by safety policy or not audited;
coverage grouped by page role;
missing roles expected for the detected site type;
failures grouped by WCAG 2.2 Level A and AA success criterion;
a complete WCAG 2.2 A/AA criterion matrix that keeps unevaluated criteria visible;
axe-core results that require human judgement, kept separate from failures and passes;
the number of automated rule/page checks that passed or were not applicable, explicitly not presented as a count of WCAG criteria satisfied;
EN 301 549 v3.2.1 clause 9 references where that published standard maps the criterion;
per-page rule detail and affected element counts;
axe-core version, sampling method, and reproducible random seed;
the audit and source-crawl references, browser viewport, evaluator and tool version;
a visible manual-evaluation matrix covering keyboard, assistive technology, content alternatives, responsive states, dynamic interactions, complete processes, and accessibility support;
explicit automated-testing limitations and a “conformance not determined” statement.

Use Open report to inspect or print it, or Download HTML to retain the self-contained artifact.

Why a report may be refused

AegisRunner does not produce a document when the coverage floor is not met. The WCAG reports page shows the exact reasons, which can include:

the completed scan discovered too few pages;
too much of the selected sample failed to load;
protected pages could not retain an authenticated session;
an important page role, such as checkout or account settings, was not found;
the scan inventory was incomplete;
safety policy excluded too much of the sample.
the scan target is private, loopback-only, or cluster-only and therefore cannot be sent to the protected audit browser.

A refusal is not an accessibility verdict. It means the automated evidence is too incomplete to circulate as a report.

What the report does not claim

Automated rules detect genuine failures, but they cannot establish full WCAG conformance. Manual evaluation is still required for areas including:

keyboard-only operation and focus behavior;
screen-reader and other assistive-technology experience;
the meaning and quality of text alternatives;
content clarity and instructions;
interaction states such as dialogs, validation, and expanded controls;
complete multi-step user processes.

The artifact is therefore not a certification, a VPAT, legal advice, or a statement of conformance. It is a dated record of automated findings and the pages actually examined.

WCAG version

The current report targets WCAG 2.2 Level A and AA. It includes the WCAG 2.2 additions for focus visibility, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication. axe-core automates only rules it can evaluate; the complete matrix and manual-review section keep the remaining criteria explicitly undetermined.

EN 301 549 v3.2.1 currently references WCAG 2.1. The report therefore shows its clause 9 references only where applicable and labels newer WCAG 2.2 criteria as not mapped instead of inventing a legal equivalence. See the W3C WCAG 2.2 conformance requirements and the European Commission’s standards and harmonisation guidance.