I had to edit some of these questions for clarity and typos, but I've kept the essence throughout.
How do I define "done" for accessibility when accessibility never really ends?
Define done for the project, not for accessibility forever. "Keyboard users can complete checkout" is done. "Make checkout more accessible" is not.
Who should own accessibility project: PM, designer, engineer, accessibility specialist?
Maybe the wrong question because accessibility isn't a project. People should each own the decisions they have the know-how to make. I usually base this on role and handoff moments. The accessibility specialist can guide the work, but they shouldn't be the one responsible for every task.
What if no one has authority to make scope tradeoffs?
Then your first task is naming the decision-maker. You can nominate yourself.
How do we decide what is out of scope without ignoring users with disabilities?
Start with the user journey you promised to fix. Any work outside that journey can still matter, but if it doesn't block the current outcome, track it somewhere visible and give it a review date.
What belongs in weekly meeting vs async updates?
Use async for status, links, notes and ticket updates. Use the meeting for demos, decisions, blockers, tradeoffs and feedback that needs people in the same room.
How do we demo screen reader work to people who don't use screen readers?
Show the same task before and after. Share your screen, let them hear the broken output, then the fixed output. Then explain what the user can now understand or do.
How small should "small shippable chunks" be?
Small enough that someone can review, test and understand the change without opening ten tabs. One flow, one component state, one focus bug or one screen reader announcement is often enough. Start embarrassingly small.
What if leadership wants WCAG compliance by date?
Translate that into product outcomes and risk. "WCAG compliance by June" is vague. Push for more concrete like maybe "top five purchase flows meet agreed WCAG criteria by June." This gives you something you can plan, test and prove.
How do we create accountability without blaming one person?
Name one owner for coordination, then name owners for decisions, design, engineering, QA and content. Accountability should make responsibilities clear, not make one person absorb every failure.
What if the accessibility lead becomes bottleneck?
Move repeatable decisions out of their head. Create checklists, examples, component guidance and review rules so teams can solve common issues without waiting for one person.
What if team says "accessibility is everyone's responsibility" to avoid ownership?
Say, "Great. Who owns this outcome?" Shared responsibility still needs named owners, dates and decisions. Without these, it becomes a polite way to do nothing.
Thank you everyone who sent in these questions!