Accessibility testing should begin before the launch checklist is already full of emergencies. The most useful review combines standards, automated tools and people completing real tasks. A green score from one scanner is evidence about the rules it tested; it is not proof that every visitor can use the website.
W3C organises WCAG 2.2 around four principles: content should be perceivable, operable, understandable and robust, and recommends using the latest WCAG version. The checks below turn those broad principles into a practical pre-launch session. They do not represent a complete conformance audit.
Choose five journeys, not five convenient pages
Test the actions that matter: finding a service, understanding a price, submitting a form, completing a purchase, opening a menu or downloading an important document. Include an error path, such as submitting a required form without one field.
Write the expected outcome for each journey. This prevents the review becoming a tour of attractive pages while checkout or contact remains difficult.
Use the whole site with a keyboard
Put the mouse aside. Use Tab and Shift+Tab to move, Enter or Space to activate controls, arrow keys where the component expects them, and Escape to close a dialog or menu.
Check that focus is visible, moves in a sensible order and never becomes trapped. A visually hidden skip link should become available when focused and move directly to the main content. Menus, cookie choices, accordions, carousels and form controls need the same attention as ordinary links.
Review headings and page landmarks
Read only the page title and headings. They should describe the content in a sensible hierarchy rather than being chosen for font size. Check that the main navigation, main content and footer can be identified in the page structure.
Link text should make sense out of context. Repeated “click here” links force a visitor to inspect surrounding text to understand the destination.
Zoom and reflow the page
Increase browser zoom to 200% and inspect narrow mobile widths. Essential text and controls should remain available without overlapping or requiring a visitor to zoom back out. Watch fixed headers, consent banners, chat buttons and sticky calls to action; several individually reasonable elements can cover the same part of a small screen.
Inspect colour without relying on colour alone
Use a contrast checker for text, controls and meaningful interface states. Then inspect the page in grayscale or with a colour-vision simulation. An error should not be communicated only by changing a border from green to red; include text or another clear indicator.
Test forms carefully
- Every input has a persistent, programmatically associated label.
- Required fields are explained before submission.
- Instructions do not disappear when a person starts typing.
- Errors identify the field and explain how to correct it.
- Focus moves to an error summary or the first useful correction point.
- Success messages are available to assistive technology.
- Timeouts, CAPTCHA and file-upload requirements have usable alternatives where needed.
Test with realistic long names, international phone formats and autofill. Accessibility problems often appear when the data is less tidy than a design mock-up.
Check images, media and motion
Informative images need alternative text that serves the same purpose. Decorative images should not add noise to the reading experience. Captions or transcripts may be needed for media depending on its content.
Respect reduced-motion preferences and avoid movement that blocks reading or interaction. Give people control over carousels or media that starts automatically.
Run an automated scan, then verify manually
Automated tools are useful for finding missing labels, invalid relationships and some contrast failures across many pages. Review every result rather than treating the count as a grade. Follow with keyboard testing, zoom, screen-reader sampling and task-based review because many issues require judgement.
Record issues in a form developers can act on
For each issue, capture the page, component, steps, expected behaviour, observed behaviour, affected journey and relevant success criterion where known. Assign an owner and retest the actual fix. Avoid closing an issue because the visual appearance changed if the keyboard or assistive-technology behaviour did not.
Sources and further reading
- W3C WCAG overview — the standards source for the four principles, guidelines and testable success criteria.
- W3C Easy Checks — a practical W3C introduction to preliminary accessibility review.
For help reviewing a priority journey or addressing confirmed issues, contact Xapner about website design and development. A formal legal or conformance opinion requires appropriately scoped specialist assessment.