Semantics

ARIA provide an AUTHOR three ways to communicate semantic information to assistive technology:

  1. ROLES – defines a component’s purpose to describe the type of widget (e.g., menu, slider, etc.) and the structure of the Web page (e.g., heading, button)
  2. STATES – defines a component’s current condition (e.g., enabled/disabled, collapsed/expanded)
  3. PROPERTIES – defines a component’s characteristics. (e.g., attribute or data value of an object). Properties can also be used for drag-and-drop operations that describe drag sources and drop targets

BOTTOM LINE: Since ARIA is used to communicate semantics (roles, states, and properties) to assistive devices, when native HTML semantics (roles, states, and properties) aren’t enough, then ARIA can be used.

STATES and PROPERTIES – provide INFORMATION about a HTML object (element) to an assistive device to help users understand how to interact with that object by revealing relationships and states to a screen reader. States and properties can also help to declare the content as an application instead of a set of static pages. These states and properties are often changed during the lifecycle via JavaScript.

NOTE: Semantic HTML elements (e.g., button, nav) have roles assigned to them by default that shade light on their purpose. However, there are times when you need to use non-semantic elements (e.g., <div>, <span>) to create a custom control the won't have a default role that reflects its purpose. ARIA can be used to provide the needed roles and other information to the browserr accessiblity API to create an accessiblity tree similar to the DOM tree. Assistive technology devices (e.g., screen readers) uses the information in the accessibility tree to determine what's on the page and how to interact with them.
IMPORTANT NOTE: A screen reader will announce an element's role, name, state, and value. For example, a screen reader like JAWS will announce:

ARIA Roles

Just like in many role-playing games, ARIA also has the concept of role-playing.  The role attribute defines a specific role for type of object (e.g., article, alert, slider, and button)

REAL LIFE SCENARIO: A role is used to define what you want something to BE, not what it really IS.

Unlike states and properties that can change over time (VERIFY THIS STATEMENT), a role value should not change over time. For example, if an element is assigned a role of a button, it should always be a button. If you want to change the role, REMOVE the element and its descendants and REPLACE it with a new element with new descendants with a new role.

ARIA’s roles enable a developer to classify an otherwise meaningless element to a more useful semantic element that can be understood by assistive technology by revealing its functionality (e.g., this is a button).

There are four major ARIA role categories:

  1. Abstract - used to define general ARIA role concepts. They are the fundamental building blocks for all other roles. Because that are used by browsers, an author will never use them. (e.g., command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, and window)
  2. Widget - used for UI widgets as standalone elements or composites:
    • Composite - acts as a container for other widgets (e.g., combobox, grid, listbox, menu, menubar, radiogroup, tablist, tree, and treegrid)
    • Standalone - is used as a "stand alone" component or INSIDE a composite widget (e.g., alert, progressbar, timer)
  3. Document Structure - used to add organize content to a page and are not usually interactive (e.g., sections)
  4. Landmark - used to create navigational page regions:
    • Application - used to defined the content as an "application"
    • Banner - contains the header information
    • Complimentary - contains information relevant to the main topic, but still meaningful when separated from the main topic.
    • Contentinfo - contains child content (e.g., footnote, copyright, privacy statement links).
    • Form - contains a collection of form elements (e.g., text fields, combobox, radio button, etc.).
    • Main - contains the main document content.
    • Navigation - contains a collection of navigational elements (e.g., buttons, links).
    • Search - contains a search form.
NOTE: Except for banner, contentinfo and main, all other landmarks can be used multiple times on a page. (VERIFY THIS STATEMENT)

Live Regions

In the past, screen readers could not discover updated content on a page if the page was not reloaded. ARIA’s live regions solve this problem by notifying assistive technology whenever a change in made to a portion of a page. ARIA live region allows a change to be announced to an assistive technology WITHOUT changing focus.

A live region is a region of a page that may be updated (e.g., weather, stock ticker) because of an external event when user focus may be somewhere else on the page that may or may not be the result of a user interaction. ARIA includes a set of properties (e.g., aria-live, aria-relevant, aria-atomic, and aria-busy) that helps to report these changes to assistive technology that would otherwise go unnoticed. (See Examples menu for detail examples)

ARIA live regions also support an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page. With live regions:

NOTE: Some roles have built-in live regions (e.g., alerts, timers, log, marquee, and status).

EXAMPLE VIDEO ON LIVE REGION: http://zomigi.com/blog/videos-of-screen-readers-using-aria-updated/
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

Landmarks

Just like you use landmarks (e.g., a building, a sign) to help you remember a particular location when you are going some where, ARIA uses landmarks as well. ARIA’s landmarks are page regions that can be used to provide quick access by a user. ARIA landmarks allow:

NOTES: