Designing for Humans: A Guide to Accessibility Best Practices

Stop building barriers. Start building bridges. Here is a practical roadmap to creating truly inclusive web experiences.

As Frontend Architects, we obsess over performance budgets, component reusability, and state management scalablity. We architect systems designed to handle thousands of concurrent users and complex data flows.

Yet, too often, we overlook the fundamental architecture of human connection.

If a user cannot perceive, understand, navigate, or interact with our beautifully architected application, then the architecture has failed. Accessibility (often shortened to a11y) is not a feature flag we flip on at the end of a sprint. It is the baseline requirement for a functional user interface.

This article isn’t just a checklist of WCAG guidelines. It’s about a necessary shift in perspective, followed by the practical steps to bake inclusion into our codebases.

The Crucial Mindset Shift

“People are not inaccessible.
The environment we design is what becomes inaccessible.”

Before we look at code, we need to reset how we view disability.

For decades, society operated under the “medical model” of disability — viewing the individual as having a “deficit” that needed fixing.

As creators of digital spaces, we must adopt the Social Model of Disability.

The social model argues that people are not disabled by their impairments; they are disabled by the environment around them. A person using a wheelchair is not disabled by their paralysis; they are disabled by a building that only has stairs.

“Accessibility is not about ‘helping disabled people.’ It is about recognizing that our digital environment is currently designed to exclude them, and fixing that design flaw.”

When we build a website that requires a mouse to navigate, we haven’t identified a user with a “lack of motor function.” We have identified a website with a “lack of keyboard support.”

We are the architects of the environment. We decide where the digital stairs go, and where the ramps go. It is our professional responsibility to stop building inaccessible environments.

The Pillars of Accessible Frontend Architecture

As an architect, my role is to define standards that make doing the right thing the easiest thing for the development team. Accessibility must be built into the foundation of our design systems and component libraries.

Here are the practical best practices we must enforce.
1. Semantic HTML: The Non-Negotiable Foundation

The single biggest accessibility upgrade you can make to any codebase is writing proper, semantic HTML.

Screen readers and assistive technologies (AT) rely entirely on the Accessibility Tree — a structure derived directly from the DOM. If your DOM is a soup of <div>s and <span>s with click handlers, the Accessibility Tree is incomprehensible.

Best Practices:

• Landmarks matter: Use <main>, <nav>, <aside>, <header>, and <footer>. These allow AT users to jump quickly to relevant sections of the page.
• Headings are a hierarchy, not styles: Never choose an <h3> just because it looks the right size. Headings (<h1> through <h6>) create an outline of your content. Skipping levels (going from H1 directly to H3) confuses navigation.
• Buttons vs. Links: This is the classic frontend mistake. If it goes somewhere new (changes URL), it’s an <a>. If it performs an action on the current page (opens a modal, submits a form), it’s a <button>.

2. The “No-Mouse” Test (Keyboard Navigation)

Many users — including those with motor impairments, power users, and people temporarily limited (like holding a baby with one arm) — rely solely on the keyboard.

If you cannot tab through your entire application and successfully use every feature without touching your trackpad, it is not accessible.

Best Practices:

• Manage Focus: When a modal opens, focus must move inside the modal. When it closes, focus must return to the button that opened it. Without this, keyboard users get lost in the DOM.
• Never suppress the outline: outline: none is a cardinal sin of CSS unless you are replacing it with a high-contrast custom focus indicator. Users need to know where they are on the page.
• Logical Tab Order: The tab order should match the visual reading order. Be very careful with CSS tricks (like flexbox ordering) that disconnect visual placement from DOM placement.

3. ARIA: The Bridge, Not the Foundation

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) is a powerful toolset for making complex web controls accessible.

However, the first rule of ARIA is: Don’t use ARIA if a native HTML element will do.

A native <button> comes with built-in keyboard focus and screen reader announcements. A <div role="button"> requires you to manually add JavaScript for Enter/Space key handling and focus management. Why reinvent the wheel poorly?

When to use ARIA:

• Dynamic Content: Use aria-live="polite" for alerting screen readers that content has updated dynamically (like a toast notification or form error appearing without a page reload).
• State Indication: Use attributes like aria-expanded="true/false" on accordions or menus to tell the user if the section is currently open or closed.
• Labeling Icons: An icon button with no text is invisible to a screen reader. Use aria-label="Close menu" so the AT user knows what the "X" icon does.

4. Visual Clarity and Robustness

Accessibility also encompasses users with low vision, color blindness, or cognitive considerations.

Best Practices:

• Color Contrast: Text must have sufficient contrast against its background (aim for WCAG AA standards at a minimum). Don’t guess; use automated tools in your CI/CD pipeline or design system to check this.
• Don’t rely solely on color: Never indicate a state (like an error) using only color. If a form field turns red on error, also add a text label or an icon. A colorblind user may not see the red state.
• Respect User Preferences: Modern CSS allows us to detect user preferences like prefers-reduced-motion or high contrast modes. Your animations should be optional; if a user has requested reduced motion, disable those fancy scroll-triggered effects.

The Architect’s Duty

Accessibility is a quality metric, just like performance or security.

It isn’t easy to retroactively fix a sprawling codebase that ignored these principles for years. It requires effort, education, and empathy.

But as architects, we set the direction. By embedding these practices into our standards, our code reviews, and our definition of “done,” we stop creating inaccessible environments. We start building the digital world we all deserve — one that everyone can use.