Technical: Here are some WAI-ARIA attributes that are used often and are relatively easy to understand.
This attribute is very useful for adding instructions or descriptions of web elements for AT users. In the menu example above, aria-describedby is used to provide instructions on using the menu, in that case referencing a hidden span element containing a description of keyboard navigation.
It could also be used to provide extra information about a particular feature, such as describing the format for a password form field. If the password must include numbers, letters, and special characters, that text might be positioned after the password field in a span element and through its ID attribute, referenced using aria-describedby in the input element for the password field. With the example markup below, a screen reader would announce the label for the password field, followed by format for the password. Without referencing the format span element, this information may go unnoticed by AT users.
<input type="password" id="pass" aria-describedby="format">
must contain numbers, letters, and special characters
aria-live vs. alert role
The aria-live attribute, often referred to as a live region, must be used in places where information is dynamically updating on a page, without the page itself reloading. Otherwise AT users are unlikely to notice that changes are occurring. The aria-live attribute can be set to “polite,” as seen in the code snippet below, in which case a screen reader will wait until a break in the screen reader’s output to read the content. Or, aria-live can be set to “assertive” in which case a screen reader will interrupt whatever is being read to read the changes within the live region. Live regions are useful for things like news feeds (e.g., Twitter or news sites), live chat applications, social media streams, rotating banners or other kinds of auto-updating information.
<div id="news_feed" aria-live="polite">
//updating content goes here
On the other hand, the
role="alert" attribute, often called an ARIA alert, is a special type of assertive live region, that should be used in places where feedback is being presented. If, for example, a required field in a form is left empty, and an error message is injected immediately below the field to indicate the error (like that in the code snippet below), these types of feedback messages are good candidates for ARIA alerts. Otherwise such messages may go unnoticed by AT users. Or, after successfully submitting a form to register, for instance, the message that appears on the page after submitting the form indicating the registration was successful, would also be a good candidate for an ARIA alert.
<div id="username_feedback" role="alert">
<p style="color:red;">Username field cannot be empty.</p>
roles and landmarks
ARIA provides a whole range of roles that can be used to assign a functional application to particular HTML elements. You have already been introduced to the the “alert” role, and the roles associated with a navigation menu.
There is a particular set of roles that are referred to as landmarks. These should be used carefully throughout a user interface to define regions throughout that UI. Screen readers are able to list these landmarks and users can jump to any one of them to navigate directly to a relevant area of a page.
Where landmarks are used, all areas of a page should be contained within a landmarked region. These regions, introduced back in Unit 2 (2.4.1 Provide Ways to Navigate), are presented again here:
Full list of landmark roles:
- banner: Associated with the header area of a page. There should only be one banner landmark per page.
- complementary: A section of content that complements the main content but also retains its meaning when separated from the main content. Often used with a region containing advertising or promo items aligned down the right side of the page. There can be multiple areas defined as complementary.
- contentinfo: Contains the content usually found in the footer of a page, like copyright and privacy statements. There should only be one contentinfo landmark per page.
- form: Contains form input elements that can be edited and submitted by the user. Multiple elements can have the form role.
- main: The main content of the page. There should only be one main landmark per page.
- navigation: A collection of navigation links used to navigate the site or page. There can be multiple elements with the role navigation.
- search: A search tool.
- application: Represents a unique functional unit, and keyboard commands are handled by the application rather than the browser or the assistive technology itself. An embedded movie player, a calendar widget, or other customized software embedded in web content are examples where the application role might be used. This role should be used sparingly as it can create some confusion for screen reader users when key commands begin working differently.
Though the HTML
tabindex attribute has been around since HTML4, for use with specific HTML elements, with HTML5 it can be used with any element to add keyboard focus to elements that do not normally receive focus, using
In the code for the menu above, you will notice tabindex in the opening div element. Normally divs do not receive keyboard focus. In the case of the menu, adding focus to the container div is needed for the description referred to by aria-describedby to be read. When the div receives focus, the screen reader will announce “Main Menu: Use arrow keys to move left and right and up and down through menus.”
aria-expanded state is used for menus that have toggles to open and close submenus, and also to inform AT users whether a menu item has a submenu, and whether that submenu is open or not.
When forms are formatted in a way that prevents the use of the HTML label element to explicitly associate a label with a form field, only then should aria-label be used to label the form element. If label can be used, it should be used instead of the ARIA version.
A good example of a case where aria-label might be used is on a search form. These forms usually do not include a label element.
<input type="text" id="search" aria-label="Enter search terms" />
This attribute can be used with non-standard forms to associate a label or multiple labels with a form field. For example, you may have a data entry form laid out in a table, like that in the figure below, in which the content of the table header cells provides labels for multiple input fields.
Consider the following table, in which the content of the header cells provides labels for each form input field in the column below. In the markup that follows the figure, you can see how aria-labelledby has been used to assign the values in the header cells as labels for each form element.
Figure: A table used to layout a data entry form.
<td><input type="text" id="name" aria-labelledby="name_label"/></td>
<td><input type="text" id="email" aria-labelledby="email_label"/></td>
<td><input type="text" id="loginl" aria-labelledby="login_label"/></td>
If there is the option to use the label element over using aria-labelledby, then label should be used. If both label and aria-labelledby are used on the same input element, aria-labelledby will override the label.