WCAG 2.2 Checklist for UK Web Developers: Patterns and Testing

Discover practical WCAG 2.2 guidance tailored for UK developers. Learn patterns mapped to common React/Next workflows and a lightweight audit you can practise in live classes.

WCAG 2.2 for UK developers: patterns, workflow, and quick wins

This guide offers a practical WCAG 2.2 checklist for UK web developers, mapped to everyday React and Next.js workflows. Instead of rehashing the entire specification, we focus on what changed in 2.2, where teams typically slip in modern front‑ends, and how to integrate checks into your sprint without slowing delivery.

You will learn concrete patterns for navigation, forms, authentication, touch targets, and dynamic UI updates—plus a lightweight testing flow you can repeat across projects. We reference UK expectations so you can work confidently toward a WCAG 2.2 AA baseline often requested in contracts and accessibility statements.

By the end, you will know which components to fix first, how to prove improvements with quick tests, and how to avoid common traps like hidden focus, drag‑only interactions, and login flows that exclude users.

Practical WCAG 2.2 checklist for UK web developers

Use this section to translate the spec into decisions you can ship. It is written for component libraries, React/Next stacks, and design‑system teams working to a WCAG 2.2 AA target commonly expected across the UK.

Key point: Treat accessibility as a shared responsibility—design defines patterns, engineering implements them accessibly, and QA verifies with keyboard, screen reader, and automated checks. Aim for WCAG 2.2 AA; use AAA items as stretch goals when risk or audience warrants it.

What changed in 2.2: the AA and A criteria that matter in the UK

AA highlights to prioritise

  • 2.4.11 Focus Not Obscured (Minimum): Keyboard focus must not be hidden by sticky headers, drawers, or banners.
  • 2.5.7 Dragging Movements: Provide an alternative to drag (e.g., click, buttons, or keyboard) for actions like reordering or sliders.
  • 2.5.8 Target Size (Minimum): Interactive controls should have a minimum effective target of about 24 by 24 CSS pixels or sufficient spacing.
  • 3.3.8 Accessible Authentication (Minimum): No memory or puzzle‑style tests to sign in; allow paste and password managers.

A‑level additions that reduce friction

  • 3.2.6 Consistent Help: If a help option exists (contact, chat, docs), surface it consistently in the same relative location.
  • 3.3.7 Redundant Entry: Do not ask users to re‑enter information you already have; prefill and reuse data where possible.

Good to know: AAA items like 2.4.13 Focus Appearance and 2.4.12 Focus Not Obscured (Enhanced) raise the bar further—great for high‑risk or public‑facing services.

React/Next implementation patterns that satisfy 2.2

Navigation and focus management

Implement

  • Add a skip link to the main content. Ensure it becomes visible on focus and lands in the main landmark.
  • After route changes, move focus to the page heading or main region so screen reader users do not start mid‑page.
  • Prevent sticky headers, cookie banners, or drawers from covering the focused element.
  • Use an accessible dialog for modals (trap focus, restore it to the trigger on close).
  • Provide visible focus states with sufficient contrast against backgrounds.

How to test

  • Keyboard only: Tab through the page, including into/around menus and modals. Nothing should trap focus or vanish behind overlays.
  • Trigger a route change and confirm focus lands predictably on the new view’s main heading.
  • Zoom to 200% and repeat the sweep; focus should still be visible and unobscured.

Forms and authentication

Implement

  • Use native inputs with visible labels; associate errors with aria-describedby and unique ids.
  • Allow copy‑paste into password/OTP fields and support password managers via suitable autocomplete tokens.
  • Avoid cognitive challenges to log in or reset; offer email link or passkey options where feasible.
  • Group related fields with clear hints and examples; announce errors inline and in summaries.

How to test

  • Attempt to paste into password and OTP fields; ensure no blocking scripts.
  • Run a screen reader: confirm labels and error messages are announced after the field name.
  • Trigger validation: errors should appear near fields and be reachable by keyboard.

Pointer, drag, and target size

Implement

  • For drag components (kanban, sliders), add clickable buttons or keyboard actions to perform the same task.
  • Ensure targets are large enough or have sufficient spacing; wrap icons with a larger interactive area and an accessible name.
  • Make pagination dots, close icons, and tiny toggles finger‑friendly.

How to test

  • Use trackpad or touch simulation; confirm actions are possible without dragging.
  • Try with one hand on a small screen; you should not need pixel‑perfect taps.
  • Keyboard check: arrow keys or buttons can perform the same actions as drag.

Status messages and dynamic updates

Implement

  • Announce async results with a polite live region or role=”status”; avoid double announcements.
  • Use progress indicators for long tasks and keep focus stable while content updates.
  • For timeouts, warn users and allow an easy extension.

