Accessibility decisions belong in the design conversation

Describe a task beyond the ideal screen

Consider a hypothetical procurement application in which someone reviews an invoice, corrects a missing reference and submits it for approval. A meaningful prototype should make room for more than the successful submission. Ask how the person finds the missing information, understands the correction and knows whether the request was accepted.

Walk through that task using a keyboard, a narrow viewport and enlarged text. For each moment, distinguish what the prototype actually demonstrates from what is only an annotation. A clickable design canvas can communicate intent, but it should not be treated as proof of the implemented product's accessibility.

WCAG 2.2 includes testable requirements for keyboard operation and identifying input errors. Its conformance requirements also address complete pages and complete processes. ^[1] Use the relevant criteria to shape acceptance conditions for the whole task, then verify those conditions in the working interface.

Make the invisible decisions visible

A useful interaction specification records the decisions that a still image cannot carry. Explain the reading order, the purpose of each control, the expected keyboard action and the feedback after a change. Show the loading, empty, error and success states alongside the ordinary screen. Give destructive actions and unfinished work an explicit recovery discussion.

WCAG 2.2's Focus Not Obscured (Minimum) criterion requires a component receiving keyboard focus not to be entirely hidden by author-created content. ^[2] That has direct design implications for sticky headers, bottom action bars and overlapping panels. Review those combinations while the layout is flexible, including the moment when a person tabs to a control near the edge of the visible area.

• Write what a control does using language that still makes sense without its icon.
• Specify where attention should move after opening, completing or dismissing a task.
• Show how an error explains the problem and points to a useful correction.
• Record which movement is optional and how the task works with reduced motion.

Use the minimum as a boundary for judgement

Target size is a good example of why standards need careful interpretation. WCAG 2.2's AA criterion generally specifies a target of at least 24 by 24 CSS pixels, with defined exceptions, including sufficient spacing between undersized targets. W3C also notes that larger targets can improve usability and points to a stricter enhanced criterion. ^[3]

Treat those conditions as something to evaluate in context. A frequently used approval action, an infrequent inline link and a dense data toolbar have different purposes. Make the target's actual clickable area clear in the specification, rather than measuring the visible icon alone. For a touch-focused workflow, favour a comfortable interaction where the layout allows it. Record any tradeoff so it can be revisited with evidence.

Test a question that the design can still change

Early research is most useful when it can influence a consequential decision. Instead of presenting a finished flow for general approval, choose a question: can someone understand which invoice needs attention, recover from a validation error or return to their previous place after reviewing a detail? Include people whose access needs are relevant to that question.

W3C recommends involving people with disabilities throughout a project and combining that participation with standards-based evaluation. ^[5] A successful session with one person is useful evidence about that person's task, not a universal result. Keep the observations specific, retain the unresolved questions and turn the findings into changes that can be checked in the next version.

Hand over decisions that can be verified

Keep accessibility requirements beside the component or journey they describe. Pair an interaction example with its acceptance conditions, known limits and the person responsible for resolving an open question. A shared design system is a useful place for recurring behaviour, while unusual workflows need their own notes.

The handoff should make the next review concrete. Identify what engineering must implement, what content needs clarification and which behaviours require testing in the actual browser and assistive technology combinations chosen for the project. That gives design, development and evaluation a shared object to work on, and makes later changes easier to assess.