An accessibility finding is useful when a team can reproduce it, understand its evidence and track what happens next. A list of rule violations without that context becomes a backlog nobody trusts.
This platform work combines automated inspection, evidence capture and issue management, with AI assistance for interpretation and reporting where supported.
The problem
Teams get long scan reports with no evidence, no owner and no way to tell a fixed issue from one that moved. Automated checks also cover only part of accessibility, and a green result is easily misread as compliance.
What the system does
- Scans of authorised targets, including pages behind a sign-in, using browser workers.
- Evidence kept with each finding, such as the element, the page state and the rule it triggered.
- Repeated runs compared over time, so recurrence and resolution are visible.
- Scoped reports, with AI assistance for grouping and explaining findings where supported.
A representative journey
- Step 1: Configure a targetName the authorised site or app, how to sign in and which journeys to cover.
- Step 2: Run applicable checksWorkers load the pages or screens and run the checks that apply to that surface.
- Step 3: Retain evidenceEach finding keeps what was found, where and the state of the page, so a developer can reproduce it.
- Step 4: Group and triageSimilar findings are grouped. A reviewer confirms, dismisses or assigns them.
- Step 5: Compare a later scanA later run shows what was fixed, what remains and what is new.
- Step 6: ReportA report scoped to what was actually tested, with the limits of automated checking stated.
Findings across two scans · synthetic site
Automated checks only| Finding | Impact | Scan 1 | Scan 2 | Status |
|---|---|---|---|---|
| Form field has no label | Serious | Open | Open | Recurring |
| Low contrast on button | Moderate | Open | Fixed | Resolved |
| Dialog traps focus incorrectly | Serious | — | Open | New |
Evidence kept: element path, page state at scan time, the rule that fired, device and browser context.
Not covered: criteria that need a person with assistive technology. A clean scan is not a compliance statement.
Working prototypeUse a small working version of this on invented data, the way a person would.
Try the prototypeInspect the system
This anatomy is a proposed description of how such a system is put together. It is not an audit of a specific deployment.
Inspect the system
How AI-assisted accessibility audit platform is put together
- What it is
- Job intakeReceives a request to scan an authorised target.
- What flows through it
- A target, access details and scope go in. A queued job comes out.
- The decision
- Only a target the requester is entitled to test is accepted.
Read the whole system as a list
- Job intake. Receives a request to scan an authorised target. Flow: A target, access details and scope go in. A queued job comes out. Decision: Only a target the requester is entitled to test is accepted.
- Browser and device workers. Load pages or screens and run checks. Flow: A job goes in. Raw results and captured page state come out. Decision: The worker type matches the target: mobile web and native are not conflated.
- Rule and evidence processing. Turns raw results into findings with evidence. Flow: Raw results go in. Findings tied to an element, a rule and a snapshot come out. Decision: Evidence is captured at scan time, so a developer can reproduce the finding.
- Retrieval and AI assistance. Optional help to explain and group findings. Flow: Findings and reference guidance go in. Plain-language explanations and groupings come out. Decision: AI assists a reviewer and does not decide what is compliant.
- Issue store and reporting. Tracks findings across scans and produces reports. Flow: Findings from each run go in. Status over time and reports come out. Decision: Reports state what was tested and what automation cannot judge.
Key decisions
Evidence travels with the finding
A finding a developer cannot reproduce gets closed without a fix. Capturing the state at scan time removes the argument.
Say what automation cannot see
Automated checks cover a subset of accessibility criteria. Reports state this, instead of implying a clean scan means an accessible product.
Web and mobile are different surfaces
Mobile web and native-app instrumentation are not the same thing. Each is described by what it actually supports.
Outcomes and limits
We publish no measured outcomes for this project, because we have none we can evidence. The description above is of what the system does, not of results it has produced.
- AI assists with interpretation. It does not certify accessibility or replace manual testing with assistive technology.
- Mobile web and native app coverage differ, and the exact supported surfaces are not listed here.
- This is anonymised professional experience, not a Nupgrade product. No customer, screenshot or code is shown.
Guardrail
Automated checks and AI guidance do not certify accessibility. Reports state what was tested and what was not.
Technical detail
Technology named in the portfolio for this kind of system. Which parts a given engagement used is not stated.
- Browser automation workers
- Serverless processing
- Rule engine
- Retrieval and model APIs
- Issue store