Accessibility Compliance: Building It In Rather Than Auditing It

Accessibility built into components costs almost nothing. Accessibility retrofitted after an audit costs many times that, and arrives under a deadline. This guide covers what conformance requires and where the real barriers are, drawing on FISTA Solutions' web and mobile work. This article is general guidance, not legal advice.

Where do the real barriers come from?

Not from the things automated tools find, mostly.

Barrier	Caught by automated testing?
Missing alt text	Yes
Insufficient contrast	Yes
Unhelpful alt text	No
Keyboard traps	Rarely
Focus lost after an action	No
Dynamic content not announced	No

What does conformance require in practice?

Semantic markup that describes what things are, keyboard operability for everything interactive, sufficient contrast, text alternatives that convey meaning, and behaviour that does not surprise.

The graded levels matter for stating a target. Most organisations aim at the middle level, which covers the majority of practical barriers without the more demanding requirements of the highest.

Name the target explicitly in the brief. Teams told to make it accessible produce varying interpretations; teams given a conformance level produce something measurable.

Why is keyboard navigation the main issue?

Because it is invisible to anyone testing with a mouse, and because modern interfaces build custom controls that look interactive without being operable.

The recurring failures are keyboard traps in modals, focus that vanishes after an action, focus order that does not match visual order, and custom controls with no keyboard handling.

Test by unplugging the mouse and completing a real task. Most teams find blocking problems within five minutes, and the fixes are usually small.

What does focus management involve?

Moving focus deliberately when the interface changes: into a dialog when it opens, back to the trigger when it closes, to a validation message when submission fails, and to new content when it is inserted.

This is the single most common gap in modern interfaces and the one that makes a product unusable rather than merely awkward. A dialog that opens without moving focus leaves a screen reader user reading the page behind it.

Build it into the components once. Handling it per instance guarantees inconsistency.

How should dynamic content be announced?

With live regions, used sparingly and deliberately.

Content inserted without announcement is invisible to assistive technology; content announced too aggressively floods the user. Both make the interface worse, and the balance requires testing rather than reasoning.

Streaming content — increasingly common in AI interfaces — is the hardest case, because naive implementations announce every fragment. Announce completion rather than every token. See streaming UI patterns for AI apps.

Why does this belong in the component library?

Because a correct component fixes every use of it, and a page-by-page fix regresses with the next feature.

A design system with accessible dialogs, menus, form fields, and tables makes most of the application accessible by construction. Teams then only need to handle the genuinely novel interactions.

That is also the argument for investing in the system rather than in audits. Audits find the same classes of problem repeatedly until the components change. See design system development.

What about testing with real users?

It finds what neither automated tools nor developer testing does: whether the experience makes sense, not merely whether it is technically operable.

A form that is fully conformant and requires twenty tab presses to reach the submit button is compliant and poor. Only someone using it that way reports that.

Where user testing is not available, testing with a screen reader yourself is the next best thing and considerably better than nothing.

What are the common mistakes?

Relying on automated tools. Treating accessibility as an audit rather than a build practice. Fixing page by page. Custom controls without keyboard handling. Announcing every streamed token. And overlay products used in place of building it properly.

How do you test it?

Automated checks in the pipeline for the mechanical issues, keyboard-only testing for every flow, screen reader testing for the main journeys, and user testing where possible.

Add the automated checks as a gate rather than a report. Issues caught at build are cheap; issues found in an audit are a project.

What does it cost to operate?

Almost nothing when built into components during development. Substantial when retrofitted, because every template and component has to be revisited under a deadline.

The cost of not doing it includes litigation exposure in some jurisdictions and the straightforward loss of users who cannot complete a purchase or a task.

What should you measure?

Conformance against the stated level, issues found per release, and completion rates for keyboard-only and screen reader journeys through the critical flows.

What about AI-generated content and alt text?

Generated descriptions are a useful starting point and not a substitute for review. They are fluent and frequently miss what matters in context — the trend in a chart, the relationship in a diagram, the reason the image is there.

An inaccurate description is worse than a missing one, because it misleads confidently rather than prompting the reader to look elsewhere. See AI and ADA accessibility.

When is this the wrong approach?

There is no context where accessibility is the wrong approach. There are contexts where the conformance target is lower — an internal tool with a known user population — and even there keyboard operability and semantic markup are worth having.

What should you do first?

Unplug your mouse and complete your product's main task with the keyboard alone. The blocking problems you find in the first five minutes are the priority list.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: accessibility built into components rather than audited afterwards, keyboard and screen reader testing run during development, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read AI and ADA accessibility.