Accessible Rich Internet Applications (ARIA) – Par...
Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
The first part of the article discussed the need for complex Web controls, presents various Web content types, and explains why there is a need for something better than current solutions offer – this is where ARIA comes in. This second part of the article introduces ARIA itself and describes its specifications, basic concepts and design patterns, support in user agents, assistive technologies, and development toolkits, its, and finally turns to future challenges.
Because HTML has some limitations for creating rich Web applications (as described in the first part of the article) and to address the needs for better accessibility, the WAI-PF working group of W3C developed a new concept for Accessible Rich Internet Applications (WAI-ARIA). ARIA is a metadata specification that provides a means of describing roles, states, and properties for custom widgets so that they are recognizable and usable by assistive technology users. WAI-ARIA also provides a mechanism to ensure that users of assistive technologies are aware of updates in the application. But ARIA is not limited to HTML, because of its metadata nature, it can be used gracefully in other host languages, too. For instance, current activities specify the use of ARIA roles and properties in SVG and Digital Publishing.
Specifications
There are currently three key documents for ARIA available by W3C:
The key documents to read for Application Developers are the ARIA Specification and the ARIA Authoring Practices. The first two documents are W3C recommendation, the last is still in working draft status. However, there will be more recent versions available in near future. Also, the specification for ARIA 1.1 is already in preparation and is scheduled to be released end of 2015.
Support
ARIA has formed up already a new industry standard for enhanced web application accessibility and is supported in common User Agents (Browsers) and Assistive Technology (Screen Readers), as been described in this excellent overview article.
OS and User Agents
ARIA support is provided in major browsers and even already in some mobile operating systems. An (a bit outdated) overview is even in caniuse.com.
Figure 7: Support for ARIA in different user agents and versions (click image for larger version)
Assistive Technologies
ARIA support is provided in major screen readers, e.g. in the screen reader Jaws for Windows since Version 11.
Development Toolkits
Major companies and organizations have already incorporated full or partial ARIA support in their toolkits/frameworks/plugins already:
Yahoo enables their widgets with ARIA roles; Google is supporting ARIA in their toolkit and uses ARIA Live Regions to indicate page updates (“Please wait…”). JQuery UI ARIA-enabled plugins are also available.
Reference Examples
There are already many examples for ARIA-enabled custom elements available in the Web. The quality and maturity of these examples differ considerably. A main “definitive” reference W3C example site is mandatory but not yet available. A recommended example reference site is http://oaa-accessibility.org/examples/.
Basic Concepts
Roles
One of the major problems with Web applications is that any element can be used to make a widget. HTML elements already have predefined roles. The role of an element is what it does – the part it plays in the structure. For example, the role of a heading is well understood by assistive technology. When widgets are built with existing elements, the role of the element is what is revealed to assistive technology, rather than what it visually represents in the widget. For example, if the thumb for a slider control is created using an image element with appropriate alternative text, then a screen reader will likely announce the control as, “Graphic, thumb”, as opposed to something more meaningful, such as “slider, value 16 percent”. ARIA resolves this by defining
the mapping of the role, states and properties properties values to the respective platform accessibility API (see next chapter)
ARIA is basically RDF-based metadata information about roles, states and properties. The metadata roles are organized in an object-oriented like manner as depicted in the class diagram figure below:
Figure 8: Class diagram of the relationships described in the role data model (click image for larger version)
Note that this does not apply the property to the node with the CSS class assigned, it just advises nodes with the respective property set in markup to be styled according to the CSS class definitions. In interaction, by dynamically assigning, for example, state changes in Java Script code:
function checkbox_select(el) {
if (el.getAttribute("aria-checked") == "false") {el.setAttribute("aria-checked", true);}
else {el.setAttribute("aria-checked", "false");}
}
Interoperability
ARIA metadata is always mapped to the respective platform accessibility API by the user agent or can be retrieved from the documents DOM and Accessibility Trees. Assistive Technology (for example, a screen reader) binds to the API and consumes roles, states, properties, hierarchy information and state /property events (for example, value changes). The situation is depicted in the figure below: Figure 10: Relationships between user agents, accessibility API and assistive technologies (click image for larger version)
In this excellent article of the Pacielleo Group, a general Accessibility API and Specification support table is given. For convenience, the results are also listed below: Table 1: Practical Accessibility API support by browser and OS as of 06/10/2011 Legend:
check “good support” means implemented to a level that provides support for the majority of features.
warning “partial support” lacks support for some important features.
information “not applicable” means the browser does not run on the OS for which the Accessibility API is designed.
error “not supported” means the browser does not have practical support for the specification or Accessibility API on the OS.
Native host language (HTML4/HTML5) elements with their roles, states and properties should be always be used for HTML-based UI’s. Native host language support can be expected from user agent and assistive technology, addressing basic accessibility requirements. Because of
ARIA metadata precedence over the host language
The “bridging” nature of ARIA (the lack of elements in older HTML4-based code)
The current non-maturity of the HTML5 implementation in user agents (ARIA is ahead of HTML5 in the support!)
the question came up what ARIA roles, states and properties are generally “OK” to be used as supplement or element replacement for respective HTML4/5 elements. To address this important topic, a separate specification gives an overview.
Keyboard and Focus Management
ARIA uses the concept of negative values of the HTML tabindex property so that it can be used on all visible elements to set the focus programmatically (using Java Script). In the ARIA specification chapter “Managing Focus”, this is prerequisite for the idea that any rich Web application is responsible for managing the keyboard focus. This includes the complete control of focus handling, the focus traversal inside Ui elements, focus restoring and focus movement within the entire user interface. The “Supporting Keyboard Navigation” section in the WAI-ARIA 1.0 User Agent Implementation Guide defines the basic requirements user agent have to met for supporting this. The WAI-ARIA 1.0 Authoring Practices Keyboard and Structural Navigation chapter explains this concept in fine granularity. The Authoring Practices define also keyboard usage patterns for common UI elements (e.g. for a tab strip element).
Widgets
Many ARIA role property values help to define “custom” accessible graphical user interface widgets. The following roles act as standalone user interface widgets or as part of larger, composite widgets.
We will only present some examples for selected roles here (for complete information, please consult the ARIA specification). Example 1 An input element has a role property of slider, the role exposed to assistive technology is slider, rather than input. Figure 11: A slider element
Example 2 The following code fragment repurposes an HTML list into a tree by assigning a tree role to the
element.The
element containing fruits is repurposed into a tree node by assigning a treeitem role to it. When a blind user navigates to the fruits node, a screen reader announces that the fruits node is expanded.
ARIA defines a variety of states and properties. We will only discuss some selected properties here (for complete information, please consult the specification). Some states and properties are applicable to all host language elements or ARIA roles regardless of whether a role is applied (if existing, the respective HTML5 property counterpart is given in brackets):
For instance, the aria-required property helps with HTML4-based markup to indicate the required state of a text field and helps avoiding user input errors. A number of other properties cover element relationships and will be discussed in subsequent chapters. Other properties are only available to specific host language elements or ARIA roles (they “belong” to them):
For instance, the aria-autocomplete property is used with the ARIA combobox role to indicate that user text input in the text field in the combo will be automatically completed when the item is in the list of available items. A number of additional properties cover special topics (Live Regions, Drag and Drop) and are discussed in subsequent chapters.
Structural Roles
The following roles describe structures that organize content in a page:
Again, we will only discuss some selected roles here. ARIA knows different concepts of element “groupings” that may not be confused with each other. Group is intended to group similar elements for a concept, for example, different elements with role=radio for a radiogroup. In contrast to this, region used together with a heading role is used to identify different “sections” of a screen (in fact, the HTML5
element is the counterpart, see Landmarks chapter). It can be used to group e.g. different elements in a single container. A more specialized region is the form element (similar to the HTML4/5
, see also Landmarks chapter). Regions and forms with heading roles applied will be available as labeled Landmarks in user agents and assistive technology.
Landmarks
For ease of use, it should be possible for blind people and people using the keyboard only to navigate directly to any Website or Web Application Region in a user agent (browser) at will. This will greatly enhance the “usability of accessibility” and will be recognized as a plus in user experience regarding application navigation. The upcoming HTML 5 specification offers a number of elements that can serve for typed structuring of content:
For these are real standard elements, any HTML5-enabled user aAgent will know them and can provide internally means to navigate on request to the respective areas (for example, set the focus in the area when user presses a respective navigational key). In addition, assistive technology parsing the DOM can access them and provide separate navigational mechanisms. Because there is no HTML5 support in older browsers (IE 7, FF 3 etc.), ARIA offers the set of Landmark Roles (as values of the (XHTML) role property) for easy navigation within Web Pages in a user agent (browser). Because the role is interpreted and exposed as custom property in older browsers, assistive technology is able to parse semantics of the individual property values even in older user agents and to provide this information to the end user by offering separate navigational mechanisms. The following landmarks are available:
Landmarks are specialized regions derived from a role region, which is the generic (but not abstract) superclass. Landmarks can be nested (i.e. it is possible to have forms inside forms), forming up a hierarchical structure. Also, relationships to (visual) labels denoting the purpose of the landmarks can be defined. ARIA Landmarks are already well supported in some common screen readers. For instance, Jaws presents the Landmarks and their DOM hierarchy in a separate dialog that can be used for direct navigation:
Figure 12: Landmarks dialog in assistive technology
The following region roles can also be used as landmarks, hence they also control the assistive technology behavior when declared:
If, for example, the application role applies to the entire Web page authors SHOULD set the role of application on the root node for content, such as the body element in HTML. The both roles can be nested, that is, it is possible to have applications inside document regions and vice versa. Finally, the following roles could be also used to denote specialized region features:
These element roles can be applied to individual elements, for example, role=alert to a designated Message Area element. The old and new methods for organization of page structure are depicted below:
Figure 13: Headings, HTML5 sections and ARIA landmarks
In HTML4, there was the only option to structure content by explicit hierarchy using H1-H6 markup elements. Compared to that, HTML5 structural elements and ARIA Landmarks are a much more “semantic” improvement. For convenience, the table below maps the counterparts of HTML5 and ARIA structural elements (background article😞Table 2: HTML5 and ARIA structural elements
HTML 5 Element
ARIA Role Property
html
document
–
application
article
article
body
main
section
region
nav
navigation
fieldset
form
input type=search
search
h1-h6
heading (+ aria-level)
header
banner
address / footer
contentinfo
Examples In HTML5, a structural element is defined as follows (Method 1):
In HTML 4 with ARIA 1.0, a similar structure is defined this way (Method 2):
“banner”>
The role property for document landmarks should be generated directly into the markup:
“ads” role=“banner”> …
“nav” role=“navigation”>
“searchform” role=“search” …> ……
“content” role=“main”> …
Also, it is good practice to label the ARIA Landmarks, for example, as follows:
This will (especially in nested scenarios) considerably enhance the navigation in the page content. Finally, combinations of both approaches are possible (Method 3):
“banner”>
Sooner or later the question comes up what model has to be used best for exposing structural information, HTML5 or ARIA with HTML4. The answer is quite easy for “instrumentation” of older code: Use Method 2. Apply ARIA landmark role properties together with the existing HTML4 markup and you’re done. In addition, your code will still work both in recent AND slightly older browsers, so if you want “backward compatibility”, this is the way to go. For new projects from the scratch the answer is not so easy. If you decide not to use ARIA at all and fully rely on HTML5 markup (Method 1) you will lose some special ARIA landmarks (like “search” etc.), this may be not what you want. When you require as prerequisite an HTML5 compliant browser for your page, the best approach for now is Method 3 (in the author’s opinion): Use HTML5 and ARIA together. You still will have backward compatibility of your code provided the fact that older browsers do not comply about the new HTML5 elements and you provide some easy JavaScript-based fixes for all Internet Explorer versions. Please note: It is still not clear if arbitrary combinations of HTML5 elements and landmarks will always work and how in the various browsers and assistive technology combinations. As a consequence, this has always to be tested for a concrete implementation.
Live Regions
Live regions are parts of a Web page that the author expects to change. Examples of live regions include tables with dynamically updated content (sports stats, stock information), logs where new information is being added (chat transcript logs), notification areas (status, alerts), etc. The aria-live property will denote Live Regions in the document. Content of these regions will change dynamically by DOM manipulations. By indicating that this region is “live”, screen readers can react appropriately on these changes. The aria-busy property should be used when the entire application or an individual element gets into a busy state. This is an invaluable concept to communicate the busy state to assistive technology. The Implementing Live Regions chapter in the WAI-ARIA practices is the central source of more information for this topic.
WAI-ARIA introduces two new Drag and Drop properties that aide Web application authors with the drag and drop process, called aria-grabbed and aria-dropeffect. The property aria-grabbed(state) is applied to the source(s) being dragged, while aria-dropeffect is applied to the target(s). Use of these properties – combined with best practices for enabling the user to select the appropriate drag operations and for assigning appropriate keyboard operations for dragging and dropping – will vastly improve the accessibility of drag and drop functionality. The Drag-and-Drop Support chapter in the WAI-ARIA practices is the central source of more information for this topic.
Design Patterns
As seen in the preceding chapters, ARIA usage requires quite some background know-how. For developers who only want to implement without dealing much with the specification details, the WAI-ARIA 1.0 Authoring Practices are written. Based on the basic role, state and property set, ARIA offers the opportunity to create more complex interfaces composed of a mix of basic roles in the set. This mix is called a design pattern in the ARIA Authoring Practices. For instance, a custom “Dialog Window” is such a pattern, but also the best way to label input fields depending on the use case applies here. A few selected examples are given below. More information about design patterns can be found in the WAI-ARIA 1.0 Authoring Practices Design Patterns chapter.
Layout Tables
A “low hanging fruit” in ARIA is the support for screen reader identification of tables used for layout purposes (that is, to arrange, for example, form elements in a visually attractive manner). All authors have to do is to add role="presentation" as part of the tag:
“presentation” …>
This ensures that screen readers will ignore the table markup entirely and go directly to the elements inside the layout table. Before this became possible, there was no standard reliable concept available for screen reader identification of layout tables, only implicit heuristic rules and custom properties dependant of the actual screen reader used.
Custom Dialogs
Web Applications use more and more custom dialog screens as part of the page: Figure 14: A custom dialog To get the dialog role properly working with Assistive Technology, the following prerequisites have to be met:
Add to the dialog container element the role="dialog" (for example,
)
Define a heading role for the document element containing the dialog title text (for example, >)
Label the dialog element with the heading using aria-labelledby (for example,
)
When toggling dialog visibility: synchronize the aria-hidden state of the dialog accordingly.
Important: When showing the dialog, put the focus explicitly on an active (focusable) element within the dialog (for example, an “OK” button). Otherwise, chances are that the communication with the screen readers will not work flawlessly in actual implementations.
Messaging
ARIA offers the alert role that can be used e.g. for message handling in forms: Figure15: A simple custom message area All you have to do is to declare role="alert" for the document element containing the dialog title text, as implied in the following code snippet:
...
“messageArea” role=“alert” style=“display:none”>
"required">*
"text" id="age" aria-required="true" aria-describedby="descr8"
onkeyup="if (helpers_getKey(event)==13) checkMe(event);"/>
"descr8"> (Press Enter to Check, then enter some text)
...
The message area is initially hidden. In case of error it is shown and any content updates will be spoken by assistive technology (for alert is a “live” region). The input focus can remain in the input field for instant correction of the issue.
Labeling of Input Fields
There are two “classic” ways to label input fields with labels in HTML. By inclusion (not recommended)
By explicit reference using the for property
"text" id="t1" value=""/>
Disadvantages of this approach is that the for property is only supported for HTML form elements and that it does not allow for multiple id references. ARIA adds two additional possibilities for labeling: aria-labelledby ARIA offers the opportunity to handle arbitrary elements as label for other elements:
"text" aria-labelledby="l1"/>
Note that in opposite to for property, ARIA has the concept of inverse relationship for labeling (the element is labeled BY something else). For ARIA takes multiple IDs there is also the opportunity to include multiple labels:
Note that the element is still used, but its ID has been added explicitly to the aria-labelledby IDREF list. This is required due to the precedence rules mentioned earlier. You could even use “hidden” labels using this technique:
Do not use display:none to hide the second label for this removes the DOM node entirely from the accessibility tree and as a consequence, screen readers will not find the respective information for the IDREF given in aria-labelledby (you may use visibility:hidden, though). aria-label As an additional alternative, ARIA adds the opportunity to add a label string to an element. This can be usedfor example, together with ARIA landmark roles, where additional hidden information may make sense for a blind user within a given context:
“navigation” aria-label=“Top”>…
“navigation” aria-label=“Side”>…
To summarize it up which labeling technique should be used:
For 1:1 input labeling use the classic for property and a element
For 1:1 labeling of elements that do not support to be labeled using for, use aria-labelledby
For 1:n labeling (one input with multiple labels) you can use aria-labelledby together with for property as shown in code above
Use aria-label ONLY in exceptional cases (e.g. to give additional info for elements that have no visible label)
Element Descriptions
aria-describedby ARIA offers the opportunity to relate visual descriptions with other elements of the HTML markup. For example:
“desc1”>…
“desc1”>This table charts the number of cups of coffee consumed by each person, the type of coffee preferred (decaf or regular), and if the coffee is taken with sugar.
Used in this way, it supplements effectively the summary attribute for the element. When it is necessary to reference an external document, the aria-describedby property needs to point to a hyperlink, which in turn references the external document. For example:
“histogram.png” alt=“Histogram of Blackberry tree heights.” aria-describedby=“desc2”/>
“desc2” href=“blackberry-description.html”> Data for Blackberry Histogram.
Attention: for title property and aria-describedby are mapped to the same API, also precedence rules apply.
Use title in all cases where additional explanatory texts should be only visible on request and not permanently
To associate explanatory texts on screen to specific elements, use aria-describedby
For images:
Always use the alt property
Fill the title property in case there is no visible image caption, otherwise associate the caption with the image using aria-describedby
An “aria-description” property similar to “aria-label” is missing in ARIA 1.0 but planned for ARIA 2.0. As a workaround, you can use “hidden” elements related using aria-describedby:
"text" id="Text4" aria-describedby="sh"/>
"sh" style="position:absolute; top:-1000px">This is text from hidden span
Note that this should be used only in exceptional cases. In case of doubt, consult the ARIA Authoring Practices.
Future Challenges
ARIA became initially accepted in the Web developer community and by the people and received praise for filling a definitive gap, but also caused constructive criticism and left room for open questions and improvements. As time of this is being written, ARIA is still a young standard. Chances are that the actual slightly different implementations in user agents will be harmonized by time, and so will the end user experience with various browser-screen reader combinations on the market. The development of ARIA continues. The WAI-ARIA 1.1 specification is currently available as working draft. Some challenges related to ARIA 1.0 need still to be addressed (for example, different handling of the some of the concepts around focus management in Firefox and Internet Explorer, monitoring the ARIA support in user agents and assistive software, discussions with other W3C Working Groups etc.). As already stated, ARIA is also covered in the HTML5 specification. The HTML Working Group strives for completeness and for closing its gaps, and the different working groups of W3C are discussing frequently with each other. It can be expected that the HTML WG will pick up/address many of the issues ARIA currently addresses in the long run. ARIA 1.0 roles are based on “classic” rich client UI standard roles with some extensions. As a major future enhancement for the next version of ARIA(2.0), it is planned to add a concept to declare completely”custom” roles (e.g. to identify a “stock ticker control” or something entirely custom). This will represent a further enhancement of the possibilities for Web authors and is therefore in the true spirit of ARIA: being a flexible standard to develop accessible content in a fast-changing Internet world.
Figure 11: A slider element
Figure 14: A custom dialog To get the dialog role properly working with Assistive Technology, the following prerequisites have to be met:
Figure15: A simple custom message area All you have to do is to declare role="alert" for the document element containing the dialog title text, as implied in the following code snippet:“histogram.png” alt=“Histogram of Blackberry tree heights.” aria-describedby=“desc2”/>
