01
Design for people, not an abstract compliance score
People may browse with a screen reader, keyboard, voice control, magnification, captions or personalised colours and text sizes. Others may have limited dexterity, cognition, hearing or vision. The same design choices can also help someone with a broken arm, bright sunlight or a noisy environment.
WCAG 2.2 organises guidance under four principles: perceivable, operable, understandable and robust. Level AA is a common project target, but legal obligations and procurement requirements depend on the organisation and context. Do not claim conformance without checking complete pages, states and processes against the stated version and level.
02
Make content and page structure understandable
Use descriptive page titles, one logical heading hierarchy, meaningful link text and plain language suited to the audience. Provide text alternatives for informative images and captions or transcripts for relevant media. Decorative images should not create repeated noise for assistive technology.
Use semantic HTML for landmarks, lists, tables and controls before adding ARIA. Visual position alone does not establish reading order. A common mistake is making a clickable card from a generic container without a useful accessible name or keyboard behaviour.
- Keep heading levels logical
- Name links by destination or action
- Describe informative images in context
- Use native elements for native behaviour
03
Support keyboard, focus, zoom and form recovery
Every interactive element should be reachable and usable from a keyboard in a sensible order, with a visible focus indicator. Avoid keyboard traps and hover-only information. Layout and content should remain usable when text is enlarged or the viewport is narrow.
Give form controls persistent labels, instructions and errors connected programmatically to the relevant field. Preserve entered values when validation fails and explain how to correct the issue. Colour can reinforce meaning but should not be the only way an error, status or selection is communicated.
04
Combine automated, manual and user-centred testing
Automated tools can find missing names, some contrast failures and structural errors, but cannot judge whether alternative text is useful or a journey makes sense. Test keyboard navigation, focus order, zoom, reflow, reduced motion, form errors and representative screen-reader output.
Accessibility continues after launch. Content editors can break headings, links and alternative text; new widgets can introduce traps or unclear controls. Include accessibility checks in acceptance criteria, staff guidance and release reviews. An overlay cannot reliably repair the underlying design and code.
Practical next steps
Checklist
- 01Define the target WCAG version and level
- 02Use semantic landmarks and logical headings
- 03Provide useful text alternatives and captions
- 04Test every journey with a keyboard
- 05Keep focus visible and order predictable
- 06Associate labels, instructions and errors with fields
- 07Test zoom, reflow, contrast and reduced motion
- 08Combine automated checks with manual review
- 09Assign accessibility ownership after launch
Common questions
Questions and answers
Is accessibility only for blind people?
No. It supports varied visual, hearing, motor, cognitive and speech needs and often improves usability for people in temporary or situational constraints.
Does passing an automated scan make a website accessible?
No. Automated checks cover only part of the requirements and cannot judge many content, interaction and journey problems.
What is WCAG 2.2 AA?
WCAG 2.2 is a W3C Recommendation. AA conformance means a complete page satisfies all applicable Level A and AA success criteria, subject to the specification’s conformance requirements.
Can an accessibility overlay make an old site compliant?
An overlay may alter some presentation, but it cannot reliably correct every content, structure, keyboard, form and third-party problem. Fix the underlying experience.
Need a considered recommendation?
Discuss the website, not just the symptom.
AHANIX reviews each requirement manually. Technical recommendations may depend on access to the website, hosting or DNS configuration.
Continue learning