When implemented correctly, ARIA labels help assistive technologies interpret and convey the role and description of interface elements to users. For example, a screen reader might use the aria-label attribute to announce what an unlabeled button does, such as “Submit” or “Close Menu.” Similarly, the aria-labelledby attribute links an element to existing text on the page, effectively using that text as the element’s label.
Consider the following example:
<buttonaria-label="Submit Form">Submit</button>
Here, the aria-label attribute explicitly describes the purpose of the button to users who rely on assistive technologies.
Alternatively, using aria-labelledby might look like this:
Here are some examples of ARIA labels in action. In all of the examples, the primary emphasis is on using native HTML elements, like <button>, <label>, and <input>.
ARIA labels should only be used when necessary, especially when native HTML elements lack semantic meaning or when additional clarification is needed. This approach ensures that the site is still functional and accessible even without relying solely on ARIA.
This example shows a button designed to close a window or modal. The aria-label="Close" attribute is used to provide a clear, descriptive label for screen readers, as the button only contains an icon (×). The aria-hidden="true" on the <span> ensures that the icon itself is not announced to screen readers, preventing redundancy. By using the native <button> element, this remains semantically correct, and the ARIA label provides additional clarity for users with visual impairments who rely on screen readers.
For screen reader users, the ARIA label “Close” makes it clear what the button does, as they cannot see the icon.
For sighted users, it is visually represented by the icon.
<divrole="region"aria-live="polite"><p>Your order has been successfully placed!</p></div>
Here, a div with role="region" and aria-live="polite" is used to notify users of a successful order. The aria-live attribute with the value “polite” ensures that the message is announced by screen readers at an appropriate time without interrupting ongoing tasks.
For screen reader users, the announcement of updates to the content helps them stay informed about changes without having to actively check for them.
For all users, the use of a live region is especially useful for those who may rely on assistive technology to stay informed about changes in the application.
In this example, a native <label> is used to associate the text “Email Address” with the <input> element. The aria-label="Email address input field" is added to provide further context to screen reader users in case the label is not adequately read or if it’s in a complex form. The label itself should always be the primary method for indicating form fields, as it’s native HTML.
Screen reader users benefit from both the label association and the ARIA label providing additional clarity. For instance, if the label was hidden or not visible, the ARIA label would still ensure the field’s purpose is conveyed.
Sighted users can see the label directly, while assistive technology ensures the correct function for those who need it.
While ARIA labels are incredibly useful, their misuse can lead to confusion and hinder accessibility. Here are some best practices:
Use Native HTML First: Whenever possible, rely on native HTML elements, which are inherently accessible. Use ARIA as a supplement rather than a replacement.
Keep Labels Concise and Clear: Ensure that ARIA labels are succinct and accurately describe the purpose of the element.
Avoid Redundancy: Do not use ARIA attributes if the information is already provided by native HTML elements.
Test with Assistive Technologies: Always test your application with screen readers and other assistive tools to ensure labels are being read as intended.
By providing descriptive information for interactive elements, ARIA labels ensure that users with disabilities can interact with web content effectively. As web developers, it is our responsibility to prioritize accessibility and leverage tools like ARIA to create digital experiences that are accessible to all.
By adhering to these best practices and testing implementations using accessibility testing tools and validators, we can make significant strides in achieving a more inclusive web.
Most common questions and brief, easy-to-understand answers on the topic:
What are ARIA labels and why are they important?
ARIA (Accessible Rich Internet Applications) labels are HTML attributes that provide descriptive information about web elements, ensuring users with disabilities can understand their purpose. They are essential for improving accessibility, especially for dynamic elements like buttons, forms, or custom widgets, making the web more inclusive for everyone, including those with visual, motor, or cognitive impairments.
When should I use ARIA labels instead of native HTML elements?
ARIA labels should only be used when native HTML elements lack semantic meaning or when they need additional clarification. It is important to prioritize native HTML elements first, as they are inherently accessible. ARIA should supplement, not replace, standard HTML elements, such as using aria-label for icons or aria-live for dynamically updated content.
What’s the difference between aria-label and aria-labelledby?
aria-label provides a direct textual description for an element, while aria-labelledby references the id of another element whose text serves as the label. Use aria-labelledby when the label text already exists elsewhere on the page, and use aria-label for custom, direct descriptions when no visible label is available.
Jonas works as project manager, web designer and developer since 2001. On top of that, his areas of expertise are in user experience, accessibility, internationalization, and domain names. See: https://www.j15k.com/
This license requires that reusers give credit to the creator. It allows reusers to distribute, remix, adapt, and build upon the material in any medium or format, for noncommercial purposes only. To give credit, provide a link back to the original source, the author, and the license e.g. like this:
<p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://www.uxgem.com/articles/introduction-to-aria-labels">Introduction to ARIA (Accessible Rich Internet Applications) Labels</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://www.j15k.com/">Jonas Jared Jacek</a> is licensed under <a href="https://creativecommons.org/licenses/by-sa/4.0/" target="_blank" rel="license noopener noreferrer">CC BY-SA 4.0</a>.</p>