It's Not a Checkbox. It's How You Build Software.

Let's get this out of the way right up front. Accessibility isn't about compliance. Yes, there are laws like WCAG, ADA, and the European Accessibility Act. And yes, you should follow them. But the real reason to care about accessibility is much simpler than that. You're building something that real people use. And some of those people navigate with keyboards. Some use screen readers. Some have low vision. Some are just sitting outside with their screen brightness cranked up because the sun is bright.

Accessibility isn't about a small percentage of users. It's about building UI components that work for everyone, in every situation. A good button should be clickable with a mouse, tappable on a phone, activatable with a keyboard, and understandable by a screen reader. That's not a special feature. That's a well-built button.

As a design engineer, you touch both design and code. That means you're in a unique position to catch accessibility problems before they get baked into the product. And even better, you can build accessible patterns into the design system itself, so every team that uses your components gets accessibility for free. That's real leverage. That's why this topic matters so much for frontend development.

┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Design Phase    │────▶│  Build Phase     │────▶│  Test Phase      │
│                  │     │                  │     │                  │
│  Check contrast  │     │  Semantic HTML   │     │  Keyboard test   │
│  Touch targets   │     │  ARIA when needed│     │  Screen reader   │
│  Focus order     │     │  Focus management│     │  Axe-core in CI  │
│  Color not alone │     │  Keyboard support│     │  Zoom to 200%    │
└──────────────────┘     └──────────────────┘     └──────────────────┘

         Accessibility is built in at EVERY phase, not bolted on at the end.

The Same Mistakes, Over and Over Again

After years of reviewing code and doing accessibility audits on web applications, I keep seeing the same problems. They're not complicated to fix. They're just easy to forget if accessibility isn't part of your normal workflow. Here are the ones that come up the most.

Images Without Alt Text

Every image needs an alt attribute. If the image is decorative (like a background pattern), use alt="" so screen readers skip it. If the image conveys information (like a chart or a photo of a product), the alt text should describe what's shown. This is one of the simplest accessibility wins in web development.

Clickable Divs Instead of Buttons

If a user can click something, it should be a <button> or an <a> tag. Divs with onClick handlers don't get keyboard focus. They don't announce themselves to screen readers. They don't respond to Enter or Space keys. You can add all that behavior manually with tabIndex, role, and onKeyDown, but why would you when the native HTML element gives it to you for free?

Low Contrast Text

That Light Gray You Love? People Can't Read It.

Light gray text on a white background looks subtle and elegant in a design mockup. But if the contrast ratio falls below 4.5:1, a significant number of people literally cannot read it. This includes people with low vision, people on cheap monitors, and everyone who's ever tried to use their phone outside. Use the WebAIM contrast checker to verify your text colors meet WCAG AA standards.

Missing Form Labels

Every input needs a label. Placeholder text does not count as a label. Placeholders disappear the moment someone starts typing, leaving them with no idea what the field is for. Always use a visible <label> element connected to the input with htmlFor. This is critical for screen reader users and for anyone who needs to tap on a small input field on mobile.

Other Common Pitfalls

Use the Right HTML First

The single biggest accessibility win in frontend development is also the simplest. Use the right HTML elements. Semantic HTML gives you keyboard support, screen reader announcements, focus management, and landmark navigation completely for free. No extra code. No ARIA attributes. Just the right tags.

What Semantic HTML Gives You for Free

The second version in that code example gives you landmark navigation (screen readers can jump between header, nav, main, and footer). It gives you focusable, activatable links. It gives you proper heading structure so screen reader users can scan the page by headings. And it gives you correct announcements, so when a screen reader hits a link, it says "Home, link" instead of just "Home." All of this is completely free. Zero ARIA needed.

ARIA: When Native HTML Isn't Enough

Sometimes you build custom UI components that don't map to any native HTML element. A toggle switch. A combobox with autocomplete. A drag-and-drop list. That's when you need ARIA (Accessible Rich Internet Applications). But here's the golden rule: if a native HTML element can do the job, use the native element. ARIA is a last resort, not a first choice. Bad ARIA is worse than no ARIA because it lies to screen readers about what something is.

ARIA Attributes You'll Use Most

Keyboard Navigation Done Right

Every interactive element in your web application should work with just a keyboard. No mouse required. This is non-negotiable for accessibility, and it's also great for power users who prefer keyboard shortcuts. Here are the standard patterns that users expect.

Standard Keyboard Patterns

Focus Trapping in Modals

