Building
Accessibility
as a Foundation
Why accessibility must be architectural from day one, not a cosmetic afterthought you retrofit later.
Accessibility is not a feature you add at the end. It is an architectural decision that shapes component design, state management, routing, and testing from the first line of code. When you treat accessibility as cosmetic polish, you create technical debt that compounds with every sprint. When you build it into your foundation, you create better software for everyone while avoiding costly retrofits, legal risks, and exclusion of users who depend on assistive technologies.
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
The
Afterthought
Problem
Most development teams treat accessibility the same way they treat security audits or performance optimization: something to worry about later.
Accessibility is not a layer you add on top, it is a foundation you build from. The decisions you make on day one, how you structure state, what elements you choose, how routing works, determine whether accessibility is achievable or impossible.
Every day you wait makes the debt worse. Every component you add that lacks accessible patterns becomes another thing to fix. The codebase grows around inaccessible foundations, and fixing them means touching everything.
Architecture,
Not Decoration
Accessibility is architectural because it affects every layer of your application.
Component Hierarchy
Your component hierarchy determines whether focus management works correctly. A modal that renders outside the component tree breaks keyboard navigation unless you explicitly manage focus.
State Management
Your state management determines whether assistive technologies understand your application. When content updates dynamically, screen readers need to know.
Routing
Your routing determines whether navigation works for everyone. Client-side routing that never updates focus leaves keyboard users lost in the page.
Data Fetching
Your data fetching affects whether loading states are accessible. When you fetch data, someone using a screen reader needs to know loading started, when it finished, and whether it failed.
It cannot be retrofitted without touching every architectural decision you have made.
Progressive enhancement and accessibility share the same foundation: semantic HTML.
Semantic HTML as Bedrock
Every accessible application starts with semantic HTML. Not
<div> elements with role attributes, but actual semantic
elements that convey meaning.
Use <button> for actions, not <div onClick>. Use
<a> for navigation. Use <main>, <nav>,
<aside>, <article>, <section> to structure
content. Use <form> to collect input. Use <label>
to describe fields.
When you choose the right element, you get accessibility for free. Focus management works. Keyboard interaction works. Screen reader announcements work.
When you choose the wrong element and try to fix it with ARIA,
you are playing catch-up. You need to add role="button" and
tabindex="0" and onKeyDown handlers. You need to add aria-label
because there is no semantic content.
The first rule of ARIA: do not use ARIA if semantic HTML can accomplish the same thing.
<div
onClick={handleClick}
role="button"
tabIndex="0"
onKeyDown={handleKey}
aria-label="Submit"
>
Submit
</div><button
onClick={handleClick}
>
Submit
</button>
Component Design
Starts With
Accessibility
When you design components, accessibility shapes fundamental decisions about interfaces and composition.
Modal Dialog
- Focus trap
- Focus restoration
- ESC key handling
- aria-labelledby
- role='dialog'
- Backdrop click behavior
Tabs Component
- Roving tabindex
- Arrow key navigation
- Home and End keys
- aria-selected
- Label associations
Combobox
- aria-expanded
- aria-autocomplete
- aria-activedescendant
- Keyboard interactions
- Screen reader announcements
They affect state management, keyboard event handling, DOM structure, and component lifecycle. They must be part of the initial design, or you end up rebuilding the component from scratch.
Testing From
the Start
Accessibility testing is not something you do before launch. It is something you do during development, starting from the first component.
Keyboard Navigation
When you write a component, test it with keyboard navigation.
- Can you reach every interactive element?
- Can you trigger every action?
- Can you see focus indicators?
Screen Readers
When you add dynamic content, test it with a screen reader.
- Does content announce when it loads?
- Do errors announce?
- Do state changes communicate?
Shift in Mindset
Accessibility is not a compliance checklist you run through before shipping. It is a definition of "working" that includes everyone.
A button that only works with a mouse is a broken button, not a button that needs accessibility work.
Automated Tools Help
- axe-core, pa11y, Lighthouse catch obvious issues
- But they cannot catch incorrect keyboard behavior or unhelpful announcements
- Manual testing is required
The Real Cost
of Ignoring
Accessibility
The costs of ignoring accessibility are real, measurable, and increasing.
Retrofitting Costs
With multiple engineers dedicated full-time. The opportunity cost of that time is significant. You are not building features, you are fixing what should have been built correctly initially.
The Upside of
Building It Right
The costs of ignoring accessibility are high, but the benefits of building it correctly are also significant.
Better Code
Accessible code is often better code. Semantic HTML is easier to maintain than div soup with role attributes.
No Retrofitting Tax
Every feature ships accessible from day one. There is no cleanup phase. No compliance panic before launch.
Easier Testing
When components follow consistent accessible patterns, you know what to test. When state management handles announcements architecturally, you don't need to verify each component individually.
Decreased Legal Risk
Having demonstrable accessibility practices significantly reduces your exposure. Many suits target the worst offenders.
Expanded Market
Accessible sites reach more users, including elderly users with declining vision or motor control, users with temporary disabilities, and users in situational limitations.
The Right Way
You build the web the way it is meant to be built. Accessible to everyone, regardless of ability.
Building Accessibility
Into Your Culture
Making accessibility foundational requires cultural change, not just technical change.
Need ongoing training. Accessible patterns in component library. Code reviews check accessibility. PR templates include testing steps.
Design for accessibility from the start. Verify color contrast. Design focus states. Specify keyboard interaction. Document screen reader announcements.
Prioritize accessibility as core functionality. Estimate accessibility work in stories. Treat accessibility bugs like any other bug.
When accessibility is one person's responsibility, it becomes an afterthought. When it is everyone's responsibility, it becomes part of how you build software.
Key Takeaways
Accessibility is not a feature you add later. It is how you define "working" from the start.
Continue Learning
The Progressive Enhancement Mindset
Build resilient web applications that work for everyone, even when failures occur.
Accessibility Guide
Accessible Interaction Playbook
A comprehensive guide to building accessible interactive components and user experiences.