Accessibility Needs to Catch Up with How We Actually Build Software

Here's a situation that probably sounds familiar. You're a developer working with React components, pulling in a nice toast notification library to handle user feedback. It works great, looks polished, and saves you hours of coding time. Then the accessibility audit comes back with recommendations about ARIA roles and focus management.

All perfectly valid advice, except you have no idea how to implement it because you're working three layers above the actual HTML.

This is the disconnect we keep seeing at AccessTime, and It's nobody's fault. It's just that accessibility advice hasn't quite caught up with how modern engineering actually works.

The World Has Changed (But the Advice Hasn't)

Let's start with something simple. Developers today don't really write HTML the way they used to. Sure, the fundamentals like semantic HTML is still the foundation of accessible web development. But telling a React developer to "use semantic HTML" is a bit like telling someone who shops at IKEA to "understand woodworking fundamentals." It's technically true, but it doesn't help them assemble that bookshelf sitting in their living room.

Modern developers work almost entirely through component libraries:

• They import pre-built UI components from libraries such as Shadcn, Radix UI, or Material UI.
• They customize behavior through props and APIs instead of writing HTML tags.
• They rely on these libraries to handle patterns like ARIA roles, keyboard interactions, and focus behavior out of the box.
• They expect consistent, framework-aligned functionality across the app.

And this approach is actually good (when the library handles accessibility well).

But not all libraries are created equal. In reality:

• Some libraries ship with excellent accessibility baked in.
• Others get a few fundamentals right but miss critical behaviors.
• Some provide accessibility features but hide them behind undocumented props or unclear APIs.
• Developers rarely know where a library stands until an audit flags an issue.

When Good Advice Meets the Real World

Once upon a long time ago during an audit, we flagged a toast notifications for accessibility issues (things like missing live region announcements and improper focus management). Our recommendations were textbook perfect: add these ARIA roles, implement this focus trap, configure these live regions.

The engineering team came back with a response that stopped us in our tracks:

We're using Toast Library X. We don't directly control the HTML. Can this library even do what you're asking?

They couldn’t just open the component and tweak the markup. Their options were:

• Fork the component library (which nobody wants to maintain),
• Rewrite their own toast component from scratch, or
• Dig through the library API to see whether the required accessibility features even existed.

Unsurprisingly, they did what most teams do when faced with an overwhelming fix, they deferred it.

Aligning Accessibility With Modern Engineering

At AccessTime, we've shifted our approach. Instead of generic HTML recommendations, we now give framework-aware, library-specific guidance. That means understanding the exact tools our clients use and tailoring our advice to fit their stack.

For instance, if you're using Radix UI's Dialog component, we won't just tell you "add focus management." We'll show you which props enable proper focus trapping, how to configure the overlay for screen readers, and what aria attributes are already handled for you versus what you need to add.

And when a component library simply cannot meet accessibility needs, we provide:

• Better accessible alternatives that fit the same use case
• Clear explanations of the gaps
• Migration paths that allow incremental adoption without rewriting the entire interface

The goal is simple,

to make accessibility improvements feel like iterations, not rebuilds

.

Why Component Libraries Are Actually Great for Accessibility

Here's something that might surprise you. Component libraries, when built well, are actually amazing for accessibility. They provide consistent keyboard navigation across your entire app. They apply ARIA roles the same way every time. They reduce the cognitive load on developers who might not be accessibility experts.

The problem isn't the concept of component libraries, but to understand which ones prioritize accessibility and how to use them properly.

This is where developer education becomes crucial. We need to teach engineers how to evaluate libraries for accessibility support, how to test components in their actual framework environment, and how to configure them correctly. It's not enough to know semantic HTML if you're never directly writing it.

Accessibility That Fits Your Workflow

When we work with teams now, we focus on what realistically fits their development process. We start by understanding:

• The framework they use
• The component library powering most of their UI
• Their build pipeline and deployment setup
• Their actual codebase and common patterns
• Their team’s skill level and time constraints
• Their sprint cadence and roadmap priorities

Then we provide recommendations that fit naturally into how they already build software. We establish changes that can be completed in the next sprint, not the next quarter.

This builds momentum. And momentum makes accessibility stick.

Building Accessibility Into Your DNA

At AccessTime, we're an accessibility-first software house working remotely around the world. Our team includes both certified accessibility professionals and experienced engineers who've worked with modern frameworks. We understand accessibility standards and we understand component-driven development, state management, and framework-specific quirks.

We help teams through audits, yes—but also through developer training, design-to-code collaboration, and ongoing framework-specific support.

The web has evolved. Development practices have evolved. It's time for accessibility guidance to evolve too. Not by lowering standards, but by meeting developers where they actually work.