A few years ago, I became the accessibility champion for a TXI project. I worked with our Accessibility Working Group and TXI leadership, guiding conversation around what the role should be. I knew how much accessibility mattered. I cared deeply about the work and was willing to take responsibility for it.
I still got stuck. I reached out to Kara Carrell, another engineer on the Accessibility Working Group who was leading the newly defined Champion roll out. My message to her essentially said:
What do I do now?
That question captures something important about accessibility champions. You can care about accessibility and still be unsure where to begin. You can take ownership before you have deep expertise. In fact, that is how many people become useful in the role.
They begin by asking.
A champion is a point of accountability
At TXI, we support accessibility in two connected ways. Our accessibility working group brings people together across projects to share knowledge, improve our practices, and help teams work through questions.
Individual project teams also identify accessibility champions. The champion helps keep accessibility visible within the everyday work of that team. That person does not need to personally fix every issue. They do not need to memorize every guideline or immediately answer every technical question.
They do need to make sure the question gets asked. During one of our town halls, accessibility consultant Jeff Bishop described a champion as someone who notices barriers, asks the right questions, and knows where to find information.
I would add one thing to that definition: accountability.
A champion helps make sure someone runs the scan, reviews the workflow, talks to the user, raises the concern, or finds the person who can help. They keep the issue from disappearing simply because the answer was not obvious. The role is less about possessing every answer and more about owning the follow-through.
The expertise requirement is an invisible wall
Accessibility is broad. It touches design, engineering, content, research, product strategy, and the way teams make decisions. That complexity can make people assume they need extensive training before they are allowed to contribute.
They think:
I do not know WCAG well enough.
I am not a designer.
I do not use assistive technology.
Someone else probably understands this better.
Then they stay quiet.
That is the invisible wall we need to remove.
You do not need a certification to ask, “Have we considered accessibility here?”
You do not need a technical background to ask someone to test a workflow with a keyboard.
You do not need to understand every result before running a browser accessibility scan and bringing the report to the team. The first useful action is often much smaller than people expect.
My first step was asking for help
When I asked Kara what to do as a new champion, she did not hand me a stack of standards and tell me to come back after I had studied them. She walked me through an accessibility review of the application’s major workflows.
I had never done one before. I did not know what the output would look like or how we would decide what to address first. But after the review, we had something concrete. We could see issues. We could discuss priorities. We had a place to start.
Later, I realized the project needed automated accessibility testing. I did not know how to set that up either, so I asked our engineering team. A colleague who had used the tools on another project shared what he knew, and I used that guidance to move the work forward.
At no point did I suddenly become the person who knew everything. I noticed a need. I asked someone. I took the next step.
That was the job.
Asking the question is a skill
Teams sometimes hesitate to raise accessibility because they worry about how the question will be received.
They do not want to sound like they are criticizing someone’s work. They do not want to be seen as slowing the project down. They may worry that asking the question creates an expectation that they should also know the answer.
Working with AI tools can provide an unexpected place to practice.
You can ask an AI coding assistant:
Did this change introduce any accessibility issues?
How would this interaction work without a mouse?
What assumptions are you making about the user?
How can this be tested beyond an automated scan?
The AI will not feel embarrassed that it missed something. It will not think you are nagging it. You can build the habit of questioning the work, checking its claims, and asking for evidence.
Of course, the AI’s response is not the final answer. The tool can miss barriers or provide advice without enough context. The value is in practicing the question.
Once asking becomes routine, it becomes easier to bring that same habit into planning sessions, design reviews, client conversations, and team discussions.
A starting point should create movement
One reason accessibility efforts stall is that the topic can feel too large. A team knows accessibility matters but has no shared understanding of what to do on Monday morning.
At TXI, we have an accessibility roadmap that helps to reduce that ambiguity. It prompts project teams to align internally, learn about their users, check for barriers, communicate with the client, and address what they find. This simple best-practice template gives accessibility champions a view of the checkpoints along the way, prompting them to fill in the details of how to implement each step in the context of the specifics of that client and that moment in the project engagement.
