The useful takeaway
Define accessible task completion at the start, then combine automated checks with human testing.
Accessibility is easier to deliver when the project brief names the tasks people must be able to complete and the conditions under which they use the site. Adding an automated scan at the end cannot settle decisions about navigation, content order, error recovery, or understandable instructions.
Start with the core journeys: discovering the right service, comparing options, requesting help, or accessing an account. Include keyboard use, assistive technology, zoom, touch, and smaller displays in the acceptance criteria. These conditions often reveal weaknesses that also affect people using the website under time pressure or with an unreliable connection.
Use a standard as a working reference
W3C's WCAG 2.2 reference organizes technical criteria for accessible content and interactions. For example, the minimum-contrast criterion generally requires a 4.5:1 ratio for ordinary text and 3:1 for qualifying large text, with defined exceptions. W3C research Apply the relevant criteria in context rather than treating one number or a software badge as proof of overall conformance.
Document the target, the testing scope, and who will resolve findings. A public marketing page, an authenticated portal, and a transaction flow have different interaction requirements. Include downloadable documents and third-party services in the review where they form part of the customer journey.
VanKpa practical review
Check the task through different inputs
| Review | What to examine |
|---|---|
| Keyboard | Reachable controls, visible focus, and a sensible order |
| Zoom and small screens | Readable content and controls without lost information |
| Forms | Persistent labels, understandable errors, and recovery |
| Images and structure | Purposeful alternatives and a meaningful heading hierarchy |
Clear content and navigation
Use headings to communicate structure, not simply to achieve a visual size. Give links names that explain their destination, and ensure that information does not depend on color alone. Choose alternative text based on the purpose of an image in context; decorative artwork may need an empty alternative rather than a lengthy description.
Test the navigation with a keyboard. Focus should be visible, move in a sensible order, and return appropriately after a dialog closes. A menu should not trap someone without a way out. Check that sticky headers and floating controls do not obscure the content or action currently in focus.
Treat form recovery as a core requirement
Keep labels visible after a person starts typing. Nielsen Norman Group's research explains why placeholder-only labels create memory and error-correction problems. Nielsen Norman Group research Add instructions where they are needed, identify errors clearly, and preserve valid entries when submission fails.
The confirmation state deserves the same care as the input fields. Explain whether the request succeeded and what happens next. If the connection fails, provide a useful recovery path. A silent failure or an ambiguous spinner can leave someone uncertain whether repeating an action will create a duplicate request.
Test the full experience
Our recommended process combines automated checks, keyboard review, representative assistive-technology testing, and task observation. Automated tools can identify some defects quickly, but interpretation and interaction testing remain necessary. Track findings by severity and customer consequence, then retest the affected journey after correction.
Accessibility also needs content ownership. A future editor can introduce an unclear heading, an uncaptioned video, or a low-contrast banner even when the original design was sound. Provide simple publishing guidance and include review in the maintenance process so the site remains usable as it evolves.
- Define the journeys and accessibility target in the brief.
- Check headings, link purpose, and media alternatives.
- Test visible focus, menus, dialogs, and keyboard completion.
- Review form instructions, errors, and successful submission.
- Record the limits of the audit and unresolved findings.
Is a checklist enough?
No. Technical evaluation and legal obligations are different questions. Describe the actual testing performed and its results accurately. Where a legal determination is needed, the business should obtain advice relevant to its situation rather than relying on a website score.
Evidence behind the guidance
Sources & context
Published research informs this article. VanKpa's frameworks and recommendations are practical applications; illustrative data is labeled where used.
- W3C — How to Meet WCAG 2.2 ↗Accessed September 11, 2026
Technical accessibility reference. A checklist or automated scan alone does not establish conformance.
- Nielsen Norman Group — Placeholders in Form Fields Are Harmful ↗Reviewed September 10, 2018
Usability guidance on visible labels and persistent instructions.
What could this change?
Bring the question, the current workflow, and the result you want to improve. We can help define a useful next step.




