Purpose of ARIA is Describe Semantics and Behavior

Provide an inter-operable way to describe the features of custom widgets:
- Role: Describes the type of widget, which implies the keyboard interaction.
- Properties and States: Describing features like "expandable", "checked" or "selected".
- Language independence: Roles, properties and states can be translated by the operating systems and assistive technologies to local languages.
- Labeling: How to label the features of the widget and its components (e.g. accessible name).
- Relationships: How different components relate to each other (e.g. descriptions, controls, owns).
- Grouping: Groups of related components (e.g. lists, menus, trees, tab panels).
Define markup mappings to accessibility APIs:
- ATK/AT-SPI (Linux/Unix)
- Microsoft Active Accessibility (MSAA) + IAccessible2
- Microsoft UI Automate
- MacOS Accessibility API

Audio Transcript

The basic purpose of aria which is to describe the semantics and behavior of webpages that does this in several ways. Some of the important terms you will learn about today include: The most basic feature of ARIA is the role attribute which describes to users of screen readers the type of keyboard interaction and the potential properties and states of a custom widget. When people first look at the aria specification, they see all of these familiar roles like “menu”, “tab panel”, “dialog” and “navigation”. They start looking around their webpage and feel that I have these things in my webpage and they start sprinkling the roles throughout their webpage thinking that’ll be more accessible. Actually the page will be less accessible, since the keyboard interaction associated with these roles most likely is not supported. Using roles that do not actually describe the behavior of a widget is analogous to someone opening up a door to what they think is a bathroom, stepping in and falling into a swimming pool. The screen reader user will be disoriented. For example, you use a “menu” role, but it is just a list of tab-able links, the cursor keys don’t work you just pushed the user into the pool. Properties and states attributes communicate information about a widget being expanded, or if can open a pop-up menu, or a checkbox being checked or unchecked, more on that later. An important feature that is often not understood about using ARIA roles, properties and states is that the translation of this information to local languages is handled by the browser and operating system. This is an important feature when websites are used by people from all around the world. Widgets and many structural roles need a label or accessible name. ARIA defines how the accessible name is calculated. For example, a role of “textbox” tells the user they can enter text, but the label “name” tells them this textbox is for entering your name. There are other features for describing relationships between widgets and to identify groups of related content or controls. When relationships and grouping are properly used screen readers can provide navigation features to allow users to more efficiently ignore and find content of interest to them. When not properly used pages become more confusing and difficult to navigate. The primary adage for people to developers not familiar with ARIA is “No ARIA is better than bad ARIA”. ARIA does not directly interact with assistive technologies like screen readers. ARIA only controls how information about a web page is communicate to screen readers through operating system accessibility APIs. The current ARIA specification provides accessibility API mappings for ATK/AT-SPI (Linux/Unix), Microsoft Active Accessibility (MSAA) + IAccessible2 for Windows 10, Microsoft UI Automate for Windows 10 and the MacOS Accessibility API.