Practical approaches for effective accessibility

1 minute read

If I've convinced you to make accessibility a part of your acceptance criteria so it stops competing with features, you're likely wondering how to do just that.

Here are some ideas:

  • If it's not testable, it's not done.
  • Write it in the ticket, not the retrospective.
  • Ask "who can't use this?" first.
  • Define done with users with disabilities in mind.
  • Make the accessibility check part of sign-off, not part of v2.
  • Know your WCAG level. Pick one. Hold the line.
  • Don't accept a design that hasn't been reviewed for contrast.
  • Treat an inaccessible release like a broken build. Don't ship it.
  • Budget for remediation because you likely have issues already.
  • Invite someone with a disability to help you test.
  • When it's flagged late, fix it anyway.
  • Know the difference between "technically compliant" and "actually usable."
  • Stop closing tickets as "won't fix" without a documented reason. Make it a good reason.
  • Ask your engineers if they've tested with a keyboard.
  • Don't let "we'll come back to it" become "we never did."
  • Own the backlog. Own what's in it. Own what keeps getting pushed.

Done means done. Inaccessible ain't done.

Sent on

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.