Understanding WAI ARIA with apples and elements

4 min readNov 22, 2021

WAI ARIA (Accessible Rich Internet Applications) is a W3C initiative that provides additional attributes for all HTML elements, allowing users with disabilities or those unable to use a mouse to interact with, understand, and navigate web content.

Before implementing these definitions, it’s important to consider the porpose of functionality or widget in question, its properties, and the states it can have based on user interactions.

To make this easier, let’s consider the example of a fruit: we could say that its purpose is to be a food, we can describe it as a red apple and that it is currently in a ripped state:

In the next example, the widget is a switch that activate something and has a checked state.

An switch image that shows role is equal to switch, its property is activate something and its state is checked — switch case

The three main concepts

As seen in the previous examples, these three concepts can give us an understanding of an object or element by identifying its purpose (role), its description (properties), and its cuurent condition (state). This is achieved through the use of ARIA attributes, which can be applied to any HTML element and provide this information to assistive technologies.

conceptual dependency tree (roles, properties and state). Role ¿What’s its purpose?, properties ¿How is it described?, State ¿What’s its current condition? — conceptual dependency tree (roles, properties and state)

ROLES: ¿ what’s its purpose?

Defines what is the component’s purpose in the ui. The available role types can be divided into three groups:

Structure (organizes content and provides context): heading, group, list, row, article. see more about of structure role
Widget (identifies elements that have interactions): button, alert, menu, link, slider, progressbar, tab, tabpanel, checkbox, tooltip. see more about of widget role
Landmark (defines relevant regions or areas of the page): main, search, banner, navigation, contentinfo, complementary, region. see more about of structure role

Example case: role=“search” define a set of elements that combined create a search functionality, therefore it is a role of type “landmark”.

<div role="search">
  <input name="user"  placeholder="enter user">
  <button>search</button>
</div>

demo: https://jsfiddle.net/suricastro/fvt4kbc5/

PROPERTIES: ¿ how is it describe?

Define attributes that help describe the component. The most commonly used properties are: aria-label, aria-live, aria-required, aria-autocomplete, aria-multiline, aria-readonly. see more about of properties

Example case: aria-required=“true” indicates that the field is required before the form can be submitted.

<div role="search">
  <input name="user" placeholder="enter user" aria-required="true">
  <button>submit</button>
</div>

demo: https://jsfiddle.net/suricastro/s42mnuek/

STATE: ¿ what is its current condition ?

Defines the current condition of the componente that can changes over time. The most commonly used states are : aria-checked, aria-disabled, aria-expanded, aria-hidden, aria-invalid, aria-pressed, aria-selected. see more about of states

Example case: aria-disabled=“true” indicates that the element is perceivable but disabled and therefore, not operable or editable.

<div role="search">
  <input name="user" placeholder="enter user">
  <button aria-disabled="true" disabled>search</button>
</div>

example of input with aria disabled attribute

demo: https://jsfiddle.net/suricastro/t9fz2o6s/

Implicit semantics

A lot of web content can be made accessible by simply ensuring that HTML elements are used for their intended purpose at all times. Proper semantics provide the necessary identification for assistive technologies natively.

This image shows how semantic tags are natively converted to roles, for example header tag is equal to use role banner

Finally…How does a screen reader read?

The way elements are read can vary based on inheritance, states, properties, and the assistive technology being used.

For example, when using the <button> element, it already has the implicit role of “button”, and when using <nav> it already has the implicit role of “navigation”, so it is redundant to apply them explicitly.

A screen reader will read the elements in this way:

aria-label (property) = Sign in to the site
button (implicit widget role) = button
aria-disabled (state) =disabled
nav (implicit landmark role) = navigation

It’s important to note that different screen readers may read the elements in different ways.

<nav>
  <button aria-label="Sign in to the site" aria-disabled="true">
    Sign in
  </button>
</nav>

The screen reader usually reads in this order: property, role, state, and landmark

More info:

Roles: https://www.w3.org/TR/wai-aria-1.0/roles

States and Properties: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques

Widget examples: https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex