I'd like to go back to my calendar example from two days ago.
Suppose we fix the calendar. Now keyboard users can select dates. The focus is visible. The screen reader announces each date and whether it has available appointments. Good stuff! Do we call it done?
What if the next available slot is six weeks away and patients have to check each date to find it? Can you imagine how frustrating an experience that is for a screen reader user to keep hearing "Friday, September 11, 2026. No slots available. Saturday, September 12, 2026. No slots available."
But the calendar does exactly what we specified! It's accessible!
Still, finding an appointment is harder than it needs to be, especially for people who cannot see. And I don't think it's only a user experience problem.
This is where I've seen teams get caught between two very valid definitions of finished. Engineering fixed the reported behaviour. QA verified the fix. But nobody really checked whether the task makes sense in specific, but very real, cases.
I don't expect every accessibility fix to become a redesign. Sometimes a missing label really is a missing label.
But when a fix touches an essential task, I want us to follow that task through. How much work does someone have to do? What information do they need before choosing? Can they recover if they make a mistake?
These questions belong alongside whether the component works. They help establish whether the feature delivers what patients need.
In our example, maybe this booking flow needs a "next available appointment" option. Perhaps a short list of the next available slots would serve patients better than asking them to search through a calendar.
We don't know. How do we find out? We'd need to test that with real people.
Fixing the component tells us something important about the software, but watching someone complete the task tells us whether we've helped them.