Accessibility is a workflow question

What changed in WCAG 2.2

W3C’s introduction to WCAG 2.2 describes nine added success criteria. Examples address keyboard focus being obscured, alternatives to dragging, target size or spacing, repeated information entry and accessible authentication. The introduction dates the initial Recommendation to 5 October 2023. These changes help frame concrete interaction questions; this brief note is not a complete conformance checklist or a statement of legal compliance. Read W3C’s explanation of what is new in WCAG 2.2.

For product research, the important shift is from an abstract promise of inclusion to a named activity: creating an account, recovering access, reading a result, correcting a form or finishing a purchase.

Two kinds of evaluation, together

W3C’s guidance on involving users explains that evaluation with disabled people complements standards-based evaluation. Neither should be treated as a substitute for the other. It also cautions against generalizing the experience of a small participant group to everyone with a disability. Report the scope and the limitations of the work. Read the user-evaluation guidance.

W3C separately describes Easy Checks as a preliminary review, not a comprehensive accessibility assessment. They can expose barriers and identify where to investigate further. Passing a few basic checks does not establish that the whole product is accessible. See Easy Checks and their stated limits.

We have not conducted a user study for the product ideas discussed here. The following is an editorial planning worksheet, not reported interview evidence.

Follow one task from start to finish

Choose a meaningful task and write its start and end conditions. Include the less photogenic parts: validation errors, expired sessions, empty results, payment failures and recovery. If a task requires a document, message or external service, include that handoff in the scope instead of testing only the screen your team controls.

Record the device, browser, assistive technology where relevant, task conditions and observed barriers. Keep observation separate from interpretation. “The participant could not find the error message” is a different kind of entry from “all users will abandon this form.”

Agree the research format, consent and compensation with participants. Offer accessible ways to participate and report problems. Treat participants as people doing a job, not as a device-compatibility test. These are proposed research practices; they are not evidence that this site has already run such a program.

Turn findings into product decisions

Our suggested issue record contains the task, the barrier, the affected interaction, the proposed change and a retest plan. Avoid assigning importance solely by how easy a fix looks. A small visual change may remove a blocking obstacle; a polished animation may add no practical value.

For a startup selling accessibility-related tools, test the buyer’s workflow too. Who owns remediation? How are findings handed to designers and engineers? What evidence is needed to close an issue? A report that never reaches someone able to make a change is a weak operating proposition.

The next milestone should be a better-supported task outcome, with remaining limitations visible—not an unqualified “accessible” badge.