If your organization is starting an accessibility program, you'll find no shortage of optimistic guidance: here's what to build, here's what's working, here's what's coming. Most of that guidance is reasonable.
This post is the calibrated version. Not because the optimism is wrong, but because optimism without calibration is how accessibility programs quietly fail and become more performative than substantial.
Five risks. The honest version of what can go wrong, and what taking it seriously actually requires.
Risk 1: Without management commitment, governance is theater
This is the most important risk on the list. If you don't address it, nothing else matters.
The default state of any product organization is: features ship, accessibility regresses. That's not a moral failure. It's just how priorities work when no one is accountable. PRs that break keyboard support will merge. Designs that violate contrast will go to production. Components without proper semantics will be reused for years.
This is the default. It happens unless something explicit prevents it. What that something looks like is four things.
A decision: leadership announcing that accessibility is a non-negotiable product property. An owner: a named person or small team whose job is to make accessibility happen - not to personally fix every feature. A budget: time and money allocated as a line item, not extracted from feature work. And an expert: someone who actually knows the W3C specs, who can read across normative and non-normative text, and who can tell you with confidence what's wrong and how to fix it. That same person needs to understand how assistive technologies work - how they consume the accessibility tree, what specs they actually support, where their behavior diverges from what the standards promise, and at minimum how to verify support when it's in question.
Most organizations have zero or one of these. You need all four. Without them, you get what I'd call the performative trap - the organization "cares" about accessibility, there are Slack channels and onboarding mentions and maybe some lint rules in CI. But inaccessible code still ships, audits get postponed, expertise leaves with the one person who knew the most, and after eighteen months you're back where you started.
The good news: all four are decisions, not capabilities. You can have them on Monday if leadership chooses to.
Risk 2: It will slow you down
Yes, especially at first. I'm including this because it's the thing most people advocating for accessibility tend to skip.
The obvious cost is the learning curve. Engineers who haven't built accessible components will be slower writing them. Designers now considering semantic identity - not just visual fit - will spend more time on component decisions. PRs will get blocked on things that previously wouldn't have been raised. This fades over time.
The less obvious cost matters more. Accessibility doesn't slot cleanly into any single function. It overlaps with UX, UI, content design, and implementation. So when someone raises an accessibility concern, they're commenting on territory someone else considers their domain. UX designers feel second-guessed. UI designers feel overridden. Engineers feel audited by an outsider.
This is where a domain expert matters - not just to know the answers, but to navigate the overlap with credibility, to raise issues as a partner rather than a critic. Without acknowledging both costs up front, velocity expectations will be wrong, and the first wave of pushback will be misread as "accessibility doesn't work here" when the real problem is that the alignment phase wasn't budgeted for.
The per-feature cost drops as your design system absorbs accessible components and teams learn the vocabulary. But it never drops to zero. Accessible work is more work than non-accessible work. That's the honest answer.
Risk 3: Your safety nets have ceilings
Two safety nets that organizations lean on - static analysis tools and the WCAG specification itself - are both genuinely valuable and both have well-defined ceilings that teams tend to ignore.
How much static code analysis covers depends on what you measure. Deque's own published research found that automated tools could check only about a third of WCAG 2.1 Level AA success criteria - but when measured by volume of real-world issues, axe-core caught roughly 57% of what first-time audit customers had. Either way, a significant share of what matters is outside the tool's reach. The value of static analysis is real, but it's not what people usually think. It's not coverage - it's consistency. Two human auditors might disagree on a borderline contrast ratio. Axe won't disagree with itself. That persistence and reproducibility is why CI gates are worth running, for the slice they cover. The trap is treating the slice as the whole.
WCAG itself has a similar ceiling, though for a different reason. WCAG is a careful, deliberately technology-agnostic specification. It doesn't tell you how to implement its criteria in HTML - that translation requires reading across several companion documents. The ARIA spec defines the semantic vocabulary WCAG references. The HTML Accessibility API Mappings (HTML-AAM) defines how browsers map HTML elements and attributes to platform accessibility APIs - roles, states, properties, and events. The Accessible Name and Description Computation specifies the algorithm that determines each element's accessible name. The ARIA Authoring Practices show how to compose ARIA into known patterns like dialogs and comboboxes.
A reader who comes to WCAG alone, expecting it to be self-contained, won't just miss things - they'll misimplement what they think they understood. They'll satisfy the literal text of a success criterion in a way that fails for actual users, because they translated an agnostic requirement into HTML without consulting the specs that sit underneath it.
Neither of these safety nets is the finish line. Both are floors. The distance between the floor and actual accessibility is covered by people who know the discipline - who can do the audits, the AT testing, and the judgment calls that neither tools nor specs alone can provide.
Risk 4: Semantics is subtle - and everything is working against you
Even teams who care, who have tooling in place, will ship subtle accessibility bugs. This isn't a quality issue with the team. It's a structural property of the discipline.
But it's worth understanding why the structure works against you, because the reasons aren't obvious.
Visual affordances and semantics don't align. The web has a long history of visual conventions that feel right on screen but are semantically wrong. A link that looks like a button. A navigation that looks like a tablist. Designers inherit these conventions and reproduce them - not out of carelessness, but because that's what the industry taught them. Once you start paying attention to semantics, the legacy gets disorienting.
Component libraries weren't built for this. A library offers a "dropdown" component, but what you actually need might be a listbox, a menu, or a combobox - different things with different keyboard behaviors and different expectations for assistive technology users. The API might support setting the right semantics, but designers aren't looking at Storybook's API docs, engineers aren't asking "what is this semantically?", and product managers aren't putting that level of detail in their PRDs.
Nobody is trained in this. Designers excel at visual and interaction design. Engineers know architecture and state management. Almost nobody learns proper HTML semantics or the W3C accessibility specs. The knowledge exists; it's just not where the talent pipeline puts people.
Designers now carry a new, unnamed burden. When accessibility is required, picking a component for a new UI isn't just a visual decision - it's a semantic one. For assistive technology users, a listbox is a different thing from a menu, which is a different thing from a combobox, even if they look identical on screen. Each informs the user about expected content and keyboard behavior. That choice can't be deferred to engineering - in modern pipelines, the design handoff has already specified the component.
The consequence of all this is that the most common organizational response - "we'll hire better engineers" or "we'll send the team to a workshop" - doesn't address the structural problem. Senior engineers ship aria-modal bugs. Workshop attendees ship focus management bugs. Hiring and training help, but they don't close the gap alone.
The structural response is layers of verification at different cadences: domain experts reviewing continuously, periodic audits of what's shipped, and assistive technology testing for the flows that matter most. AT testing is the most valuable verification you can do - it's the only layer that tells you whether your product actually works for the people you're claiming to serve. It's also the most expensive and slowest, which is why it's used on demand rather than continuously.
Risk 5: AI-driven development is the next frontier
A growing share of code in every organization is being produced with AI assistance. Whether or not your team is doing this at scale yet, you will be. And the optimistic version of how that affects accessibility - better lint rules, agents that follow them, problem solved - is not what the evidence shows.
Microsoft's A11y LLM Eval benchmark tests how well LLMs generate accessible HTML across common components. The current results show a 12% overall control pass rate with no accessibility instructions. With basic prompting guidance, that climbs to 60%. With a multi-turn skill that generates and then self-reviews, the best results reach 86%. But the benchmark is careful to note that these pass rates reflect only what its automated checks can detect - passing every check does not mean the page is WCAG conformant or fully accessible.
The interesting finding is structural. The knowledge is already in the models. What's missing is the engineering around them - the pipeline that activates the right knowledge at the right phase, verifies the output, and stays current as both the models and the specs evolve. I've written about this in detail in Where Accessibility Lives in the Agent Pipeline. The people who can build that harness are the same people I've been describing throughout this post: domain experts who understand which failure modes happen where, and can read the AT behavior that machines can't evaluate.
One thread
If you've been reading for the pattern, all five risks land in roughly the same place. Tools matter. Process matters. CI gates are worth running. Design reviews are worth doing. AI-assisted workflows are worth building.
But none of it works without the people who actually know the discipline. If you don't have those people, the program you build around tools and processes will be theater - real-looking, quarterly-update-able, and in the end, not actually accessible.
The organizations taking this seriously now have a window. The European Accessibility Act has been in effect since June 2025. The US is moving the same direction. WCAG conformance is increasingly a product requirement, not a wish. The opportunity is to invest while it's still a choice, before it's only a compliance project.