The Growing Story of Accessibility in Web Applications and Radix UI

In recent years, not only “good-looking” interfaces but also interfaces that are accessible to everyone have become a topic of discussion in web applications.

This change is not a coincidence; it has a serious impact on both the technical and business sides.

At exactly this point, an infrastructure that is mentioned more and more frequently in modern frontend projects comes forward: Radix UI.

A UI That “Works” Does Not Have to Be Accessible

Let’s think about the following interactions in a web application:

• A modal opens
• A menu closes
• A dropdown is selected
• A tooltip appears

Most of the time, our check is this:

But accessibility asks the following:

• Can it be used with a keyboard?
• Is focus managed correctly?
• Does the screen reader read the correct content?
• Can a non-visual user still access the background?

In most projects, the answer to these questions is no.

Why Has Accessibility (a11y) Become a Topic?

For a long time, accessibility was a “we will look at it later” topic.

But today:

• It is mandatory in enterprise projects
• It is a legal requirement in public and financial projects
• It creates legal risks in the US / EU markets
• User profiles have expanded

in short:

What Is Actually Hard About UI Components?

Writing a modal is not as simple as it looks.

For an accessible modal:

• Focus must be trapped inside
• It must close with ESC
• The background must be inactive
• The screen reader must read only the modal

Each of these behaviors must be implemented correctly.

What Does Radix UI Solve?

Radix UI solves the behavior layer of UI components:

• Keyboard navigation
• Focus management (trap & restore)
• ARIA roles and states
• Screen reader compatibility
• Edge cases (nested dialogs, portals, scroll lock)

But it does not do the following:

• It does not provide styles
• It does not enforce a theme
• It does not generate CSS

For this reason, Radix UI is a headless infrastructure.

Radix UI Slot and asChild: Why Is Semantic HTML Not Broken?

1<Dialog.Trigger asChild>
2  <a href="/profile" className="text-blue-600 underline">
3    Open profile dialog
4  </a>
5</Dialog.Trigger>

Here:

• Radix does not create an extra
• It uses your element
• But it transfers all behavior and accessibility to it

Result:

• Correct HTML semantics
• CSS is not broken
• Accessibility is preserved

This is a fundamental solution to a major problem that UI libraries have had for years.

Where Does shadcn/ui Fit in This Picture?

Today, many developers do not write Radix UI directly. But they use shadcn/ui.

shadcn/ui:

• Is built on Radix UI primitives
• Provides visual design and Tailwind integration
• Simplifies the complexity of Radix UI

An example shadcn Button:

1<Button asChild>
2  <Link href="/dashboard">Dashboard</Link>
3</Button>

Here:

• Behavior: Radix UI
• Appearance: shadcn/ui
• Semantics: your HTML

This invisible infrastructure role is the main reason for the popularity of Radix UI.

Conclusion

Today, everyone who uses shadcn/ui is using the accessibility approach of Radix UI, whether they are aware of it or not.