Webpages and applications are designed to solve all different tasks. They need to give web developers the creativity and ability to solve all different types of problems, while still being intuitive and accessible for web users. This becomes more of a challenge, however, if you use the web differently than others. If, for example, you use a screen reader instead of a visual display, the construction behind the page becomes much more important than the appearance. This is where Accessible Rich Internet Applications (ARIA) come in. In this blog post, we’ll explain the basics of ARIA for web accessibility.

How to Use ARIA for Web Accessibility

WAI-ARIA Basics

WAI-ARIA was developed by the Web Accessibility Initiative (WAI), part of the World Wide Web Consortium (W3C). WAI-ARIA, or ARIA for short, is a set of markup extensions which are meant to provide additional description or meaning to elements within a site or application. ARIA attributes are used in websites, blogs, games, social media, and much more.

Not all websites use or need to use ARIA attributes to be accessible. In fact, ARIA attributes are intended to be used only when a part or function of a site is difficult to use or unclear with a screen reader or assistive technology. Many of the most common elements you’ll see in modern websites today are already accessible, and don’t need additional ARIA attributes. However, if you have tested your site and it isn’t accessible, ARIA may offer solutions to fix it.

Since the web is so vast and there are so many different ways that information and content may be displayed, ARIA must be versatile, with the ability to solve many different accessibility issues. To help organize ARIA solutions, they are mainly divided into three subsections: roles, states, and properties.

ARIA Roles

ARIA roles are described using role= in your website code. For example, the navigation menu of your site might use role="navigation", or a search bar might use role="search". To users looking at your site, nothing changes by using an ARIA role; all elements function the same way. To users with assistive technology, however, roles can provide extra meaning and usability. Roles allow a screen reader to easily convey what an element is supposed to do and what it means.

  • Landmark roles: these help users navigate websites more easily when using screen readers and other assistive technology. These include role="navigation", used to highlight groups of links used to click around the site, or role="form" for showing where a user might input information.
  • Widget roles: these provide more clarity about what a part of the website is supposed to do. One widget role is role="button", which shows what an element is and when it should be clicked. Another is role="progressbar", which shows that an element is displaying the progress of a task.
  • Live region roles: these show that an element is dynamic and changes based on certain criteria. For example, role="alert" triggers a message, like error messages. Another is role="timer", which might show that a user has a limited time before being automatically logged out.

ARIA Properties

While roles describe what an element does, ARIA properties describe more about what the element is. Properties and roles are often used together. Most of the time, ARIA properties do not change as a user clicks or interacts with a site, while ARIA states do. Since they are used in similar ways, ARIA states and properties are often collectively called ARIA attributes. Here are some common ARIA properties:

  • Widget properties: these generally describe one part of a widget and give it additional meaning. For example, aria-required="true" used with an input element would indicate that the element must be filled in to continue.
  • Live region properties: these describe how live regions in a site update and how a screen reader interacts with them. For example, aria-live="polite" would inform the user that the live region has changed but would not interrupt a task, while aria-live="assertive" would be used only for essential live updates.
  • Relationship properties: these describe when two or more elements share an important relationship, such as labels, controls, or descriptions. For example, aria-labelledby used with a form input would clearly show a screen reader and a user what the input is.

ARIA States

ARIA states are very similar to properties. The key difference is that ARIA states indicate change. ARIA states are most useful with live regions or with alerts.

  • Widget states: very similar to widget properties, except they can be changed with a user’s action. For example, aria-expanded="true" would show that a box, tree, or table is expandable, and the current state is expanded.
  • Live region states: used in conjunction with live region properties to show users what these parts of websites are doing. The state aria-busy="true" shows that an area is in the process of updating.

ARIA is meant to make your site more accessible and help you overcome accessibility obstacles. Some ARIA attributes are easy to implement, while others require more coding knowledge. Remember that ARIA is meant to help your web accessibility, and you may not need it. If you have an accessibility issue that is restricting important content or functionality from your site, a web developer may be the best option to help you find the right solution with ARIA tags.