When should I use ARIA?

Reach for ARIA when semantic HTML cannot describe what your component does. Custom tabs, modals, and carousels without native equivalents need it, as do dynamic regions that should announce updates. Native HTML is always the first choice, and ARIA fills the gap only when nothing else fits.

What's the first rule of ARIA?

Avoid ARIA when you can. A real button outperforms a div carrying role=button on accessibility, performance, and maintenance, and a real nav element handles its job better than a div with role=navigation. Reach for ARIA only when native HTML genuinely cannot describe the widget you are building.

Landmarks are top-level page regions like banner, navigation, main, contentinfo, search, and form. Screen reader users jump between them to orient themselves quickly. The HTML5 elements header, nav, main, and footer imply the matching landmark roles automatically, so you rarely need to add ARIA on top of them in modern browsers.

What are ARIA states vs properties?

Properties tend to be structural and stable, like aria-label and aria-labelledby naming an element. States change as the user interacts, like aria-expanded flipping when a disclosure opens or aria-pressed tracking a toggle button. Both share the aria- prefix, but mixing up which is which leads to subtle bugs.

Should I add aria-label to everything?

No. Most elements get their accessible name from the native HTML, so a button containing the word Submit already announces correctly without any extra attribute. Add aria-label only when the visual label is missing or when you need a different name specifically for screen readers.

How do I test ARIA usage?

Test with the actual screen readers your users have, including NVDA on Windows (free), JAWS on Windows (paid), VoiceOver on Mac and iOS (built-in), and TalkBack on Android (built-in). Automated checkers like axe and Wave catch syntax issues, but only running through the page with assistive tech reveals whether the experience actually works.

Is the data sent anywhere?

No. The reference is a predefined database that ships with the tool, and lookups happen entirely on the client without any server queries.

ARIA Role Reference

Interactive ARIA roles and attributes reference with usage examples, required properties, and browser support. Free accessibility guide.

Web & SEO Developer Tools

Instant results

Showing 68 of 68 roles

Widget Roles(31)

Interactive UI elements like buttons, checkboxes, sliders, and dialogs

Document Structure Roles(21)

Structural elements for organizing content like headings, lists, and tables

Landmark Roles(8)

Major page sections that help assistive technology navigate the page

Live Region Roles(6)

Regions that dynamically update and can announce changes to screen readers

Window / Application Roles(2)

Application-level roles for complex interactive widgets

About ARIA Role Reference

Comprehensive reference for WAI-ARIA roles covering 68 roles across 5 categories: Widget, Document Structure, Landmark, Live Region, and Window roles. Each entry includes required/supported attributes, HTML equivalents, and copy-ready code examples. Based on the WAI-ARIA 1.2 specification.

How to Use ARIA Role Reference

Search by role or scenario

Look up a specific role like tab or dialog, or describe the scenario in plain language such as making a modal accessible. The reference picks up either form and surfaces the relevant entries.

View the role details

Each entry covers the role name and purpose, the attributes that are strictly required, the related properties and states that frequently accompany it, and short examples showing the markup in context.

Apply the pattern to your code

Drop the appropriate roles and attributes into your HTML where they fit, keeping the native element when one exists. Verify behavior afterwards by running through the component with a real screen reader.

Reference the comprehensive guide

For composite widgets like grids, comboboxes, and treeviews, consult the WAI-ARIA Authoring Practices Guide. The reference here covers the basics, while the APG remains the definitive resource for keyboard interaction and detailed patterns.

When to Use ARIA Role Reference

Web accessibility implementation

ARIA attributes describe roles, properties, and states to screen readers and other assistive tech. Developers building components that go beyond native HTML rely on this reference to find the right role plus its required attributes without paging through the full specification.

Custom widget accessibility

Modals, tabs, accordions, and dropdowns are invisible as structured widgets unless ARIA tells assistive tech what they are. Looking up the recommended role pattern saves hours compared with reverse-engineering it from the spec.

Accessibility audit and review

During code review, the reference helps verify that roles are applied correctly and that the required companion attributes are present. Auditors use it to confirm a component meets compliance targets without combing through MDN tabs.

Education and learning

Anyone new to ARIA can browse the reference to see how role categories fit together. Trainers point students toward the role descriptions and examples as a faster on-ramp than reading the W3C document end to end.

ARIA Role Reference Examples

Common roles

Input

A scan of the everyday roles most apps need

Output

button for interactive controls, link for navigation, navigation for the nav landmark, main for primary content, banner for the header, contentinfo for the footer, search for search regions, form for forms, and region for named sections

These nine cover the bulk of typical web applications. Each role carries a specific accessibility meaning that helps screen reader users orient themselves on the page.

Custom widget role

Input

A tab interface implementation

Output

role=tablist on the container, role=tab on each tab, and role=tabpanel on each panel, tied together with aria-selected, aria-controls, and aria-labelledby

Composite widgets require coordinating roles with relational attributes so the user can navigate between tabs with the arrow keys and hear the right announcements when each panel becomes visible.

Properties versus states

Input

A comparison of structural attributes against dynamic ones

Output

Properties like aria-label, aria-labelledby, and aria-describedby name and describe elements; states like aria-expanded, aria-pressed, and aria-selected reflect the current condition

Properties tend to stay constant once set, while states change as the user interacts with the page. The reference distinguishes them so authors update the right one at the right moment.

Tips & Best Practices for ARIA Role Reference

1.The first rule of ARIA is to avoid ARIA when native HTML can do the job. A real button outperforms a div with role=button on accessibility, performance, and maintainability.
2.Pick a role that matches the actual behavior. Slapping role=button on a link confuses keyboard users, and role=alert on static text triggers spurious announcements.
3.Some roles demand specific companion attributes. role=dialog requires either aria-labelledby pointing to a heading or aria-label as a fallback, otherwise screen readers cannot announce the dialog properly.
4.Automated tools verify ARIA syntax but not usability. Test with real screen readers like NVDA, JAWS, or VoiceOver to learn how the attributes actually sound to users.
5.Distinguish properties from states deliberately. aria-expanded flips on every disclosure click, while aria-label rarely changes once set, and using the wrong category sows bugs.
6.For composite widgets like trees, grids, and combo boxes, follow the WAI-ARIA Authoring Practices Guide patterns rather than improvising. The APG covers keyboard interaction in detail that this reference cannot match.

Frequently Asked Questions

ARIA stands for Accessible Rich Internet Applications, a W3C specification that exposes roles, properties, and states to assistive tech like screen readers. The attributes layer over HTML to describe behavior the markup alone cannot convey, which matters most for dynamic content, custom widgets, and anything that goes beyond standard form controls.

ARIA Role Reference

Widget Roles(31)

Document Structure Roles(21)

Landmark Roles(8)

Live Region Roles(6)

Window / Application Roles(2)

About ARIA Role Reference

How to Use ARIA Role Reference

Search by role or scenario

View the role details

Apply the pattern to your code

Reference the comprehensive guide

When to Use ARIA Role Reference

Web accessibility implementation

Custom widget accessibility

Accessibility audit and review

Education and learning

ARIA Role Reference Examples

Common roles

Custom widget role

Properties versus states

Tips & Best Practices for ARIA Role Reference

Frequently Asked Questions

Related Tools

Robots.txt Generator

Sitemap Generator

.htaccess Generator

User Agent Parser

URL Parser

HTML Viewer