WCAG 2.2 Focus Appearance & Keyboard Navigation Audit Guide

1. Executive Summary & WCAG 2.2 Focus Criteria

Keyboard accessibility is the cornerstone of web inclusivity. Millions of citizens relying on screen readers, switch access devices, eye-tracking hardware, or motor-impaired keyboard navigation cannot use a pointing mouse. Under W3C WCAG 2.2 Level AA and the statutory GIGW 3.0 standards, every interactive element must be keyboard operable without keyboard traps, and its active focus indicator must be unmistakably visible.

Standard Reference

WCAG 2.2 Success Criteria 2.1.1 (Keyboard), 2.4.7 (Focus Visible), 2.4.11 (Focus Not Obscured) • GIGW 3.0 Clause 5.1

2. CSS Implementation: The :focus-visible Standard

A common anti-pattern in modern web development is removing the default browser focus outline using outline: none or outline: 0 without providing a styled replacement. This instantly breaks accessibility.

The modern solution is using :focus-visible, which only shows outlines when the user interacts via a keyboard, preserving a clean aesthetic for mouse clickers while ensuring 100% keyboard accessibility:

/* Modern Accessible Focus Indicator Pattern */ /* 1. Never strip outlines without a replacement! */ :focus:not(:focus-visible) { outline: none; /* Safe for mouse/pointer clicks */ } /* 2. High-Contrast Keyboard Focus Indicator (WCAG 2.2 AA Compliant) */ :focus-visible { outline: 2px solid #0f172a !important; /* Minimum 2px thickness */ outline-offset: 3px !important; /* Offset creates distinct visual boundary */ box-shadow: 0 0 0 4px rgba(15, 23, 42, 0.15) !important; } /* 3. Button and Navigation Focus States */ .btn:focus-visible, a:focus-visible, input:focus-visible { outline: 2px solid #0f172a !important; outline-offset: 2px !important; }

3. Eliminating Keyboard Traps in Dialogs & Drawers

Under Success Criterion 2.1.2 (No Keyboard Trap), when a modal dialog or navigation menu opens:

Focus must be immediately moved to the first interactive element inside the modal.
Tab and Shift+Tab must be trapped inside the modal while open.
Pressing the Escape key must dismiss the modal.
Upon closing, focus must be returned to the trigger button that launched the modal.

// Accessible Modal Focus Management Pattern function trapFocus(modalElement) { const focusable = modalElement.querySelectorAll('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'); const firstFocusable = focusable[0]; const lastFocusable = focusable[focusable.length - 1]; modalElement.addEventListener('keydown', function(e) { if (e.key === 'Tab') { if (e.shiftKey) { // Shift + Tab if (document.activeElement === firstFocusable) { lastFocusable.focus(); e.preventDefault(); } } else { // Tab if (document.activeElement === lastFocusable) { firstFocusable.focus(); e.preventDefault(); } } } else if (e.key === 'Escape') { closeModal(); } }); firstFocusable.focus(); }

4. Keyboard Accessibility Audit Checklist

Audit Checkpoint	WCAG Success Criterion	Verification Method
Full Operability	2.1.1 Keyboard (Level A)	Disconnect mouse. Can all forms, menus, and controls be reached and activated via Tab / Enter / Space?
No Keyboard Traps	2.1.2 No Keyboard Trap (Level A)	Navigate into all modals, widgets, and dropdowns. Can you exit using Tab or Esc without reloading?
Focus Visible	2.4.7 Focus Visible (Level AA)	Does a clear outline (minimum 2px with 3:1 contrast) appear around every focused element?
Focus Not Obscured	2.4.11 Focus Not Obscured (WCAG 2.2 AA)	Does sticky header/footer avoid completely covering focused input fields during keyboard navigation?

WebOTG Standards Directorate

Lead Accessibility Auditor

WebOTG provides benchmark reference documentation, automated matrix evaluators, and security test harnesses for government digital platforms, WQMS architectures, and STQC compliance frameworks.