ARIA Roles: What Product Designers Need to Know

March 26, 2026 7 min read

When you don't specify ARIA roles in your component annotations, developers guess. And when developers guess about accessibility, screen reader users lose. You don't need to become an accessibility expert. Understanding eight core ARIA roles is enough to write the specs that make your designs actually work for everyone.

Why this is a designer's problem

You already own the interaction model. You define what a button does, when a dialog appears, how tabs organize content. That model is invisible to assistive technology unless you tell it what's happening.

ARIA stands for Accessible Rich Internet Applications. It's a set of HTML attributes that tell screen readers, voice controls, and other assistive tech what your components are and how they behave. Without ARIA, a screen reader sees a <div> with click handling and has no idea it's a button. It sees a <div> that appears on screen and can't tell if it's informational or requires immediate action.

The assumption that this is "the developer's job" is exactly why so many components fail accessibility testing. Developers can code the interaction. But they can't read your mind about what the interaction means. If your spec doesn't say "this is a navigation link" or "this dialog traps focus," developers default to whatever HTML they remember, and accessibility breaks.

You're already specifying everything else: interaction patterns, focus order, keyboard behavior. ARIA roles are just the last step that connects your design to assistive technology.

The roles you actually need to know

You'll encounter these eight roles regularly. Learn them, and you can spec accessible components.

Button vs Link

Your first decision: is this a navigation action or a behavior trigger?

A link (role="link") takes the user somewhere. A button (role="button") does something: submit a form, open a modal, delete a record, toggle a view.

The problem: designers often style navigation as button-looking elements, and developers don't know whether to use <a> or <button>. If you don't specify the role, screen reader users get confused. They'll try to treat a navigation link as an action, or expect a button to take them somewhere.

In Figma, label these clearly. If something visually looks like a button but navigates, write "role: link" in your annotation. If it looks like a link but triggers an action, write "role: button."

A dialog role wraps any modal overlay: error confirmations, forms, preferences panels.

Three things must happen: First, focus must trap inside the dialog. When the user tabs through all interactive elements, they loop back to the first one, never escaping into the background. Second, the dialog must have an accessible label via aria-labelledby, pointing to a heading or title inside it. Third, pressing Escape must close it.

Developers often miss focus trapping. If you don't spec it, screen readers will let users tab behind the modal into unreachable elements. Spec it explicitly: "Focus trap required. Dialog closes on Escape."

Alert and Alert Dialog

Not every warning is the same.

An alert is a passive message: a validation error that appears below a form field, a loading state, an informational notification. It doesn't require immediate action. The screen reader announces it, but focus doesn't move.

An alertdialog interrupts. It's a modal that demands attention: "Are you sure you want to delete this?" or "Your session is expiring in 30 seconds." Focus moves into the dialog, the user must respond, and they can't dismiss it by clicking outside.

When you're speccing error states, ask: does the user have to act on this right now? If yes, use alertdialog. If it's informational, use alert.

Screen reader users navigate by landmarks the same way sighted users scan a page visually. They jump from header to nav to main content to footer.

banner wraps your site header (logo, main nav)
navigation wraps any major navigation region (not every single nav, just the significant ones)
main wraps the primary content area
contentinfo wraps the footer

These aren't hard to implement. One per layout section. Your job: call them out in your spec. In Figma, label each major section with its landmark role. That's it. Developers handle the HTML; you've told them what goes where.

Tabs: Tablist, Tab, Tabpanel

Tabs are the most commonly misspecced pattern. Many designers treat them as cosmetic, but screen readers need to understand the relationship between the tab buttons and their panels.

The structure: a tablist container holds multiple tab buttons. Each tab has an aria-controls attribute pointing to its matching tabpanel. The active tab gets aria-selected="true".

Keyboard behavior: left and right arrow keys move between tabs, not Tab key. Tab key should move focus into the active panel. If you don't specify this, developers often implement tabs that fail keyboard navigation entirely.

Spec the full pattern in Figma. Show which tab is active. Make clear that arrow keys navigate tabs, not Tab key.

How to annotate ARIA roles in Figma

Create a dedicated annotation layer on each component. Use a simple, consistent format:

role: button
aria-label: "Close dialog"

Or for more complex patterns:

role: dialog
aria-labelledby: modal-title
focus-trap: yes
close-on-escape: yes

Write clearly. Developers should never have to ask what role or property something needs. If your annotations regularly fail to make it into builds, Why Your Figma Accessibility Annotations Aren't Reaching Developers covers what breaks between design and development.

For interactions that need specific behavior, add notes:

role: tab (in tablist)
aria-selected: true (when active)
Keyboard: arrow keys navigate, Tab enters panel

Include focus order for dialogs. Mark the first focusable element. Diagram the focus trap visually if the dialog is complex.

For landmarks, label each major section:

role: banner (site header)
role: navigation (main nav)
role: main (primary content)
role: contentinfo (footer)

The three mistakes designers make most often

1. Using button styles on links without speccing the role

You design something that looks like a button: rounded corners, solid background, white text. But it navigates to another page. You don't mention the role in your spec. The developer, seeing "button-looking element," codes a <button> with JavaScript navigation. Screen readers announce it as a button. Users expect it to trigger an action on the current page, not navigate away.

Spec: If it navigates, it's a link. If it triggers an action, it's a button. Write the role down.

2. Not labelling dialogs

A modal appears on screen. You don't include a visible heading, or you do but don't connect it to the dialog with aria-labelledby. Screen readers announce "dialog" with no description. The user has no idea what they're being asked.

Every dialog needs a label. Usually it's a visible heading. Point to it with aria-labelledby. If there's no space for a heading, use aria-label with a short description.

3. Skipping landmarks on layouts

You design a clean, minimal layout. You skip labeling sections as banner, navigation, main, footer. It's "obvious" where things are. But screen reader users can't see your clean design. Without landmarks, they have to listen to every element in order. What takes you 2 seconds to scan takes them 2 minutes to navigate.

Landmark roles cost nothing. Add them to your spec. They multiply usability for screen reader users.

What happens when you spec ARIA

When you include ARIA roles in your annotations, something changes. Developers get clarity. Components fail accessibility audits less often. Screen reader users can actually use the product.

You're not doing this to pass WCAG compliance. You're doing it because your design doesn't work if people can't perceive it. ARIA is how you tell assistive technology what you meant. Spend five minutes speccing roles. It works.