Storecode [SYSTEM]
← Back to logs
DESIGN2019-07-22BY MARA SABOGAL

Checklist: Accessibility for critical flows

A small checklist we run on the flows that matter: sign-in, checkout, account changes. Accessibility is reliability for humans.

designaccessibilityuxreliability

Accessibility work is often treated like polish.

In practice it’s incident prevention: it reduces confusion, retries, and support load—especially in the places where users are already stressed.

Context

We don’t try to “audit the whole product” in one pass.

We pick the critical flows (sign-in, checkout, account recovery, billing changes) and make those boring and dependable.

We also treat accessibility as reliability for humans: if the flow fails for a keyboard-only user, it fails under stress for everyone.

Checklist

  • Keyboard path works end-to-end

    • tab order is logical
    • focus is visible
    • no keyboard traps
    • the “primary action” is reachable without hunting

  • Forms are labeled and errors are specific

    • every input has a label
    • errors say what happened and what to do next
    • errors are announced (not only color)
    • error summary exists for long forms (and focus moves to it)

  • Loading and success states are legible

    • the user can tell if something is still working
    • buttons don’t silently do nothing
    • double-submits are prevented without hiding feedback
    • spinners are paired with text (“Saving…”) when possible

  • Contrast and hit targets are usable

    • text is readable
    • controls aren’t tiny
    • disabled states are distinguishable without relying on color alone

  • Status changes are announced

    • confirmation messages are reachable by screen readers
    • focus moves intentionally after an error
    • inline validation doesn’t steal focus unexpectedly

  • Failure is recoverable

    • a timeout or validation error doesn’t force a full restart
    • the next step is clear
    • users can retry without losing everything they entered

  • Time and motion are handled

    • timeouts warn and allow extension (especially in checkout / billing)
    • animations respect “reduced motion” preferences

Notes

We run this checklist with real constraints:

  • only keyboard
  • zoomed UI
  • one small screen

We also do a “slow and tired” pass:

  • throttled network
  • a screen reader (at least once)
  • sound off
  • one hand on the trackpad, not two hands on the keyboard

If the flow is confusing under those conditions, it will be confusing for tired humans in the real world.

Takeaways

Accessibility isn’t a separate project. It’s part of making the system usable under stress.

A good error message is accessibility work.

A good runbook is accessibility work for the people operating the system.

Further reading