Job audit-accessibility-report-for-one-flow · revised 11 October 2026
An accessibility audit report for one user flow, against WCAG 2.2 A and AA
One flow of up to eight pages or states is tested with scans, keyboard use and a screen reader. You get a findings report against WCAG 2.2 A and AA. It is not a conformance statement.
You might be seeing
- Nobody has tried to complete the flow using only a keyboard or a screen reader
- An automated scan was run and came back clean, and it is unclear what that does and does not show
No passwords, keys, card details or admin invites needed to start.
What usually happened
A key flow has never been evaluated for people who use a keyboard, a screen reader, zoom or high contrast, and automated scanners find only part of the problems, so a clean scan is easily mistaken for accessibility. The job is a structured evaluation of one flow, covering every page and state in it, with each finding tied to a WCAG 2.2 success criterion and steps to reproduce. It reports barriers. It does not fix them and it is not a conformance statement.
Who it’s for: A business owner or product manager with an online flow such as sign-up, booking or checkout, who has been asked about accessibility and does not know where the barriers are.
Usually starts when: A customer, a tender questionnaire or a partner asks whether the flow is accessible, or someone reports that they could not finish it using a keyboard or a screen reader.
The result: One named flow of up to eight pages or states has a written audit report in which each finding cites the WCAG 2.2 criterion and level, the page and element, steps to reproduce, who is affected and a suggested fix, with a criteria matrix and a list of what was not tested. Your developers can turn it into work items.
Check whether this job fits
Answer from what you know about the flow. These checks show whether one flow can be evaluated safely and whether a barriers report is what you need.
Checks you can run yourself
Try the flow with the keyboard alone
On the live or test copy, complete the flow using only the Tab, Shift+Tab, Enter, Space and arrow keys. Note every place where you lose sight of where you are, cannot reach a control or cannot continue.
Look for: Any point where you are stuck is a barrier worth reporting. This quick check covers a few issues only; W3C's own Easy Checks say that a page can seem to pass them and still have significant barriers.
What you get
- The audit report with findings ordered by severity
- A criteria matrix: each applicable Level A and AA criterion per page or state, marked barrier found, no barrier found in the tested conditions, not applicable or not tested, with a reason for every not tested
- The method statement: browsers, assistive technologies and their versions, settings and the dates of testing, with the automated scan outputs attached
- A first-fixes list ordered by effort and impact, written for the developers who will act on it
Included
- One user flow of up to eight pages or states, such as browse, basket, address, payment in test mode and confirmation, at one public or test address we are allowed to use, agreed in writing
- Assess each page and state against the WCAG 2.2 Level A and AA success criteria that apply to it, using automated scans, keyboard-only use, text resized to 200 percent and a screen reader on one agreed browser pairing
- Record each barrier with steps to reproduce, the criterion it fails, the element, who it affects and a suggested fix
- Record the criteria where no barrier was found in the tested pages, browser and assistive technology, those that do not apply and those that could not be tested, so the report shows what was checked as well as what was found. A finding of no barrier describes those tested conditions only; it is not a pass of the criterion
Not included
- A statement of conformance, a certification, a legal opinion or any claim that the flow meets an accessibility law or regulation
- Fixing the barriers, or retesting after they are fixed: a retest is quoted separately
- Pages outside the named flow, mobile apps, PDFs and other documents, or review of video captions beyond noting that they are missing
- Testing with disabled users, which a specialist evaluation would add and this report does not replace
- Level AAA criteria
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The report covers every page and state of the agreed flow, and the criteria matrix marks each applicable WCAG 2.2 Level A and AA criterion for each page or state as barrier found, no barrier found in the tested conditions, not applicable or not tested, with a stated reason for every not tested. No cell is marked pass or conforms.
Evidence: The criteria matrix compared against the flow's list of pages and states.
Every finding states the criterion number and level, the page and element, steps to reproduce, who is affected and a suggested fix, and a developer you choose can reproduce three findings you pick using only those steps, or every finding if the report has fewer than three.
Evidence: The written findings and your developer's confirmation for the three findings.
The method statement names the browsers, assistive technologies and versions, the settings and the dates, and the automated scan output for each page and state is attached.
Evidence: The method statement and the attached scan files.
The report states plainly on its first page that it is not a conformance statement, certification or legal opinion, that it describes only the tested pages, browser and assistive technology, and that a finding of no barrier does not mean the criterion is met everywhere; it also lists what is out of scope and what was not tested.
Evidence: The report's opening page and its scope and limits section.
Sign-off. You read the report and the matrix, have your developer try the three spot-check findings, sign off in writing and decide what to fix. Payment follows sign-off.
If it fails. If the report does not meet the agreed checks, you do not pay for this fixed scope. If a page or state in the flow cannot be reached, it is listed as not tested with the reason, and we say so rather than guess.
When it fits, and when we stop
It fits when
- The whole flow can be completed at a public or test address with synthetic accounts and without a real payment
- You can name the flow's start and end and the pages and states in it, eight or fewer
- Someone on your side, or your developers, can act on a list of findings
We stop and tell you if
- The flow needs a real payment, a real identity check or a captcha that cannot be passed in a test setting
- The flow can be reached only with real customer data or accounts
- The flow has far more than eight distinct pages or states: we propose splitting it into separate flows instead of sampling
What could go wrong
The audit only observes your website using test accounts and changes nothing on it, so there is nothing to roll back. We delete the synthetic accounts' data from our side when the job ends, and you can remove the accounts on yours.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The report is read as a certificate, or as proof that the site meets an accessibility law. | The report says on its first page that it is a list of findings against selected success criteria, not a conformance statement, certification or legal opinion, that it describes the tested conditions only, and lists what was not tested. The matrix never uses the word pass. |
| Results differ with other browsers or assistive technologies than the ones tested. | The method statement names the browsers, assistive technologies and versions used, and the report claims nothing beyond them. |
| The flow changes during testing, so findings no longer match the live site. | The tested revision and dates are recorded, and you are asked to freeze or tell us of planned changes in advance. |
| A finding is wrongly classified or cannot be reproduced. | Every finding carries steps to reproduce, and a second evaluator re-tests a sample before delivery. You can ask us to explain any finding. |
A second evaluator re-tests a sample of findings and checks the report for wording that could be read as a conformance claim or a legal opinion. Your own team decides what to fix and when.
Need to keep it working?
A retest after your developers have fixed the findings, or an audit of a further flow, is agreed as a separate written scope.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- W3C's Easy Checks are a free first review you can do yourself: page title, images, headings, contrast, resizing, keyboard use, forms and more. The page says they are quick, not definitive. www.w3.org
- Playwright documents running axe-core accessibility scans inside automated tests, which suits a developer who wants the automated part on every build. It says many problems still need manual testing. playwright.dev
Questions
Is this an accessibility compliance audit?
No. It is a technical evaluation of one flow that lists barriers against WCAG 2.2 A and AA criteria. We do not certify conformance or give legal advice, and the report says so on its first page.
Why only one flow?
WCAG conformance applies to complete processes, so every page in a flow counts, and each needs checking by hand. One flow tested properly is more useful than many tested lightly. Further flows are separate audits.
Will you fix the problems?
Not in this job. The report gives steps to reproduce and suggested fixes for your developers. If you want us to fix a short agreed list of criteria on up to five screens, that is a separate fixed-price job, listed in the related products. Retesting is also a separate scope.
Does 'no barrier found' mean the flow meets WCAG?
No. It means we found no barrier for that criterion on the pages and states we tested, with the browser and assistive technology named in the method statement. WCAG conformance applies to complete processes, and no tool or single evaluation alone can determine it, so the report never marks a criterion as passed or the flow as conforming.
Why not just run an automated scanner?
A scanner finds only part of the problems. Keyboard use, focus order, labels that make sense and screen reader behaviour need a person to check them. We use scanners as one input and attach their output.
Send an enquiry
Send us
- The flow in a sentence, with its first and last page, the address of a public or test copy and the number of pages or states
- The website's platform in general terms, and why accessibility came up, such as a customer question
- Whether you want a list of barriers to fix, or a formal statement or certificate (a different need)
- Do not send passwords, real accounts or customer data in the first enquiry
Later, once you agree
- The agreed address and synthetic test accounts created for this job, with test-mode payment details if a payment step is in the flow
- A freeze or a note of any planned changes to the flow during testing, so the report states what was tested
- The person who accepts the report and the developer who will read the findings
You own the website, its accounts and its content. We use only the synthetic test accounts you create, through a company-controlled identity, never a personal login, and we do not touch real customer data or production settings. You decide what to fix and when.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “audit-accessibility-report-for-one-flow” as the subject.