You probably wont notice it, but Drupal 8 comes packed with WAI-ARIA markup to ensure that your pages are as semantically correct as they can be out of the box. Who will notice it though is blind users who rely on additional meaning to be hard coded into the HTML of the site, rather than inferred from the visual cues on the page.

Let’s say you’ve got an employee named Jim who needs to navigate your Intranet site like all of your other employees. Jim’s legally blind, and the open-source screen reader NVDA to help him with his work. Jim, just wants to get to today’s tasks and doesn’t know anything about ARIA roles, properties, and states but his screen reader does. Let’s look at what these things do exactly and how Jim would benefit from them.
 

Roles

ARIA Roles are the main indicator of the type of element. This allows accessibility tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type. For instance, <role=”main”> would indicate the main content of a page, such as an article tag would in HTML5. The great thing about Drupal 8 is these ARIA landmark roles are applied by default to Drupal 8 Core.

With the default themes in Drupal Core, Jim will be able to easily navigate between the header (banner), footer, and navigational elements of the site. He’ll also be able to quickly jump between the main body of the page and the search page.  Jim will also be able to get a sense of the structure of the page because Drupal still comes with a default heading hierarchy (H1 to H6) which can also help Jim navigate. You can find more information on the wide variety of roles on Drupal.org.

Properties and States

Both properties and states are similar in that they are both markup attributes and provide specific information about an object. The chief difference between the two, is that a property’s value isn’t likely to change (aria-labelledby). Whereas a state (aria-checked) will change depending on user input.

Examples of Properties:
aria-required="true", aria-live, aria-label, aria-labelledby, aria-describedby

Examples of States:
aria-disabled="true", aria-hidden (state), aria-invalid (state)

Drupal 8 includes these attributes along with roles in Drupal Core. For example, aria-sort was added to tables to add additional context and aria-describedby links were added to form elements to reference related descriptions. These two additions would allow Jim to understand what sort order the tables are in and what the purpose of a button or input element is.
The great thing about the Drupal community is that they are constantly looking into resolving Drupal issues of varying levels. And in Drupal 8, accessibility is at the forefront. One such example was adding role="group" to <figure> (5) to meet WCAG requirements.

One more thing. You may not think it, but having ARIA markup within Drupal does help with search engine optimization. HTML5 is semantic in nature and including AIRA markup just further enhances the readability and accessibility of content for more web users. Jim will visit a webpage on his screen reader and it completely understand all of the elements. Thus, he’s more likely keeping him on the site and reading other sections.

These elements are just included when forms are built with the Form API in Drupal. So without developing for accessibility web developers will be adding semantic relationships to their webforms simply by building the webforms that they need with Drupal. If you're interested in seeing a list of WAI-ARIA related issues in Drupal.

With all this in mind, you can see all the accessibility advantage that Jim gains from having the ARIA tools included in Drupal 8 Core.

See more about this series on Drupal 8.