Use WCAG 2.2 as a practical reference
The Web Content Accessibility Guidelines are organised around four principles: content should be perceivable, operable, understandable and robust. WCAG 2.2 adds criteria to improve areas such as focus visibility, dragging alternatives, target size and accessible authentication. The standard is technology-neutral and needs both automated checks and human evaluation. A site should not claim conformance simply because an automated scanner reports no errors.
Agree on the target level and scope before testing. Level AA is a common organisational target, but applicability depends on the organisation, jurisdiction and contractual requirements. Document the pages, templates, user journeys and third-party components included in the review. A conformance statement should be evidence-based and should not imply that every user need is covered.
Make every action possible with a keyboard
Many users navigate with a keyboard, switch device or other input method. Check that every interactive control can receive focus and be activated without a mouse. The tab order should follow the visual and reading order. Menus, dialogs, accordions and custom controls should expose predictable keyboard behaviour, and focus should not become trapped unexpectedly.
Visible focus is essential. Do not remove the browser outline without providing an equally clear replacement. When a dialog opens, move focus into the dialog and return it to the triggering control when it closes. Sticky headers and floating widgets should not hide the focused element. Test at normal zoom and at high zoom, not only in a wide desktop viewport.
Use semantic structure and meaningful labels
Use headings to represent the page hierarchy, not simply to achieve a particular font size. A page should normally have one clear main heading, followed by section headings in a logical order. Use lists for lists, buttons for actions and links for navigation. A clickable div often needs extra keyboard and accessibility behaviour that native controls already provide.
Every form control needs a programmatic label. Instructions, required status and error messages should be available to assistive technology. When a form fails validation, identify the field, explain how to correct it and move focus or provide a clear summary. Do not rely on colour alone to communicate success or failure.
Check contrast, text resizing and layout
Text and controls should remain legible against their backgrounds. Check contrast for normal text, large text, icons, borders and focus indicators. Do not use a pale colour as the only indicator for a selected field or disabled state. Provide useful text alternatives for informative images; decorative images should not create noise for screen readers.
Allow text to resize without clipping or losing functionality. Avoid fixed-height cards around long text and make sure buttons can expand for translated or enlarged labels. Test responsive pages at narrow widths, landscape orientation and 200% zoom. Content should reflow without requiring unnecessary horizontal scrolling for ordinary reading.
Design for touch and pointer alternatives
Small controls placed close together are difficult to use on phones and for people with motor impairments. WCAG 2.2 includes a target-size criterion with defined exceptions. In practice, provide comfortable spacing and generous hit areas for navigation, checkboxes, icon buttons and form controls. Where a drag interaction is used, provide a simple tap, click or keyboard alternative.
Make authentication usable without relying on memory puzzles or inaccessible interaction patterns. Support password managers and paste where appropriate. Provide an accessible way to complete multi-step verification and ensure users can recover from errors without losing their progress.
Test with people and assistive technology
Automated scanners can identify missing labels, some contrast problems, invalid markup and other machine-detectable issues. They cannot reliably judge whether instructions are understandable, whether focus order makes sense or whether a screen-reader user can complete an entire business workflow. Combine automated scans with keyboard-only tests, screen-reader smoke tests and usability feedback from people with different access needs.
Test complete journeys: finding a service, opening a menu, searching, submitting a form, correcting an error and completing a transaction. Include mobile screen readers and touch interaction. Record the browser, assistive technology, page, steps, expected behaviour and actual result so another tester can reproduce the issue.
Turn accessibility into a release habit
Include accessibility acceptance criteria in design reviews, development pull requests and release checklists. Add semantic and keyboard checks to component tests. Re-test shared components after a change because one inaccessible navigation or form component can affect many pages. Track issues by user impact and severity rather than treating every finding as a cosmetic defect.
GrapeCrux can support accessible design reviews, manual QA, responsive checks and remediation planning. The scope should specify the templates and journeys reviewed, assistive technologies tested and any exclusions. This creates a clear, honest record of what was checked.
Further reading
- W3C — Web Content Accessibility Guidelines 2.2 for the normative success criteria.
- W3C — Understanding WCAG 2.2 for explanations and examples.
- W3C WAI — Evaluate accessibility for testing methods and planning.
Published by GrapeCrux Editorial Team · 31 October 2026. This article is educational and should be adapted to the specific context, risk and requirements of each project.
← Back to selected articles