Job a11y-wcag-checklist-one-flow · revised 11 October 2026
Fix one page or flow against a named accessibility checklist
One page or short flow is tested against an agreed list of WCAG 2.2 criteria, the failures are fixed, and each criterion is re-tested by hand and shown as pass or not applicable.
You might be seeing
- The page cannot be completed with a keyboard alone, or focus disappears behind a sticky banner
- Form fields have no visible labels or errors are shown only in colour
- A screen reader announces unlabelled buttons or says nothing when a message appears
No passwords, keys, card details or admin invites needed to start.
What usually happened
A page or short flow fails parts of WCAG 2.2, but the failures are unlisted, a mix of real faults and tool noise, and nobody has agreed which criteria count. Without a named list a fix cannot be accepted. The job fixes one flow against a fixed list of criteria, tests it by hand as well as with a tool, and reports each criterion as pass, fixed or not applicable.
Who it’s for: An agency, or a founder or product owner, who must improve the accessibility of one important page or short flow (sign-up, checkout, booking, contact) and needs a bounded, checkable piece of work rather than an open-ended audit.
Usually starts when: A customer, a tender or an internal review asks for the page or flow to meet WCAG 2.2 Level AA, or an automated checker reports many failures and nobody has turned them into a fixed list.
The result: Every criterion on the agreed list passes for the named page or flow at the agreed widths, in a keyboard-only run and in a run with one named screen reader and browser. You receive the fixes, a table with a result for each criterion and screen, and a list of anything outside the agreed list that we saw.
Check whether this job fits
These questions check whether this is a bounded fix against a list. They need no access or code.
Checks you can run yourself
Try the flow with a keyboard only
On the page, put the mouse aside and use Tab, Shift+Tab, Enter and Space to complete the flow from the first screen to the last.
Look for: Any control you cannot reach or use, focus that disappears or is hidden behind a banner, and any point where you are trapped. Write down the screen and the control.
What you get
- A pull request with the fixes and a note for each criterion that changed
- A results table: each criterion, each screen, the method used and pass, fixed or not applicable
- A short list of issues seen outside the agreed list, in order of likely importance
- Reversal steps and any limits found
Included
- One page, or one flow of at most five connected screens, at one address or in one staging environment
- An agreed checklist of WCAG 2.2 success criteria at Levels A and AA, fixed in writing before testing (we propose a default list of about twelve)
- Manual testing with a keyboard alone and with one agreed screen reader and browser pair, plus an automated checker for a first pass
- Fixes to markup, styles and scripts you control on those screens
- A re-test of every criterion on the list after the fixes, with a result for each screen
Not included
- A statement of legal compliance, a conformance claim for your whole site or a certificate
- Testing with several screen readers, voice control or users with disabilities
- Fixing content you do not control, such as a third-party widget or an embedded video player, beyond describing the fault
- Writing alternative text for large libraries of images, captions or transcripts
- Site-wide audits, remediation of other pages or a continuing accessibility programme
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every criterion on the agreed checklist is recorded as pass or not applicable for every agreed screen after the fixes, with the method and tester named for each.
Evidence: The results table with one row per criterion and screen.
A keyboard-only run completes the agreed flow from the first screen to the last without a trap, with a visible focus indicator on every control and no focused control completely hidden by a banner or header.
Evidence: A recording or step log of the keyboard run on each screen.
With the agreed screen reader and browser, each form control is announced with its label, each error is announced in text with the field named, and a status message after submit is announced without moving focus.
Evidence: A step log with the announced text for each control and message.
At 320 CSS pixel width each agreed screen can be used without scrolling in two directions, and the diff contains no secret and removes no content.
Evidence: Screenshots at 320 pixels, the changed-file list and a secret scan of the diff.
Sign-off. You or your authorised maintainer review the results table, try the flow with a keyboard, sign off in writing and merge. Payment follows sign-off.
If it fails. If an agreed criterion still fails after the re-test, you do not pay for this fixed scope. If a failure sits inside a third-party component we cannot change, we name it in the results table and agree with you whether to continue. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The page or flow can be reached in a staging environment or at a public address with a test account
- You can change the markup, styles and scripts of those screens, or have a developer who can
- You agree the checklist and the screen reader and browser pair before work starts
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The flow is built inside a closed tool whose output you cannot edit
- The main failures are inside a third-party component you will not replace
- You need a legal conformance statement, which this job cannot give
- The flow is longer than five screens or changes with real customer data in ways we cannot test safely
What could go wrong
Before merge, closing the pull request leaves the screens unchanged. After merge, your maintainer can revert the commit. Each fix is recorded against its criterion so a single change can be reversed on its own.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A fix satisfies a tool but not a person, for example a label that is read out wrongly. | Each criterion is tested by hand with a keyboard and a screen reader, not only with a checker. |
| A result is read as proof of compliance for the whole site. | The results table states the screens and criteria it covers and says plainly that it is not a conformance statement. |
| A change for one screen breaks another. | All agreed screens are re-tested after the fixes, and the existing tests are run. |
An independent reviewer repeats a sample of the keyboard and screen reader tests and checks that no fix hides content from some users. Your maintainer reviews and merges. We make no legal compliance claim.
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
- The W3C's evaluation guidance explains that tools alone cannot decide whether a site is accessible and offers a beginner's check you can run yourself before paying anyone. www.w3.org
- The WCAG 2.2 specification itself lists every success criterion and level, so you can write your own checklist. www.w3.org
Questions
Will this make my site compliant?
No. It fixes one page or flow against a list we agree and shows the result for each criterion. It is not a legal statement or a conformance claim for the whole site.
Why test by hand if an automated checker exists?
W3C says no tool alone can decide whether a site is accessible. A checker is used for a first pass, but each criterion is also tested with a keyboard and a screen reader.
What if a flow includes a payment widget?
We cannot change a third-party widget. We test around it, describe what is inside it, and agree with you what to do about it.
Do you test with real users with disabilities?
No. That is outside this job and worth doing separately.
Send an enquiry
Send us
- The page or flow, the number of screens and the technology it is built with
- Why it matters now (a customer request, a tender, an internal review) and any report you already have
- Which screen reader and browser your visitors most likely use, if you know
- Do not send credentials, customer data or source code in the first enquiry
Later, once you agree
- The source through an agreed company-controlled route, with a branch for the pull request
- A staging address and a test account that holds no real customer data
- Any existing accessibility report for the flow, with identifying details removed
- The name of the person who reviews and merges
You own the site and its content. We work on a branch or staging copy through a company-controlled identity, never a personal login, with a test account. Your team deploys. We make no statement about your legal obligations.
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 “a11y-wcag-checklist-one-flow” as the subject.