Accessible design / 4 min read
Accessible interaction design: make every click and keypress count.
A researched guide to target size, keyboard access, and visible focus—with practical checks for your next website.
Start with the action someone needs to complete
Imagine a visitor trying to book a studio consultation. They can read the page, but a small calendar arrow is difficult to select and the booking action becomes unclear when they put the mouse aside. The visual direction may be strong, yet the interaction still gets in the way. Start your review with a complete task: find a date, choose a time, and confirm the request. Identify every control involved, including the quiet ones. Small interaction decisions shape whether the task remains manageable from start to finish.
Give pointer targets enough room
WCAG 2.2 success criterion 2.5.8, at Level AA, sets a 24 by 24 CSS pixel minimum for pointer targets, subject to exceptions. Those cover sufficient spacing, an equivalent control on the same page, inline text, unmodified browser controls, and essential presentation. For the spacing exception, a 24 CSS pixel diameter circle centred on an undersized target’s bounding box must not intersect another target or another undersized target’s circle. Measure the clickable area, not just the drawn icon. For important controls, consider more generous dimensions: the separate Level AAA enhanced criterion uses 44 by 44 CSS pixels, also with exceptions. Avoid presenting either number as a universal rule for every link.
W3C: Target Size (Minimum), AA ↗W3C: Target Size (Enhanced), AAA ↗Make the task work through a keyboard
Keyboard access is a separate requirement from target size. WCAG 2.1.1, at Level A, requires functionality to work through a keyboard interface without demanding specific timings between keystrokes; its exception concerns functions inherently dependent on a movement path. For an ordinary booking journey, keyboard operation should reach the same outcome as pointer operation. Try selecting the date and submitting the request without a mouse. W3C’s button pattern specifies Enter and Space for activating a focused button. Give that button a name that explains the action, such as “Request consultation”, and check the behaviour as well as the appearance.
W3C: Keyboard, A ↗W3C: Button Pattern ↗Design a visible focus state
A keyboard user needs to see which control will respond next. WCAG 2.4.7, at Level AA, requires a mode with a visible keyboard focus indicator. Treat that state as part of the component design alongside hover, pressed, and disabled states. A clear outline is one possible treatment; the precise choice should work across the backgrounds where the component appears. Do not remove the browser outline without providing a visible replacement. Check the actual page rather than a single component mock-up: a ring that stands out against a pale panel may become difficult to see against a photograph or dark section.
W3C: Focus Visible, AA ↗Keep the focused control in view
Sticky headers, floating notices, and bottom banners can cover the control a person reaches by keyboard. WCAG 2.4.11, at Level AA, addresses this by requiring that author-created content does not entirely hide the component receiving focus. Partial visibility can meet this criterion, but keeping the whole control visible is a better design goal. In the consultation example, move through the calendar with the site header and any notices present. Check whether the active date and booking action remain visible. Adjust spacing, scrolling, or overlay behaviour where needed; an attractive floating layer should not conceal the next step.
W3C: Focus Not Obscured (Minimum), AA ↗Run a focused interaction review
Before publishing, take the consultation task through three passes. First, inspect the clickable areas and spacing at a narrow viewport. Second, complete the journey with the keyboard and follow the focus indicator throughout. Third, repeat with any menus or floating panels open where the workflow allows it. Record the control, the problem, and the change needed, then verify the repaired journey. These checks cover selected interaction issues, rather than establishing full WCAG conformance. They do, however, turn abstract accessibility requirements into concrete design decisions that a designer and developer can review together.