Why Accessibility Should Start In Design

Accessibility often doesn’t get considered until late in the development process, if at all. That approach puts the burden on QA engineers to catch defects after code has already been written. Shifting accessibility work earlier — into the design and development phases — reduces both cost and effort while producing better results.

Research on defect costs shows a clear pattern: fixing an issue during design costs a fraction of what it costs later. Estimates range from a 6x increase during implementation to as high as 100x if the defect reaches production. Deque’s data from 20 years of accessibility testing shows that modern web applications now average between 30 and 50 accessibility defects per page — numbers that dwarf typical functional defect rates. Around 70% of accessibility defects can be avoided through the right combination of automated and guided testing during design and development.

Annotations: The Designer’s Accessibility Spec

Designers already annotate wireframes with colors, font sizes, and spacing. Accessibility information needs the same treatment. Consider a simple audio player with three controls: previous track, play/pause, and next track. The wireframe shows only icons — no text — so annotations become critical.

Three things must be specified for each control:

  • Name: The accessible name is what assistive technology announces. For the audio player, annotate “Previous track,” “Pause,” and “Next track.”
  • Role: These are clickable controls that perform actions, so each gets a semantic role of “button.” Don’t assume implementers will infer this from the visual design — state it explicitly.
  • State: Just as designers document hover styles, they must document accessible states. The previous and next track buttons should be disabled at the first and last tracks, respectively. The play/pause button’s name changes with state: “Play” when paused, “Pause” when playing.

Focus and hover states also need annotation so keyboard users can see which control is active. Without these details, developers have to guess — and accessibility gaps are the likely result.

Usability Testing With Disabled Users

Usability testing with participants who have disabilities is essential for understanding how real users interact with your system. Testing an existing product is straightforward, since participants can work with the actual interface. For new systems, there’s a catch: prototypes generated by design software are often inaccessible themselves and generally poor stand-ins for the final browser-based product.

The practical fix is to find a comparable existing component on the web and test with that instead. If you’re designing a new mobile navigation menu, locate a similar one someone else has built and observe how your participants interact with it. That gives you real data about what works and what doesn’t, minus the accessibility barriers of a fake prototype. Always prepare accommodations for participants based on their disabilities so the session runs smoothly.

Pattern Libraries And Cross-Team Collaboration

Pattern libraries serve both designers and developers. For designers, they keep components consistent across an application. For developers, they provide tested, reusable components that can be assembled quickly. Because these components appear throughout your product, their accessibility deserves extra scrutiny.

Teams where designers and developers work in isolation produce worse accessibility outcomes. Developers should join design reviews; designers should stay involved during implementation. Developers often know implementation constraints that affect design decisions, and designers can catch issues that developers miss — focus indication, tab order, color contrast, accessible names, and alt text. Well-annotated designs are only useful if someone verifies they were implemented correctly.

Automated Testing In Development

Several tools make accessibility automation practical. Static analysis through eslint-plugin-jsx-a11y gives immediate feedback while coding, and editors can display warnings in real time. Rules engines like axe-core integrate into nearly any framework and catch common issues. The most effective setup combines these with accessibility-specific test cases in the CI/CD pipeline. With everything wired up, teams can block pull requests until all automation passes — guaranteeing that many defects never reach dev servers, let alone production.

However, automation can’t catch everything. The limitation is fundamental: a tool can’t determine what meaning an image conveys in context, or whether it’s decorative. That judgment requires human understanding. A machine might describe what an image shows, but it can’t know the author’s intent. Manual testing still has an essential role.

Making Accessibility Part of the Workflow

Accessibility is most effective when it is introduced at the very start of a project, rather than retrofitted after development is complete. Building it into the ideation, design, and implementation phases leads to a more sustainable product — one that is easier to maintain and does not require costly remediation later.

Teams can set themselves up for success by relying on established guidance such as WCAG, ARIA, and the ARIA Authoring Practices. Community resources like Stack Overflow are also useful when specific implementation questions arise. To keep accessibility defects from reaching production, teams should integrate automated accessibility testing libraries into their continuous integration servers. This approach catches issues before they are merged and helps avoid regressions in the future.

Automated testing, however, has its limits when it comes to identifying certain accessibility problems, particularly those related to context or user interaction. Manual testing remains necessary, and tools like axe Beta are designed to bridge that gap between automation and human judgment. When accessibility defects are handled systematically — detect, fix, and prevent — applications not only improve in the short term, but remain accessible over time as new features are added.

Further Reading

Smashing Editorial