I'll try to pick some questions I can answer for everyone's benefit, starting with this one:
Is a target date risky if we don't know full scope yet?
Yes, a target date is risky when you pretend it means certainty.
Accessibility work, much like any other work, often starts with unknowns. You may not know how many keyboard traps exist or whether the design system or one product flow causes most of the pain. You won't know how much screen reader testing will reveal.
But that's no reason to avoid dates altogether!
It is a reason to use dates correctly.
Here's how I think about dates.
A date should force useful questions:
- What can we fix by then?
- Which user journey matters most?
- What can wait?
- What do we need to learn so we can make better decisions?
Without a date, every issue will start to feel equally urgent. That's obviously wrong. But nevertheless, you won't be able to say no to any of it. And the work will expand until nobody knows what done means anymore. You'll ship something, you'll make some people happy because their thing made it in and lots of people unhappy because theirs didn't.
With a date, you have to get honest about scope and you can be straight forward with requests.
When you say by October 15, keyboard users can complete checkout, if testing shows the work is bigger than you expected, you're free to either adjust scope or adjust the date. You can't shove more stuff in without either taking stuff out or changing the date. I'm in favour of almost always keeping the date and making the tradeoff visible.
My idea of a date is not some fantasy deadline you pull out of thin air.
Yes, you give it some thought, but ultimately, it's a tool for deciding what your users get first, not what they get period.