I'm so dang tired of accessibility being treated like just a moral imperative.
Everyone agrees it matters. Everyone says they care. Everyone nods when someone says that it's everyone's responsibility.
And then the work drifts. Spreadsheets are born. They feed an ever-growing backlog. The design team waits for product direction. Product waits for engineering estimates. Engineering waits for priorities. Support has user complaints. And everyone waits for somebody else to come in and do some awareness training.
The last thing accessibility needs is another awareness campaign.
Here's a novel idea. Get someone to run the project.
This sounds so small and the simplicity of it bothers people. Accessibility is bigger than a project. You know, it touches design, engineering, content, QA, procurement, support and leadership. It affects every release. It should be part of how the organisation works.
Yes.
But right now, your product can't be used with a keyboard. Screen readers say "button, button, button" on a page that makes sense visually.
What are you doing about these?
These problems don't get fixed because everyone cares. We need someone who turns care into work.
It doesn't mean that someone does all the work. That's ridiculous. Leading accessibility is usually a cat-herding job. You're trying to get designers, engineers, product managers, QA, researchers, stakeholders and sometimes vendors to move in the same direction for long enough to ship something useful.
You can be responsible. You can be accountable. What you can't be is alone.
Ask for help and then make the work visible.
Create a project in whatever task system your team already uses. Make that be the one place where people can answer where are we?
If the project page does not answer that question, people will ask you directly. They'll ask in Slack, you'll sit in meetings and you'll spend your week repeating yourself instead of moving the work forward.
The project page should say what you're doing, why it matters, who is involved, what is blocked, what changed this week and what "done" means.
"Make the product accessible" is not a project outcome.
"Improve accessibility" is not much better. Improve which part? For whom? By when? How will we know?
How about this:
By October 15, keyboard users can create an account, choose a plan and complete checkout without a keyboard trap, missing focus indicator or unreachable control.
Now you have something you can split into work, test and demo. You can decide whether a new request belongs in scope. You can tell a stakeholder that it matters, but it does not block the outcome. For larger projects, set milestones. By this date, checkout works with keyboard. By that date, screen reader announcements match the visible state. By the next date, QA has regression checks in place. Between those milestones, ship small chunks.
One thing about dates. People get nervous about dates in accessibility because they don't want to imply the work ends. It makes sense, but it creates a different problem. Without a date, accessibility becomes the project that can always absorb one more issue, one more page, one more component or one more debate about standards.
Having a date forces tradeoffs.
Having a date does not mean you stop caring after that day. It just means you choose what matters most before that day.
If the target is checkout by October 15, maybe account settings move out of scope. Maybe PDF remediation moves out of scope. Maybe colour tokens redesign waits because the missing focus state blocks every keyboard user today. Those tradeoffs are uncomfortable. Good!
Takeaway: clearly define what is out of scope by writing it down on that project page.
Someone will ask why their favorite issue is not included. Someone will say, correctly, that another page also has problems. Someone will worry that writing "out of scope" means the team has decided not to care.
It does not mean that.
It means you decided to finish something useful.
Can you change scope later?
Yes! You can change scope as you learn more. In fact, you should be at least open to it. If user research or testing shows that your chosen path misses the real problem, you'd be silly not to change scope. But make the tradeoff explicit. If something comes in, something else moves out. Don't change the date.
Don't pretend you can add work without cost just because you now have AI.
I need to say something about meetings.
They're not magic. Many are useless. But a 30-minute weekly project meeting can save you from two weeks of async confusion.
Bring stakeholders into such a meeting. These people won't read every ticket, they'll likely skim documents five minutes before a decision and ask the question you answered last week.
So put them in the room, do a demo and don't start with a status monologue. Show the damn thing. Show the checkout flow with keyboard only. Show the screen reader output before and after the fix. Show the focus order moving through the modal. Show the error message being announced after submit.
That's how they'll understand the issues you're fixing. Someone who thought the issue was theoretical will see that the visual order and keyboard order are out of sync. A product manager who thought the work was just some compliance thing will see a user unable to pay.
They'll have feedback. Don't ignore it. Turn it into tasks while everyone is there. Then rank them.
Demos can and do reveal more work. That's okay. That means people are seeing the product more clearly. But not every comment is equally urgent.
Then don't forget to ship the thing. Shipping small things is good. It creates evidence. You find out sooner when the approach is wrong. Reviewers can understand the change. QA can test the behavior. Stakeholders can see progress. Users get what they need sooner.
No awareness campaign can do all this for you.
Awareness can help people care. But they already do, don't they?!
Someone still has to lead.
Might as well be you.