Every team I've worked with in fifteen years has claimed accessibility matters. The ones where it actually held up under deadline pressure had one thing in common: accessibility lived in code and tooling, not in intentions. Here's the setup I use, and where AI helps and hurts.
Semantic HTML is 80% of the work
Before ARIA, before audits: use the element that means the thing. A button for actions, a for navigation, real label elements on inputs, headings in order. Most accessibility failures I see in B2B SaaS aren't exotic — they're div soup with click handlers. When I review AI-generated components, this is the first thing I check, because LLMs trained on the open web have absorbed plenty of div soup. They'll produce semantic markup if your prompt and your codebase model it, and reproduce garbage if that's what surrounds them. Your existing code is a prompt.
Design decisions that are accessibility decisions
Three that come up constantly in my fintech and marketplace work:
- Contrast at the token level. Don't audit contrast screen by screen; validate it once, in the palette. Every color pairing in the design system gets checked when the token is defined. After that, any screen built from tokens inherits compliance. This is the whole argument for tokens-with-teeth.
- Focus states are designed, not defaulted. Keyboard users in enterprise software are not an edge case — power users of dense B2B tools live on the keyboard. I design the focus ring with the same care as the hover state, and I do a keyboard-only walkthrough of every flow before calling it done. It takes ten minutes and finds something every single time.
- Error messages that say what to do. "Invalid input" fails everyone, and fails screen reader users hardest, because they can't glance around for context. Tie the error to the field programmatically (
aria-describedby) and write it as an instruction: what was wrong, what to enter instead.
Where AI actually helps
AI-accelerated workflows have made my accessibility practice better, not worse — but only in specific ways:
- Audit at scale. I can run a WCAG-oriented review pass over an entire component library in an afternoon: a model flags candidates, I verify each one. The model's recall is great; its precision requires my judgment.
- ARIA patterns on demand. Getting a combobox or a disclosure pattern right from memory is error-prone. Generating it from the documented ARIA Authoring Practices pattern and then testing it with a real screen reader beats hand-rolling it.
- Cross-model review. My standing rule — whoever writes doesn't review — catches accessibility regressions the author model is blind to. A second model reviewing generated code has caught missing labels, broken focus order, and icon-only buttons with no accessible name.
The non-negotiable
No automated pass, AI or otherwise, replaces using the interface the way affected users do. Tab through it. Turn on VoiceOver. Zoom to 200%. Evidence over intentions: a checklist that says "accessible" is a claim; a keyboard walkthrough recording is proof.
Accessibility isn't a compliance layer you add. It's what "works" means, fully stated.