Five New ARIA 1.3 Attributes Face Uneven Screen Reader Support

WebAIM's May 2025 review of ARIA 1.3 tested five emerging attributes across JAWS, NVDA, VoiceOver, and TalkBack, and the support map came back lopsided. A screen reader user trying to recover from an invalid email field shouldn't have to wait through a paragraph of helper text to hear what went wrong — and that's the specific problem aria-errormessage was built to solve.

WebAIM, a Utah-based accessibility nonprofit, ran its evaluation across Windows 11 (JAWS, NVDA, and Narrator in Chrome, Firefox, and Edge), macOS Sequoia (VoiceOver in Safari, Chrome, and Firefox), iOS 18.4 (VoiceOver in Safari), and Android 15 (TalkBack 15.2 in Chrome). The verdict, in their framing, is "infrastructure stage": well-defined and ready in theory, uneven in practice.

What does aria-errormessage actually change?

The attribute attaches a custom error message to a form field that announces only when aria-invalid="true" is present. Unlike aria-describedby, which fires regardless of validation state, this one is purpose-built for error feedback. WebAIM found support strong across JAWS, NVDA, and iOS VoiceOver — and limited elsewhere. For a developer shipping a checkout flow, the takeaway is concrete: use it where the support holds, keep aria-describedby as the fallback for the rest.

How does aria-placeholder differ from the HTML placeholder?

The HTML placeholder attribute can leak into screen reader output even after a user has typed content — a small but persistent annoyance. aria-placeholder reads the prompt to the screen reader without leaving visible text behind, which makes it ideal for div[contenteditable] widgets that mimic form fields. WebAIM calls support "surprisingly consistent" across JAWS, NVDA, VoiceOver, and TalkBack — rare praise for an attribute that didn't exist in 2014.

What about aria-description and aria-details?

These two are the most uneven. aria-description provides a programmatic supplement for content that isn't visible on screen — a breadcrumb trail with aria-description="You are here:" offers orientation without cluttering the visual layout. Support is limited to NVDA and iOS VoiceOver today.

aria-details, conceived as a modern replacement for the long-defunct longdesc attribute, points to supplementary content like the data table behind a visualization. The catch: WebAIM found there is currently "no way to access the details element directly from the element that references it." It's effectively a placeholder for future capability rather than a production-ready feature.

Are any of the new roles worth using?

Three editorial-friendly roles caught the reviewer's attention:

• role="mark" for highlighted text
• role="comment" for user-generated feedback
• role="suggestion" for proposed content changes

role="mark" is catching on — it's semantically equivalent to the native <mark> element. role="comment" and role="suggestion" are still finding their footing inside collaborative editing tools.

Two more, role="code" and role="time", mirror native semantics for component-based systems where the HTML tags aren't practical. role="image" is a synonym for role="img" — a readability convenience, not a behavioral change.

Where does this leave accessibility teams?

For teams shipping production interfaces, the calculus is straightforward: deploy the newer features when they add real value and degrade gracefully, then test across multiple environments before relying on them. A companion demo at webaim.org/presentations/2025/examples/up-and-coming-aria offers working markup for each attribute. As browser and screen reader vendors work through their backlogs, the best practices will be written by the teams that started experimenting first.

By James Calloway