The Accessibility Imperative — Why WCAG Is a Leadership Issue, Not Just a Technical One
Accessibility compliance gets treated as a technical checkbox. It's actually a values question — and the teams that treat it that way produce better outcomes at every level.
2026-07-24
In 2021, I inherited responsibility for WCAG accessibility compliance across 5,000 live web pages at a Fortune 500 bank. My team hadn't been prepared for it. The timeline was aggressive. The tools were inadequate.
Most people in that situation would have treated it as a technical problem: identify the violations, fix the violations, pass the audit.
I treated it as a leadership problem — specifically, as an opportunity to build something the team would be proud of rather than just compliant with.
The outcome was different because of that framing.
What Accessibility Actually Is
WCAG — the Web Content Accessibility Guidelines — exists to make the web usable for people with disabilities: visual, auditory, motor, and cognitive. At the technical level, it's a set of standards for HTML structure, color contrast, keyboard navigation, screen reader compatibility, and alternative text.
At the values level, it's a commitment that the digital products you build are usable by everyone — not just the majority who happen to navigate the same way the developer does.
That values framing matters. A team that understands why accessibility exists — who it serves, what it enables — builds it differently than a team that treats it as a compliance obligation.
How I Built the Program
The first decision: I made accessibility a domain. I didn't try to train everyone on everything — I identified the team members with the sharpest eye for detail, the strongest interest in the problem, and the technical capacity to become genuine experts.
I gave them ownership of the domain. I called them accessibility SMEs. I sent them to training. I made sure that when accessibility questions came up in cross-functional meetings, they were in the room and their judgment was authoritative.
The team didn't just learn to fix accessibility issues. They learned to see them — the way an experienced designer sees visual hierarchy, or an experienced developer sees security vulnerabilities. The domain became a professional capability, not a compliance task.
The Tooling Investment
No compliance program works without tooling. I worked with SiteImprove developers to customize QA reports specific to our authoring team's workflow. I standardized how we used the Axe dev tool. I created a testing protocol that made accessibility checks a natural part of the page delivery process, not a separate audit step.
The principle: make the right behavior the easy behavior. Don't ask people to add steps — integrate the check into the existing process.
The Cultural Signal
The moment I knew the program was working: a junior developer caught an accessibility issue in a senior developer's work during code review and flagged it without hesitation.
That moment — someone early in their career holding the standard against someone more senior — means the standard has been genuinely internalized. It's not compliance. It's culture.
That's the outcome worth building. Not passing an audit. Building a team that wouldn't ship inaccessible work even if you asked them to.
Gray Hodge is a Fractional Chief AI Officer and full-stack engineer. He builds AI-powered platforms for small businesses and government contractors. Work with Gray →