> Markdown version of [/videos/801-aria-the-good-parts](https://www.wearedevelopers.com/videos/801-aria-the-good-parts). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # ARIA: the good parts Stop treating ARIA like an accessibility cure-all. It adds semantics, not behavior, so discover which attributes developers actually need to build truly inclusive interfaces. - **Speakers:** Hidde De Vries - **Event:** WeAreDevelopers LIVE - **Published:** November 3, 2023 - **Duration:** 55:32 - **URL:** https://www.wearedevelopers.com/videos/801-aria-the-good-parts ## Summary ARIA is frequently misunderstood by developers who treat it like an accessibility cure-all—or as a popular meme suggests, pouring an oversized bottle of ARIA "salad dressing" onto an otherwise inaccessible HTML "salad." In reality, ARIA is a powerful ontology designed to set and augment a webpage's accessibility meta information. When used correctly, it informs the browser's accessibility tree, directly shaping the interface for assistive technology users. However, a crucial caveat remains: "ARIA adds semantics but not behavior." Simply slapping a button role onto a standard div will not magically generate the necessary keyboard support, focus management, or interactive behavior required for genuine accessibility. The safest and most effective implementations of ARIA generally involve conveying visual states programmatically. Indispensable attributes include `aria-expanded` and `aria-pressed` for communicating active states on toggles, and `aria-current` to indicate active navigation items. Additionally, `aria-live` regions are pivotal for alerting users to asynchronous changes, such as session timeouts or shopping cart additions. Meanwhile, `aria-describedby` gracefully associates form input fields with their respective hints or error messages. While `aria-label` is a handy fallback for labeling visually silent icons, developers must be careful to avoid causing a mismatch between visual text and programmatic names, which immediately breaks voice-control navigation. The risks of ARIA scale rapidly alongside widget complexity. Building custom dropdown menus from scratch requires extensive JavaScript to handle roving tabindexes and complex key-press mappings—a notoriously difficult task to get right. Common ARIA pitfalls include conflicting DOM states (where an element programmaticly asserts it is open but is visually closed) and disappearing focus, which frustrates users by unpredictably resetting their cursor placement. Furthermore, developers should avoid using `role="application"` unless specifically intending to override native screen-reader shortcuts, and steer clear of `aria-roledescription`, which baffles users with unrecognized, bespoke control names. Ultimately, as modern browsers expose robust native features like the Popover API and the `<dialog>` element, prioritizing standard HTML over heavily "ARIA-bandaged" custom components remains the most reliable path to an accessible web. **Keywords:** accessibility meta information, browser accessibility tree, aria-expanded state, aria-pressed usage, aria-current attribute, aria-live notifications, aria-describedby patterns, accessible page landmarks, aria-label mismatch, roving tabindex, focus management strategies, custom widget accessibility, role="application" pitfalls, aria-roledescription warnings, native html components, popover api accessibility, assistive technology ui, screen reader navigation, keyboard accessibility constraints, ui state synchronization ## Chapters 1. **Exploring the purpose and misconceptions of ARIA** (00:02) — Why ARIA alone does not guarantee a more accessible web experience. 1. **How diverse users and assistive technologies navigate the web** (05:23) — Understanding the variety of user settings and assistive tools interacting with web interfaces. 1. **ARIA as an ontology for accessibility meta information** (09:25) — How ARIA defines standardized semantics through roles, states, and properties. 1. **Evaluating the good parts of ARIA and essential caveats** (14:19) — Why ARIA must be combined with standard accessibility practices like keyboard support. 1. **Structuring web pages effectively using ARIA landmarks for navigation** (16:26) — Highlighting key page sections without overwhelming users navigating through screen readers. 1. **Exposing visual states with ARIA expanded and pressed** (19:01) — Implementing state attributes to programmatically indicate toggled elements and visual changes. 1. **Labeling elements safely with ARIA labels and descriptions** (21:43) — Providing contextual names for interactive elements without overriding visible text. 1. **Managing dynamic states, live updates, and hidden content** (25:44) — Using specific attributes to communicate active states, interface updates, and redundant elements. 1. **The complexities and risks of building ARIA widgets** (29:37) — Why interactive custom widgets require rigorous state management and keyboard accessibility. 1. **Common pitfalls and misunderstanding complex standard accessibility guidance** (33:08) — Differentiating normative accessibility standards from non-normative authoring practices and recommendations. 1. **Addressing common ARIA implementation pitfalls on individual websites** (35:24) — Avoiding state conflicts, disappearing focus, and the misuse of complex ARIA roles. 1. **Key takeaways for responsible ARIA implementation on interfaces** (42:39) — Summary of why developers should use ARIA carefully alongside native HTML elements. 1. **Answering questions on frameworks, translations, and standard adoption** (43:38) — Audience questions covering framework behaviors, localization limits, and native HTML features. ## Related Moments - [Enhancing screen reader support with ARIA design patterns](https://www.wearedevelopers.com/videos/403-the-what-why-who-and-how-of-accessibility-on-the-web) (from "The What, Why, Who and How of accessibility on the web") - [Leveraging semantic HTML output tags and aria live regions](https://www.wearedevelopers.com/videos/1730-wearedevelopers-live-accessibility-isn-t-magic-longevity-devrel-in-times-of-ai-and-more) (from "WeAreDevelopers LIVE - Accessibility isn't magic, Longevity, Devrel in times of AI and more") - [Resolving default accessibility limitations in custom web components](https://www.wearedevelopers.com/videos/648-accessibility-with-web-components) (from "Accessibility with Web Components") - [Enhancing screen reader support with targeted ARIA attributes](https://www.wearedevelopers.com/videos/1671-oh-s-there-s-a-new-accessibility-law-and-i-m-not-ready) (from "Oh S***! There's a New Accessibility Law and I'm Not Ready!") - [Understanding aria toggle fields and missing accessible names](https://www.wearedevelopers.com/videos/2077-accessibility-features-in-chrome-devtools-and-beyond) (from "Accessibility Features in Chrome DevTools and beyond") - [Prioritizing semantic html over custom aria attribute implementations](https://www.wearedevelopers.com/videos/2077-accessibility-features-in-chrome-devtools-and-beyond) (from "Accessibility Features in Chrome DevTools and beyond") ## Related Articles - [The State of Accessibility on the Web in 2025: WebAIM Million Report Findings](https://www.wearedevelopers.com/magazine/570-the-state-of-accessibility-on-the-web-in-2025-webaim-million-report-findings) - [3 JavaScript-Free Techniques for Accordions, Dialogs, and Table of Contents](https://www.wearedevelopers.com/magazine/684-3-javascript-free-techniques-for-accordions-dialogs-and-table-of-contents) - [The Web We Broke (And Why AI Agents Are Paying the Price) - AgentCon Berlin](https://www.wearedevelopers.com/magazine/735-the-web-we-broke-and-why-ai-agents-are-paying-the-price-agentcon-berlin) - [How Developers Can Focus on Maintaining Satisfaction With Accessibility](https://www.wearedevelopers.com/magazine/109-how-developers-can-focus-on-maintaining-satisfaction-with-accessibility) ## Related Jobs - [AI Full Stack Engineer](https://www.wearedevelopers.com/jobs/ext/1354435-ai-full-stack-engineer) at **Almedia** - [Senior Product UI Designer](https://www.wearedevelopers.com/jobs/ext/1998621-senior-product-ui-designer) at **Almedia** - [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.** - [Staff Developer Advocate, GitHub Security Lab](https://www.wearedevelopers.com/jobs/ext/1921051-staff-developer-advocate-github-security-lab) at **GitHub** - [AI Software Engineer (Germany)](https://www.wearedevelopers.com/jobs/48317-ai-software-engineer-germany) at **Sunhat** - [AI Operations Manager (all genders)](https://www.wearedevelopers.com/jobs/48263-ai-operations-manager-all-genders) at **envelio**