At some point before a release, someone will ask whether what we built is "good enough."
I was never sure what to say. Yes? Maybe?
But I realised why I had problems giving an answer. I didn't know what "good enough" meant. To me, it's relative. Good enough needs a qualifier. Good enough for whom to do what in which circumstances?
"Good enough" gets surprisingly flexible when the deadline is tomorrow. The broken keyboard interaction becomes an edge case. Testing with a screen reader becomes follow-up work. Someone points out that QA hasn't complained. We've already talked about how little that last one tells us.
So I think we have a scale, from something like "this sucks" to "okay" to "good enough" to "done." That’s why it's called the definition of done, not the definition of good enough. If something is done, it's good enough, but not the other way around.
And we don't need to have this conversation at the end before the release. I'd rather we agreed on what "done" means before we build it.
A definition of done gives us the expectations we can build and plan around. Accessibility needs to be part of those expectations, with specific checks for the feature where necessary. Things we can reliably test. "We considered accessibility" tells us nothing.
Agreeing on this early makes the required work visible before anyone commits to a release date. It also gives everyone grounds to raise a problem without having to argue that accessibility matters every time.
We won't make every release perfect, testing has its limits after all and we'll always discover problems later. But a known problem that prevents someone completing the core task means that part of the work isn't "good enough."
Let's not call it good enough any more. That doesn't mean done. Changing the meaning of done won't make the buttons work.