A passing automated WCAG test does not prove that a website works with a keyboard, screen reader, or high zoom. The client needs clear acceptance criteria and documented manual testing before approving the delivery.
At the approval meeting, the web agency presents a green report from an automated tool. Yet it does not show whether the mobile menu can be opened without a mouse, whether focus becomes trapped behind a dialog, or whether form errors are announced by a screen reader. An accessibility audit that stops at the green indicator therefore leaves the client with a promise, but no evidence that the agreed work has been delivered.
The problem often becomes apparent only after launch, when a user cannot complete a purchase, submit an enquiry, or book an appointment. By then, remediation is more expensive and responsibility is less clear: was the defect part of the agency's delivery, a third-party service, or a later change? This is how we would approach approval: manually test the most important user journeys, define observable acceptance criteria, and link every claim to a documented result.
An accessibility audit must follow real user journeys
A green scan is a starting point, not proof of delivery. Tools such as axe DevTools, Lighthouse, and WAVE can detect many machine-identifiable problems, including certain missing form labels, incorrect attributes, and insufficient contrast. However, they cannot determine whether the focus order is understandable, whether link text provides the right information in context, or whether an error message actually helps the user move forward.
Manual accessibility testing should therefore be based on tasks that provide business value: finding a service, navigating to the right page, using search, submitting a contact form, signing in, making a booking, or completing a purchase. Each test case needs a clear starting point, numbered actions, and an observable end result. A mobile menu test could, for example, specify that the tester opens the menu using the keyboard, moves through the options, closes it without a mouse, and checks that focus returns to the menu button.
Keyboard testing shows whether functions can be reached at all. Screen reader testing shows whether names, instructions, status changes, and error messages are communicated, while magnification and a narrow viewport reveal whether content is obscured, cut off, or requires awkward movement in multiple directions. Relevant combinations may include NVDA with Firefox and VoiceOver with Safari, but the agreed environment should reflect the website's technology and target audience.
| User journey | Test steps | Assistive technology | Expected result | Illustrative outcome | Status |
|---|---|---|---|---|---|
| Mobile menu | Open, navigate, and close without a mouse | Keyboard | All options can be reached and focus returns to the menu button | Focus moves to the beginning of the page | Non-conformity |
| Contact form | Submit the form with a required field left empty | NVDA and Firefox | The error is identified and an understandable instruction is announced | The error text is visible but is not announced | Non-conformity |
| Consent dialog | Open, select a setting, and close | Keyboard and screen reader | The dialog can be used and exited without losing focus | The expected behaviour is achieved in the example case | Passed |
| Search results | Enlarge the text and reduce the viewport width | Browser zoom | The search field, filters, and results remain usable | A button is obscured by adjacent text | Non-conformity |
The value of the record lies in enabling another person to repeat the check. A status of “passed” should mean that the actual outcome matches the expected result, not merely that the tester visited the page. Screenshots, short screen recordings, and links to issue tickets make observations easier to understand and reduce the time otherwise spent reproducing the problem.
Acceptance criteria must specify functionality, environment, and blocking conditions
The difference between “the website must meet WCAG” and a useful acceptance criterion is the ability to determine whether the delivery actually satisfies the requirement. Website acceptance testing should describe what the user must be able to do, which page types and components are included, and which browsers, devices, and assistive technologies must be used for testing. Without this scope, the client and supplier may interpret the same promise in entirely different ways.
For keyboard use, the criterion may state that all interactive components must be reachable, operable, and exitable without a mouse or touchscreen. The focus indicator must be visible and follow an understandable order. This relates to W3C's WCAG 2.2, including WCAG 2.2 – 2.1.1 Keyboard and WCAG 2.2 – 2.4.7 Focus Visible.
The environment needs to be equally specific. State the browser, operating system, assistive technology, and relevant device, and document the versions used at the time of testing. For a React-based booking dialog, the combination of framework, custom code, and third-party libraries may create different defects from those found in a standard WordPress form; testing a single standard page is therefore not enough.
Blocking conditions should be agreed before delivery. A defect that prevents navigation, makes a dialog impossible to close, or blocks a high-priority form journey should not suddenly be reclassified as launch approaches. Minor non-conformities may be handled through an explicitly accepted remediation plan, but the plan needs to specify the responsible party, the next decision, and retesting requirements—even when the defect exists in a chat tool, consent solution, or another third-party component.
| Component | Test environment | Passing behaviour | Blocking defect | Retest |
|---|---|---|---|---|
| Main menu | Agreed browsers with keyboard use | All options can be reached, activated, and exited with visible focus | The menu cannot be opened, closed, or navigated | The full keyboard sequence is run again |
| Form | NVDA with Firefox and VoiceOver with Safari | Labels, instructions, and error messages are communicated clearly | The user cannot find or correct an error | Both unsuccessful and successful submissions are tested |
| Dialog | Keyboard and screen reader | Focus moves into the dialog, is managed logically, and returns when it is closed | Focus moves behind the dialog or the user becomes trapped | Opening, interaction, and closing are repeated |
| Carousel | Keyboard, screen reader, and magnified view | The controls can be used and the content remains readable | Movement cannot be stopped or controls are hidden | All states and controls are reviewed again |
A matrix like this makes the discussion less personal and more objective. The agency knows what must be built and tested, while the client can distinguish blocking issues from those that may receive planned remediation. This reduces the risk of late negotiations, additional development work, and lost business when key journeys do not work for all users.
Delivery evidence must make every claim traceable
Delivery evidence creates a chain from the requirement to the test and then to the published version. The report should state the scope, tested URL or environment, build identifier, testing date and time, browser, assistive technology, and responsible tester. For a WordPress website, relevant theme and component versions may need to be documented; for a separate React application, a build or version ID may be more useful.
Each result should then be linked to a page, component, or user journey. The record needs to show the test steps, expected outcome, actual outcome, and status, and refer to relevant evidence. A screenshot may show a hidden focus indicator, while a short screen recording is often more appropriate for focus order, keyboard traps, or an error message that is not announced by the screen reader.
A summary label such as “passed” is not enough if it is unclear which version was tested. If code, content, or a third-party script changes between testing and publication, the report may apply to something other than the website users actually encounter. The client must therefore be able to trace the evidence all the way to the delivery that is ultimately approved.
Non-conformities should remain visible until a decision has been made. The issue should state the affected function, reproduction steps, responsible party, and whether the problem will be fixed or explicitly accepted. After remediation, the same test case is run again, because “fixed” describes an activity, whereas a passed retest demonstrates a result.
The documentation provides technical acceptance evidence, not automatic proof of legal compliance. For official information about digital accessibility and which requirements may be relevant, the client should consult Digg. The practical value of the documentation remains the same regardless: it makes responsibilities, outstanding risks, and future regression testing clearer.
The criteria that make a WCAG promise verifiable
Assess the delivery based on whether accessibility can be demonstrated through working user journeys, rather than merely summarised in a scan report. The framework below provides practical support for evaluation and technical acceptance, not legal advice; consult Digg for legal guidance.
Require manual testing of priority user journeys
The supplier must test real journeys such as navigation, forms, purchases, sign-in, or booking using a keyboard and relevant assistive technologies. Automated tools complement this work, but they cannot determine whether the focus order is logical, the content is understandable, or the task can be completed.
Indicator: The supplier shows which journeys were tested, how each step was performed, and the actual result.
Define functionality, test environment, and blocking conditions before delivery
The acceptance criteria must state what the user needs to be able to do and which agreed browsers, devices, and assistive technologies must be used. They must also distinguish blocking defects from non-conformities that may be handled through a documented decision.
Indicator: Every important journey has an observable passing result and clearly defined defect types that prevent acceptance.
Make every accessibility claim traceable
Every claim regarding WCAG 2.2 AA must be linked to a test case, an environment, an outcome, and any non-conformities. This makes it possible to distinguish verified characteristics from assumptions and general statements in a proposal.
Indicator: Be cautious if the report shows only a score, a green indicator, or a statement that no automated errors were found.
Require non-conformities to be managed and retested
An identified problem must be described with the affected function, reproduction steps, responsible party, and a decision regarding remediation or an explicit exception. After remediation, the same test case is run again so that acceptance is based on verified behaviour.
Indicator: The supplier can show both the original defect and the retest result without concealing any remaining limitations.
Start here: require verifiable delivery before approval
-
Request a written accessibility test record
Ask the web agency to document the tested version, page types, key journeys, browsers, assistive technologies, test methods, and known non-conformities in a shared document. Store the record in a platform such as Confluence or Google Drive, where the client and supplier can work from the same information.
-
Scan representative pages with multiple testing tools
Run axe DevTools and Lighthouse on the home page, navigation, forms, search, and important page templates; consider adding WAVE as well. The result should be a prioritised defect list containing the URL, component, problem type, and assessed severity—not a score used as the sole evidence for approval.
-
Conduct manual tests of critical journeys
Navigate using only a keyboard and check the focus order, focus indicator, menus, dialogs, form errors, and the ability to complete priority tasks. Add testing with NVDA and Firefox or VoiceOver and Safari, and document the observations step by step.
-
Turn every non-conformity into a verifiable delivery requirement
Record issues in Jira, Trello, or GitHub Issues with the URL, a screenshot or recording, reproduction steps, expected behaviour, owner, and status. Define an acceptance criterion for each issue so that the remediation can be retested without requiring a new interpretation.
-
Retest and sign off only when the evidence chain is complete
Rerun both automated and manual tests after remediation and document the outcome in the same record. Approve the delivery only when blocking non-conformities have been closed, remaining limitations have been explicitly accepted, and a regression testing plan is in place for future changes.
A credible accessibility audit consists of clearly scoped testing, documented findings, remediation, and verified retesting—not merely a statement in a proposal. This is practical guidance and not legal advice; use Digg for official information about accessibility requirements. An experienced partner approaches delivery by defining the scope and acceptance criteria early, then ensuring that every approval is based on a result the client can independently trace and understand.
