- All content on a webpage should be contained inside landmarks.
- Use ARIA roles to describe the type of widget presented.
- Use an aria-label attribute to identify form controls without label.
- Use tabindex or ARIA roles to ensure an element can receive keyboard focus.
- Alert users to dynamic changes in content by defining live regions, especially error messages.
- Use ARIA states to describe the state widgets are in.
The Web Accessibility Initiative (WAI) defines Accessible Rich Internet Applications (ARIA) as:
Most HTML elements have a default role that's understood by browsers and assistive devices--a button has the role of button, for instance. Some have additional properties and states as well--for example, a link can be active or visted. But many elements, such as divs and spans, are without a role.
ARIA allows developers to define roles, states and properties that are not natively available in HTML and to override the HTML defaults of elements. ARIA is supported by most browsers and screen readers, and it is a powerful tool in a developer's accessibility arsenal.
Landmarks: HTML5 and ARIA roles
Landmarks identify the major structural parts of a webpage and can be used by screen reader and other users for keyboard navigation. All content on a webpage should be contained inside landmarks.
There are two ways to define landmarks: with an HTML5 landmark element or an ARIA landmark role. Because some elements and roles are not yet supported by all browsers or screen readers, it's recommended to use both when possible. If no HTML5 landmark element is available (for instance, if you can only use a
<div>), an ARIA landmark role alone will define the landmark.
|HTML5 landmark element||ARIA landmark role||Definition||Usage|
|<header>||role="banner"||Site-oriented content at the beginning of each page||Only one per page. Must be a top-level landmark.|
|<nav>||role="navigation"||Groups of links intended for website or page navigation||If more than one, each should have a unique label.|
|<main>||role="main"||Primary content||Only one per page. Must be a top-level landmark.|
|<section>||role="region"||Content relevant to a specific, author-specified purpose||Must have an unique label.|
|<aside>||role="complementary"||Supporting section that complements and is related to the main content but remains meaningful when separated from it||Must be a top-level landmark. If more than one, each should have an unique label.|
|<footer>||role="contentinfo"||Common information at the bottom of each page||Only one per page. Must be a top-level landmark.|
|<form>||role="form"||Collection of items and objects that together create a form||Must have an unique label.|
|None||role="search"||Contains search functionality for the site||If more than one, each should have an unique label.|
Example of recommended HTML5 and ARIA landmark roles
Example of ARIA landmark roles alone
Labels for HTML5 and ARIA landmarks
Some HTML5 and ARIA landmarks require labels.
- The <header>, <main> and <footer> landmarks do not need labels because they can only be defined once per page.
- Landmarks such as <form> and <section> must always be labeled, even when they are the only landmark of that type on the page.
- Landmarks such as <nav> and <aside> must have a unique label if more than one is used per page.
You can give landmarks (and other elements) unique labels using the aria-label, aria-labelledby, and title properties:
aria-label: Provides text that labels the current landmark when no other label exists; is visible only to assistive technologies.
<aside aria-label="Title for Complementary Area 1">
aria-labelledby: Identifies the element that labels the current landmark.
<h2 id="comp1">Title for Complementary Area 1</h2>
title: Identifies the element that labels the current landmark and may be available as a tooltip on some browsers.
<h2 id="comp1">Title for Complementary Area 1</h2>
ARIA roles to describe widgets
ARIA roles can be used to define otherwise meaningless HTML5 elements, such as divs and spans. Attaching a role gives assistive technologies information about how to handle each element. For example, the following seems to be a simple list:
But it could be intended to represent tabs or a menu, both of which function quite differently. In the absence of visual cues, adding ARIA roles defines elements so assistive devices know how those elements should behave.
<li><a role="tab" href="#bio">Bio</a></li>
Live regions for dynamic content
For content that changes dynamically without page reload, ARIA provides a way to alert assistive device users of those changes: the aria-live property.
<option> .... </option>
Possible values for aria-live are:
- off: screen reader will not announce the changes unless focused on the region
- polite: changes will be announced when the user pauses next
- assertive: changes are immediately announced
aria-live="assertive" is often used for dynamic error messages and is equivalent to
Tabindex and ARIA roles to set focus
Tabindex to make elements focusable
tabindex="0" on an element places the element in the logical navigation flow of the document and allows it to receive focus. For instance, tabindex will allow focus to be set on a normally unfocusable element, such as a <div>:
<div id="menu-container" tabindex="0">
ARIA-roles to make elements focusable
The ARIA-role attribute can add a role to otherwise meaningless (or "role-less") elements such as spans and divs, thus allowing them to receive focus. For example:
<span id="checkbox" role=”checkbox” aria-checked=”false”>...</span>
<div class="button" aria-role="button">Go back</div>
ARIA provides for many states that can add, supplement or alter the current condition of an HTML5 element. For example:
There are many aria states and properties to enhance the accessibility of HTML5 elements. See a list of all ARIA properties and states.
An excellent resource for learning ARIA is the Ryerson University online textbook, Web Accessibility for Developers.
For a table of ARIA roles and attributes, see the ARIA Role Matrices from WhatSock.
- Alert and Message Dialogs
- Combo Box
- Dialog (Modal and non-modal)
- Menu or Menu bar
- Menu Button
- Radio Group
- Tree View
- Window Splitter
For more information on WAI-ARIA, see:
- Accessible Rich Internet Applications (WAI-ARIA) 1.1 (the specs)
- WAI-ARIA Overview
- WAI-ARIA Authoring Practices 1.1
- ARIA Techniques for WCAG 2.0
Relevant W3C WAI documents
- WCAG 2.1 Guideline 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
- How to Meet WCAG 2.1 Guideline 1.3.1
- WCAG 2.1 Guideline 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
- How to Meet WCAG 2.1 Guideline 2.1.1
- WCAG 2.1 Guideline 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
- How to Meet WCAG 2.1 Guideline 2.4.1
- WCAG 2.1 Guideline 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
- How to Meet WCAG 2.1 Guideline 2.4.4
- WCAG 2.1 Guideline 3.3.1 — If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
- How to Meet WCAG 2.1 Guideline 3.3.1
- WCAG 2.1 Guideline 3.3.2 — Labels or instructions are provided when content requires user input. (Level A)
- How to Meet WCAG 2.1 Guideline 3.3.2
- WCAG 2.1 Guideline 3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
- How to Meet WCAG 2.1 Guideline 3.3.3
- WCAG 2.1 Guideline 4.1.2 — Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
- How to Meet WCAG 2.1 Guideline 4.1.2
- For accessibility in online learning and education, join the UDAT working group.
- Connect with us on ASU's #accessibility Slack channel.
- Subscribe to ASU's ITACCESS mailing list.