How to test

  • Trigger success/error toasts and verify they are announced once.
  • Simulate slow network and confirm progress is conveyed accessibly.
  • If a session can expire, check that extending time is keyboard and screen reader friendly.

Help and redundant entry

Implement

  • Keep help/chat/contact in the same location across pages; ensure the control is reachable and labelled.
  • Prefill known data and offer checkboxes to reuse addresses or details; respect user privacy and consent.

How to test

  • Move between key pages: help options should appear consistently.
  • Repeat a common flow (e.g., checkout) and confirm you are not asked to retype known information.

Lightweight 30‑minute accessibility audit workflow

  • Keyboard‑only sweep (5 min): Tab through primary journeys; check skip link, menus, dialogs, and focus visibility.
  • Focus not obscured (5 min): With headers/banners active, ensure the focused element remains fully visible on all key screens.
  • Forms and auth (7 min): Labels, errors, and help text read correctly; paste and password managers work; no puzzle‑style challenges.
  • Targets and gestures (5 min): Tiny controls are easy to hit; any drag‑only UI has a tap/click/keyboard alternative.
  • Screen reader smoke test (5 min): Try NVDA or VoiceOver on a core flow; confirm headings, landmarks, and announcements make sense.
  • Automated pass (3 min): Run Axe or Lighthouse to catch colour contrast, names/roles, and obvious markup issues. Use results to create tickets.

Rotate devices and contexts: desktop with zoom, mobile touch, and high‑contrast/forced colours modes. For UK public‑facing services, align with internal accessibility statements and procurement requirements that typically reference WCAG 2.2 AA.

Quick wins you can ship this week

  • Add a visible skip link and main landmark to every page template.
  • Move focus to the main heading after route changes in your router/layout.
  • Replace any drag‑only action with buttons and keyboard shortcuts.
  • Allow paste and autocomplete on login, registration, and reset flows.
  • Wrap icon buttons with a larger target and give them clear accessible names.
  • Add a role=”status” region for toast messages and API results.
  • Standardise help/contact entry points in your header or footer.

Examples: mapping criteria to real components

WCAG 2.2 itemComponent to reviewActionable fix
2.4.11 Focus Not ObscuredSticky header + anchored contentEnsure focused elements are not covered by overlays; adjust layout so focused links and form fields remain fully visible.
2.5.7 Dragging MovementsKanban board or sortable listAdd Move up/down/left/right buttons and keyboard support; provide click/tap targets for reordering.
3.3.8 Accessible AuthenticationLogin/Reset screensPermit paste and password managers; offer alternatives like email links or passkeys where suitable.

Common mistakes to avoid

  • Relying only on automated tools—many 2.2 issues are behavioural, not just semantic.
  • Replacing semantic buttons/links with divs and custom handlers.
  • Hiding focus outlines without providing an accessible alternative.
  • Icon‑only controls without an accessible name or description.
  • Off‑canvas menus that trap keyboard focus or return it to the top of the page on close.

Practise the workflow on real projects

Best for: Teams who want hands‑on patterns and repeatable checks.
Format: Live virtual practice focused on React/Next components.
Support style: One‑to‑one guidance available for tricky UI states.

Run the 30‑minute audit on your codebase, refine component patterns, and leave with a prioritised fix list you can track in your backlog.

Final advice

Lock in a WCAG 2.2 AA baseline by baking patterns into your design system and making the 30‑minute audit part of every release. Start with focus visibility, form/auth flows, target sizes, and drag alternatives—these deliver the biggest wins for UK users and regulators. Iterate, test in the open, and keep accessibility visible in your pull requests and sprint reviews.

Next Step • Learn with Codionix

Turn what you just learned into a real IT career move

Whether you want to build job-ready skills, follow a structured career path, or get expert advice before choosing a course, Codionix IT Training UK can help you move forward with confidence.

01

Explore IT Courses

Browse instructor-led training across cloud, cybersecurity, networking, data, support, digital skills, and more.

View Courses
02

View Career Paths

See structured pathways designed to help you progress toward roles like helpdesk technician, network engineer, ethical hacker, and beyond.

Explore Career Paths
03

Book Free Consultation

Not sure which course or path fits you best? Speak with the team and get clear, practical guidance before you commit.

Get Free Advice

Related articles

Contact us

Free IT Training Consultation

Use the calendar to book your free one-to-one course advice session with a Codionix IT training expert. Get personalized career guidance to help you choose the best online IT course in the UK for your goals. We’re happy to answer any questions you may have and help you determine which of our training programs best fit your needs.

How it works?
1

You schedule a call at your convenience 

2

We do a free discovery and consulting meeting 

3

We guide you towards the best career path for you

Your benefits:
Find us on:
Schedule a Free Consultation

Not sure which IT course is right for you? Book a free consultation and get expert guidance from our team — no cost, no pressure.