WCAG is a shared technical reference for making web content more accessible to people with disabilities. WCAG 2.2 extends WCAG 2.1 and includes additional criteria, while many organisations still have obligations or procurement requirements that name a specific version. Always confirm which version applies to your service before claiming conformance. This guide explains how to turn the principles into a practical design, development and testing routine.
The four WCAG principles
Perceivable
People need to receive information through at least one usable sensory channel. Provide appropriate text alternatives for meaningful images, captions or transcripts for relevant media, sufficient text and interface contrast, and layouts that remain usable when enlarged or reflowed. Do not communicate status through colour alone; pair colour with a label, icon or other clear cue.
Operable
Controls and navigation must work for people using different input methods. Test all actions with a keyboard, keep focus visible and in a logical order, provide clear names for controls, and ensure dialogs, menus and custom widgets can be opened and closed without a pointer. On touch interfaces, make controls easy to activate and avoid gestures that require precise or complex movement as the only option.
Understandable
Use clear labels and instructions, identify errors in text, and keep repeated navigation and controls predictable. A user should be able to understand what information is requested, how to correct a mistake and what happens after submitting a form or transaction.
Robust
Use valid, semantic HTML and expose each control's name, role, value and state to assistive technologies. Native buttons, links, headings and form controls are usually more dependable than custom elements that imitate them without complete keyboard and accessibility semantics.
Understand conformance levels
WCAG success criteria are organised at Levels A, AA and AAA. A conformance claim applies to a specified version, level, pages and complete processes; it is not a general label for a homepage or an automated scan. Many policies specify Level AA, but the required target depends on the applicable law, regulator, contract or organisational policy. Level AAA criteria are not universally required and may not be achievable for every type of content.
WCAG 2.2 also includes criteria concerning focus visibility and obscuring, dragging movements, target size (with defined exceptions), consistent help and accessible authentication. These are especially useful prompts when reviewing mobile navigation and sign-in journeys.
A repeatable website accessibility checklist
- Structure: Use a meaningful page title, one clear primary heading, logical heading levels, landmarks, lists and table headers.
- Images and media: Give informative images concise alternatives; mark decorative images as decorative; provide captions and other appropriate alternatives for media.
- Keyboard: Reach and operate every link and control, follow a sensible focus order, show focus clearly and avoid keyboard traps.
- Visual design: Check text contrast, non-text control boundaries, zoom, text spacing and reflow; do not rely on colour alone.
- Forms: Associate labels with controls, group related fields, identify required fields, announce errors and move or direct focus to useful feedback.
- Dynamic content: Announce meaningful status changes, manage focus in dialogs and ensure expanded/collapsed state is available to assistive technology.
- Mobile: Test portrait and landscape layouts, touch targets, orientation changes and common assistive-technology combinations.
How to test and report results
Start with representative templates and complete user tasks, not isolated screenshots. Use automated tools to find common defects, then manually evaluate keyboard behaviour, screen-reader announcements, magnification, text alternatives, contrast and error recovery. Include people with disabilities in usability evaluation where possible; standards checks and real task usability answer related but different questions.
Record the page or task, environment, steps, expected and actual behaviour, affected users, criterion, evidence and suggested fix. Re-test after changes and check neighbouring states so a fix does not introduce a new barrier. Keep the scope and tested version with the report. WCAG evaluation is evidence for a defined scope and point in time, not a guarantee that every future change remains accessible.
For a structured manual and assistive-technology review, explore our accessibility testing services or talk with the team.