Accessibility is more than meets the eye.
Yet designers are literally trained to think with their eyes, since appearance and flow (for sighted users) form the backbone of design thinking on the web.
And, as designers have come to be concerned about accessibility, their first impulse is to worry, unsurprisingly, about visual issues. Nothing wrong with that – indeed, it’s a welcome development – but it’s not the whole story, either. In fact, when it comes to accessibility, it’s a very small part of the story.
Consider a seemingly simple example.
A not-so-simple example
Here are three alternative buttons for, say, a design system. Which of these isn’t accessible?
Did you guess the button in the center, the one that’s a much lighter shade of purple?
It’s a reasonable guess. And you bet, there is a color contrast problem there.
But there is more afoot here than color contrast.
Here are six questions you’d want the answer to before you’d be able to tell if this button, or any of them, were accessible to screen reader and keyboard users.
| Keyboard Interaction | Screen Reader Semantics |
|---|---|
| Which keystroke is supposed to activate the button? | How many states do you really need? |
| How does focus get set after the button is clicked? | What should the accessible name be? Is it just “Buy Now?” |
| Under what circumstances does focus stay on the button after it is pressed? | Is the <button> tag the only way to get the role of the button assigned? |
A long list of issues like this is laid out helpfully in the ARIA Authoring Practice Guide published by the W3C. All of these issues are concerned with how the button works.
And zero of those issues are about how it looks.
Not my job?
It would be understandable if a designer wanted to view their accessibility responsibility as limited to visual issues like color contrast and touch target size.
But to us, that would be a very big missed opportunity.
The designer and the developer are, to take a baseball analogy, the pitcher and catcher of web development. In baseball, it’s sometimes said that the only two players you need on a team are the pitcher and the catcher – one person to throw unhittable pitches, and one of them to catch them!
In accessibility, it’s similar. If the designer and the developer get the design and handoff right, then that is very close to the whole ballgame, and certainly it has an outsized impact downstream in the product development life cycle.
Fewer accessibility bugs created means fewer bugs that need chasing down later, either in QA or in a post-production audit.
What to do
To start, designers should get used to thinking about these four fundamental aspects of accessible design.
1. States, roles, and attributes for components
Designers (and certainly those working on design systems) should be thinking about how components will look and behave on a web page or in a mobile application.
Components are self-contained and reusable building blocks in web design such as buttons, forms, and menus. They can be designed (and coded) once and reused many times, with or without variations, saving both design and development effort. It is important to note that for components with many variants, each variant needs to be accessible.
All interactive components need states, roles, and attributes to define functionality, appearance, and behavior.
For example, the buttons above need to have two states to be accessible, a default state and focus state. Ideally, they would also have a hover state. A missing focus state makes it difficult for keyboard and screen reader users to locate and interact with the button, and a missing hover state can make buttons less discoverable for mouse users.
2. Visual issues, like color contrast and touch target size
Many designers have an idea of what they want to create before they create it, but can the concept be designed in an accessible way? It’s important to look for visual issues while executing the vision.
Check for things like color contrast between text and background, readability of the font choices, and adequate touch targets on interactive elements (especially important in mobile design).
3. Structural issues, like landmarks and headings
An important concept in accessible design is layout structure, which includes landmarks and headings. These elements are essential to screen reader users, since both enable them to navigate content much more efficiently.
Consider a web page that talks about, say, product development updates from a company. It might have a section called “News” that discusses released features, and a section called “Upcoming Releases” that talks about things in the pipeline. A screen reader user might want to skip the News section directly and go straight to the Upcoming Releases section. If the design is properly annotated and developed, they will be able to do that.
Landmarks and headings work together in this way, along with focus order, and they are essential to the accessibility success of any design.
4. Developer handoff
It’s probably true that developers don’t always perfectly handle handoffs from designers, and it’s also probably true that handoff instructions from designers aren’t always comprehensive.
For accessibility, the handoff stakes are especially high.
If designers can get in the habit (or get a tool that helps them get in the habit) of annotating designs precisely and comprehensively for all the issues discussed above, then even developers who themselves don’t know a ton about accessibility will still be able ship accessible features.
What our Design Assistant can do for you
Asking designers to perfectly annotate designs is asking a lot. The good news is, Evinced can help.
Our Figma plugin, Design Assistant, bridges the knowledge gap by helping designers make accessible designs and teaching accessibility in the process.
Design Assistant works in two modes:
- Component mode: Scans design system components (even ones with many variants) for accessibility issues like missing states or contrast problems and suggests appropriate fixes.
- Layout mode: Guides designers through annotating landmarks, assigning heading levels, writing alt text, and defining keyboard interactions.
Everything is saved directly in the design file, so annotations and guidelines are persistent across teams and handoffs. Even if a developer only has view-only access, they can still get all the information they need to turn accessible designs into accessible code. And we take security seriously, so all of the notes are saved on the file, not sent back to Evinced.
We’re working on some exciting features for Design Assistant, too, including automating annotation with AI. This feature will let designers automatically identify and tag landmarks, headings, roles, and alt text. It will also be able to handle advanced elements like sortable tables, links, and nested grids.
Soon you’ll be able to hand your designs off to your developer (even the most complex pages) and they can be made accessible faster and more reliably, without hours of manual work.
You can watch the Design Assistant demo I did at Config 2025 to see more.
What we all want
For the longest time, designers and product managers have worried about how to make products that don’t just work, but work well. No product manager stands in front of an audience and says, of their website, “Well, at least it works.”
But because accessibility has seemed so hard, teams have been forced to worry just about the bare minimum. Plenty of product managers have stood in front of an audience and said, with some relief, “Well, our website is accessible.”
Our hope is to make it so easy for teams to get the basics of accessibility right, that they will have bandwidth to consider the larger problem of how to make a product that’s amazing for screen reader users, and keyboard users, and voice control users, and sighted users. In other words, for everybody. And with the right tools that take care of the basics, we think that’s not only possible, but likely.