When a modal dialog opens, focus should move inside it. When the user tabs through the modal's interactive elements, focus should loop back to the beginning instead of escaping behind the modal. When the modal closes, focus should return to the element that opened it. This is called focus trapping, and it's one of the most important keyboard patterns for user experience.

Visual Accessibility

Accessibility isn't just about screen readers and keyboards. There's a whole range of visual considerations that affect a huge number of users. Getting these right improves the user experience for everyone, not just people with disabilities.

Color and Contrast

• Contrast ratios: Normal text needs 4.5:1 minimum. Large text (18px+ bold or 24px+) needs 3:1. Use the WebAIM contrast checker to verify.
• Don't rely on color alone: If red means error, also add an icon or text label. About 8% of men and 0.5% of women have some form of color vision deficiency.
• Focus indicators: Never remove the focus ring without replacing it with something equally visible. Users need to see where keyboard focus is.

Sizing and Scaling

• Use rem for font sizes: So text scales when people change their browser font size settings. Using px locks them out.
• Touch targets: At least 44x44 pixels on mobile. Small tap targets are frustrating for everyone and impossible for some.
• Zoom support: Your layout should work at 200% zoom without horizontal scrolling or content being cut off.

Motion and Animation

Some people experience motion sickness or vestibular disorders triggered by animations. Always respect the prefers-reduced-motion media query in your CSS. When reduced motion is requested, disable or simplify animations. Tailwind CSS makes this easy with the motion-reduce: variant.

┌────────────────────────────────────────────────────────┐
│                  ACCESSIBILITY CHECKLIST                │
├────────────────────────────────────────────────────────┤
│                                                        │
│  PERCEIVABLE          OPERABLE          UNDERSTANDABLE │
│  ───────────          ────────          ────────────── │
│  ☐ Alt text           ☐ Keyboard nav    ☐ Clear labels │
│  ☐ Contrast 4.5:1     ☐ Focus visible   ☐ Error msgs   │
│  ☐ No color-only      ☐ No traps        ☐ Consistent   │
│  ☐ Captions           ☐ Skip links      ☐ Predictable  │
│  ☐ Resize to 200%     ☐ Touch 44px      ☐ Help text    │
│                                                        │
│  ROBUST                                                │
│  ──────                                                │
│  ☐ Valid HTML          ☐ ARIA correct    ☐ Works w/AT   │
│                                                        │
└────────────────────────────────────────────────────────┘

How to Test for Accessibility

No single tool catches everything. You need a combination of automated testing, manual testing, and assistive technology testing to get real coverage. Here's the approach that works best for frontend development teams.

Automated Testing

Automated tools like axe-core and Lighthouse catch about 30-40% of accessibility issues. That might sound low, but it covers the easy stuff that should never ship: missing alt text, empty buttons, broken ARIA, contrast failures. Run these in your CI pipeline so you catch regressions automatically.

Manual Testing

The stuff automated tools miss requires a human. Here's what you should test manually on a regular basis.

Making Accessibility Part of Your Process

Accessibility can't be a thing you do at the end. It has to be woven into every step of your design and development process. Here's how to make that happen without it feeling like a burden.

In Design Reviews

Check contrast ratios and touch targets before anyone writes a single line of code. Look at focus order. Make sure information isn't conveyed through color alone. These are easy to fix in Figma but painful to fix in React code after a component is already built and shipped.

While Building

Add ARIA attributes and keyboard support as you build each component, not as a separate pass afterward. It's much faster to build it right the first time than to retrofit it later. Use semantic HTML as your starting point and only add ARIA when native elements can't do what you need.

In Code Reviews

Make accessibility a standard part of your PR review checklist. Did the developer test with a keyboard? Are there proper labels on form inputs? Are interactive elements using the right HTML tags? This doesn't need to be exhaustive on every PR, but basic checks should be routine.

In Your CI Pipeline

Run axe-core in your automated test suite. Fail the build if there are new violations. This creates a safety net that catches regressions before they reach users. Pair this with visual regression testing for a really solid quality gate.

In Your Design System

This is the real multiplier. Build accessible patterns into your base UI components. When your Button component handles keyboard events, focus styles, and ARIA correctly, every team that uses that component gets all of that for free. They don't even have to think about it. That's the power of a well-built design system.

The Short Version

When you bake accessibility into your design system and your React components from day one, you're not doing extra work. You're doing the work right. Every component you build with proper accessibility becomes a building block that makes your entire product better for every user. That's not a compliance checkbox. That's just good engineering. And as a design engineer who works at the intersection of design and code, you're in the perfect position to make it happen.