I keep using this word "rework," so I should probably say what I mean by it.
This is my working definition. I expect it to change as I talk to more product teams, especially in digital health. But for now, let's work through this.
Here's what I’ve seen show up in a few ways over time, in one way shape or form (pun intended).
Someone marks a ticket as done, only to later reopen it later. Why? Because the form errors didn't work for screen reader users. Everything looked fine in design, but when they tried to tab around with a keyboard, everything broke. And by they, I mean QA. Usually it's QA that finds these issues.
So now engineering has to rewrite a bunch of code because nobody agreed what "done" meant before implementation.
To be honest, product thought design owned the decision. But design thought it was the engineer's responsibility. And so it reached QA, they caught it late and now everyone loses time.
For me, that's what rework is.
Accessibility rework is work your team has to redo because an accessibility decision was missed, delayed or left unclear earlier in delivery.
It rarely happens because people are careless.
Usually, it's because someone asked the right questions too late. Other times, it's because the answer lived in someone's head instead of the way the team works. I'm guilty of this one.
We rarely label accessibility rework as "rework." We mostly think it's accessibility, it's some bug and we should fix it without digging any deeper.
Rework usually looks like reopened tickets, release risk or some frustrated engineers that need to fix stuff they thought was done. It looks like QA finding problems everyone wished they found earlier.
This is the type of work I'm trying to pay closer attention to now.
Where did we miss the decision? Who should have been involved earlier? What would have made this feature easier to ship than the last?
That's the thread I want to pull on for a while.
This definition of rework will probably get sharper over time.
For now, this'll do.