Web Accessibility — ARIA

Accessible Rich Internet Applications

In today’s world of web where accessibility is one key factor to consider, it very helpful to be familiar with some tools and tips to achieve this. In this article, I will be talking about the aria-* attributes and how it helps web accessibility.

https://www.dhark.com/acc101_aria.html

What is ARIA?

ARIA (WAI-ARIA if you want to be formal)is a set of attributes that you can add to HTML elements. These attributes communicate role, state, and property semantics to assistive technologies via the accessibility APIs implemented in browsers.

The W3C HTML specification provides information about which ARIA attributes are allowed to be used on each HTML element in section 3.2.7 WAI-ARIA. — wikipedia.

Generally, ARIA is a set of attribute that helps make websites to be more accessible to assistive technologies such as Screen readers e.t.c. used by people with some form of disability, especially sight as It aids in their interaction with websites.

ARIA attributes are divided into two categories:

• Roles
• States & Properties.

ARIA roles

This is added by using the role="<ROLE_TYPE>" attribute

Categories of ARIA roles include:

• Landmarks
• Documents
• Widgets
• Abstract — This is the basics of how other ARIA roles are defined. They can not be used in HTML.

Landmark

This helps us provide a better way for users of assistive technologies to navigate and identify the different part of the website.

A use-case is this:

<nav role="navigation" class="navbar nav" id="main-nav">...</nav>

Here we notice that the role is set as navigation and helps screen readers know that is part of the website is for navigation.

Landmarks roles also include:

• Banner: A region that contains the prime heading or internal title of a page.
• Complementary: Any section of the document that supports the main content, yet is separate and meaningful on its own.
• Contentinfo: A region that contains information about the parent document such as copyrights and links to privacy statements.
• Form: A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.
• Main: Main content in a document. In almost all cases a page will have only one role=“main”.
• Navigation: A collection of links suitable for use when navigating the document or related documents.
• Search: The search tool of a Web document.
• Application: A region declared as a web application, as opposed to a web document. (note: The role of application should only be used with caution because it gives a signal to screen reading software to turn off normal web navigation controls.

Simple widgets should generally not be given the application role, nor should an entire web page be given the application role, unless it is not to be used at all like a web page, and not without much user testing with assistive technology.)

Document

Unlike Landmark which describes the structure of the page, Document describes the structure of the content of the pages.

Documents roles also include:

• Article
• Columnheader
• Definition
• Directory
• Document
• Group
• Heading
• Img
• List
• Listitem
• Math
• Note
• Presentation
• Region
• Row
• Rowgroup
• Rowheader
• Separator
• Toolbar

Widgets

Widgets are used to describe the javascript-based component of the website.

Its roles include:

• Alert
• Alertdialog
• Button
• Checkbox
• Dialo
• Gridcell
• Link
• Log
• Marquee
• Menuitem
• Menuitemcheckbox
• Menuitemradio
• Option
• Progressbar
• Radio
• Scrollbar
• Slider
• Spinbutton
• Status
• Tab
• Tabpanel
• Textbox
• Timer
• Tooltip
• Treeitem

ARIA States and Properties

This is used to aid the aria roles already defined on the web page. ARIA Properties often describe relationships with other elements, while the ARIA States are more dynamic and are typically updated with JavaScript as a user interacts with a page. Here screen readers are aware of these changes and notify the user of the update made by these changes.

These states and properties can be found on the w3c website. But some examples include;

• aria-activedescendant: Identifies the currently active descendant of a composite widget. Use with autofill search suggestions.
• aria-autocomplete: Indicates whether user input completion suggestions are provided. Use with autofill search suggestions.
• aria-checked (state): Indicates the current “checked” state of checkboxes, radio buttons, and other widgets. You can set this to be true, false, or mixed state. See related aria-pressed and aria-selected.
• aria-controls: Identifies the element (or elements) whose contents or presence are controlled by the current element. See related aria-owns.
• aria-describedby: Identifies the element (or elements) that describes the object. See related aria-labelledby.
• aria-disabled (state): Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.
• aria-expanded (state): Indicates whether the element or another grouping element it controls, is currently expanded or collapsed.
• aria-hidden (state): Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author. See related aria-disabled.
• aria-invalid (state): Indicates the entered value does not conform to the format expected by the application.
• aria-label: Defines a string value that labels the current element. See related aria-labelledby.
• aria-labelledby: Identifies the element (or elements) that labels the current element. See related aria-label and aria-describedby.
• aria-live: Indicates that an element is dynamic, changing, and will be updated, and describes the types of updates the user can expect from the live region. There are two types of live regions: polite and assertive.When an element uses the polite attribute, the screen reader is able to finish reading what it was focused on before it reads the updated live region. With an assertive attribute, the screen reader interrupts what it is doing to read the updated live region.
• aria-owns: Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. See related aria-controls.
• aria-pressed (state): Indicates the current “pressed” state of toggle buttons. See related aria-checked and aria-selected.
• aria-required: Indicates that user input is required on the element before a form may be submitted.
• aria-selected (state): Indicates the current “selected” state of various widgets. See related aria-checked and aria-pressed.

Importance of ARIA

ARIA is important as it helps inform the users of:

1. The functions of an element.
2. The Structure of the page.
3. The state of an element.
4. Any updating section of the page.
5. Drag and drop sources and targets.

That is the end of the article if you interested in further reading, here are some references.

Improve The Accessibility of Your Designs With ARIA

ARIA | Accessibility Guidelines

Using ARIA in HTML

Introduction to ARIA | Web Fundamentals | Google Developers

Till next time. 😉