I don't trust accessibility projects that never end.
When you say you want to make some feature more accessible, it all sounds responsible, but it can hide a mess. Better for whom? In what way? By when? Without an answer to these questions, the work becomes a foggy pile of audits, fixes, debates and nice-to-have improvements.
You'll only end up hurting your users.
People won't benefit from you arguing for three weeks about the perfect long-term component strategy if the checkout button still has no accessible name. Good intentions do not make broken flows usable.
It's better to start with the outcome.
That's not, for example, make search better. You need a specific outcome. Maybe something like...a keyboard and screen reader user can both search, filter results and open a result using their preferred devices.
Now you can tell when the work is done. You can test it, decide what matters and then you stop.
After you know the outcome, you add a target date. Dates force tradeoffs. If you have two weeks, you may fix the broken focus order, missing labels and unclear error messages. You may not rebuild the whole design system.
Finally, say what's out of scope. Maybe you won't redesign the filters. Maybe you won't rewrite the error messages.
Scope can change as you learn more about what your users need. If testing shows that screen reader users cannot recover from form errors, something else may need to move out. The target date gives that decision weight.
Accessibility work gets better when it has edges.
Here's a simple first step to define those edges. Write this down and fill in those blanks:
By [date], [user] can [complete task] using [access method]. We are not doing [out of scope].
Tell me how it felt after you wrote a few of these.