Accessibility is often discovered too late because teams describe it as a review activity rather than a property of the product. A release reaches QA, someone tabs through it, a control is hard to reach or a dialog hides focus, and the work becomes a list of visual adjustments.
That framing misses the real decision. If a customer cannot find, operate, or recover from an important path with the way they use the product, the product has not delivered the promised outcome. Accessibility belongs beside correctness, security, and response time in the definition of done—not after the interface is otherwise “finished.”
The useful move is small: make the interaction contract explicit before implementation. It gives product, design, engineering, and quality the same thing to build and verify.
Describe the complete action, not the happy-path screen
Start with the job a person needs to complete and the conditions that make it complete. “Add a payment method” is a feature label. “An account owner can add, correct, and confirm a payment method without relying on a pointer, losing their place, or exposing a confusing error” is a product requirement.
That second statement immediately creates better questions:
- How does someone reach the action?
- What tells them where they are and what will happen next?
- Can they complete the task with keyboard, touch, pointer, or assistive technology?
- If validation fails, can they understand the problem, correct it, and keep their work?
- What state must still be true afterwards—correct data, the right permission, and a clear confirmation?
This is not a separate “accessible version” of the workflow. It is the workflow. The WCAG 2.2 standard is designed to make web content more usable across a wide range of disabilities; its criteria are useful constraints for the ordinary product questions above, not decoration added at the end.
Put observable interaction rules in the acceptance criteria
Avoid acceptance criteria such as “make it accessible.” They assign intent without giving the delivery team a shared test. Write the visible, observable condition instead.
For a filter drawer, a compact contract might say:
- opening it moves focus to a meaningful starting point;
- keyboard focus remains visible and is never hidden behind the sticky header or the drawer itself;
- every control has a programmatic name, a visible label where the context needs one, and a usable touch target;
- applying, clearing, and closing the drawer are available without dragging or a precise pointer action; and
- an error identifies the field that needs attention without erasing already entered values.
Those statements can be discussed in a product review, represented in a design prototype, implemented in code, and exercised in an automated or manual check. They also expose trade-offs early. A floating action bar might be beautiful until it covers the field a keyboard user has reached. A compact toolbar might save space until adjacent controls become too easy to activate by mistake.
The WCAG 2.2 guidance for Target Size (Minimum) sets an AA baseline of 24 by 24 CSS pixels for pointer targets, with specific exceptions. That is a useful lower boundary, not a substitute for product judgement. Important actions, destructive choices, and repeated mobile use often deserve more space than the minimum.
Treat focus as product feedback
Focus is how many people know where an interaction will occur next. Removing the browser’s outline without replacing it with an equally clear signal makes the interface less legible even when every feature technically works.
Design the focus state with the same care as hover, loading, error, and success. It should be visible against the component and its surroundings, survive theme changes, and remain on screen when overlays, sticky navigation, and validation messages appear. The WCAG 2.2 Focus Not Obscured (Minimum) criterion requires that a focused component is not entirely hidden by author-created content. It turns a common late-stage surprise into a condition the team can test deliberately.
Do not treat this as keyboard-only polish. A reliable focus position helps a support teammate reproduce a report, makes validation behavior predictable, and forces the team to decide which control has responsibility after a state changes. Those are product-quality questions.
Test the composition, not isolated components
A button can pass its component test and still fail in the page where people use it. Accessibility problems often appear at the seams: a dialog opens from an overflow menu, a responsive layout reorders content, a notification appears while an async task is running, or an error summary competes with a fixed footer.
Add a short end-to-end pass for each important journey:
- Use only the keyboard from entry to completion, including opening and closing overlays.
- Check focused controls at the narrowest supported viewport and at browser zoom.
- Try the error and retry path with realistic data rather than a pristine happy path.
- Confirm that target size and spacing remain usable on touch devices.
- Verify the confirmation is understandable without depending on colour, animation, or a transient toast alone.
Automation is valuable here: it can catch missing names, broken heading structure, contrast regressions, and focus traps consistently. But it cannot infer whether the words make sense, whether the tab order matches the task, or whether a recovery path preserves a person’s intent. Use automated checks to protect known rules, then reserve a small human review for the journey and the decision it supports.
Give accessibility an owner before the release meeting
The strongest teams do not create a last-minute accessibility gate that one person must approve. They assign the work across the delivery system:
- Product names the user outcome and unacceptable failure.
- Design specifies the states, hierarchy, spacing, and behaviour.
- Engineering implements semantic structure and resilient interaction.
- Quality verifies the end-to-end contract in the environments people actually use.
Record the result with the release evidence: which journeys were checked, which states are intentionally supported, and which known limitations require a follow-up. If a limitation changes who can complete a core task, it is a release decision—not a backlog footnote.
Accessible interaction is not a compliance layer wrapped around a finished product. It is evidence that the team has defined a complete experience, made its trade-offs visible, and verified the outcome for more of the people who need it.
If your next product needs strategy, design, engineering, and quality to make those decisions together, bring BugSquad the challenge.