The aria-description attribute and why you should avoid using it | by Daniel Berryhill | Feb, 2024
Whenever something new comes along, eager (and even well-meaning) developers may be quick to implement without reading the fine print. Now that new ARIA roles and attributes are part of the First Public Working Draft of WAI-ARIA 1.3, caution is warranted.
This article will cover the new
aria-description attribute — and why you should avoid using it, if you can.
WAI-ARIA is short for Web Accessibility Initiative — Accessible Rich Internet Applications. The ARIA Working Group provides a set of recommendations for web browsers and developers “to enhance the accessibility of web content through the development of supplemental attributes, including roles, states, and other properties, that can be applied to native host language elements and exposed via platform accessibility APIs.” (Source)
In late January 2024 (just a few weeks before the writing of this article), the ARIA Working Group released its First Public Working Draft of WAI-ARIA 1.3.
It’s still a few steps away from becoming the W3C Recommendation, but it likely won’t take as long as it takes WCAG to go through the process.
Keep in mind that although
aria-description will most certainly be included in the final recommendation, it is likely that changes will be made to WAI-ARIA 1.3 before completion.
A quick word about ARIA attributes
Before we get into
aria-description, we need to cover some important points about ARIA attributes.
- ARIA attributes should only be used when native HTML elements cannot be.
- ARIA attributes only change how content is consumed by assistive technology (AT). They make no visual or functional changes to a page for a non-AT user.
- If you’re not sure how to use ARIA attributes, don’t use them. As the ARIA Authoring Practices Guide states: