If your spec is incomplete because accessibility never made it into it, I bet accessibility will never make it into the product either.
That's true whether you're handing requirements to a developer, a design team or an AI agent. The spec is your blueprint. It defines what "done" looks like. And if accessibility isn't in the definition of done, it won't get built. So how do we fix that?
Here are some ideas:
- Start every user story with "any user can" instead of "user can." It's a subtle nudge that forces you to think beyond the default.
- Require that users can adjust text size up to 200% without losing content or functionality.
- Define that users with screen readers hear meaningful descriptions of all images and icons.
- Specify that users can pause, stop or hide any moving or auto-updating content.
- Require that users never lose their place or context when new content loads on the page.
- Require that all forms must be usable with a keyboard.
- Require that users can read all text clearly against its background.
- Specify that users hear exactly what went wrong when they make a mistake, not just see a red border.
- Define that users who get motion sick can use your product without triggering nausea or disorientation.
And include test criteria with assistive technologies, not just automated tools, for all these.
The real test is whether your spec makes it impossible to ship something that isn't accessible.
But here's what I'm wondering. If accessibility is in the spec and teams still skip it, is the problem really the spec at all? Or is it that we've made "meeting spec" optional?