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.

Table of Content

 

Introduction to ARIA

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_acc rich internet part 2_webacc

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

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_acc rich internet part 2_rdf_model

Figure 8: Class diagram of the relationships described in the role data model (click image for larger version)

 

Roles are categorized as follows:

ARIA metadata definitions currently take precedence over the host language in all implementations in user agents. For example:

  • If role="button" is used on an element, the result will be the same as if would have been declared instead of (The role declaration overrides the ‘native’ AccessibleRole in the platform accessibility API).
  • If aria-labelledby is used together with , aria-labelledby will take precedence.

All override definitions are given in detail for roles and for states and properties in the WAI-ARIA 1.0 User Agent Implementation Guide. Also in the User Agent Implementation Guide, additional precedence considerations among individual ARIA properties (with host language as fallback concept) are discussed.

Layers

It is long-term known in the Web development community that the terms

  • Content itself, coming from a server storage location, e.g. disk or a data base
  • HTML – for describing and displaying content (markup, Structure layer)
  • CSS – for design (styling, Presentation layer)
  • JavaScript – for functionality (behavior, Interaction layer).

ARIA can be applied on each of these “layers”, as shown in the following figure:  

figure 9_acc rich internet part 2_layers_metaw2

Figure 9: Content with structure, presentation, and interaction layers. Metadata can be applied on each layer. (Click image for larger version)

 

In structure, by inserting metadata into the host language:

  • “ml1” role=“menuitemcheckbox” aria-checked=true>Sort by Last Modified

In presentation, by adding to CSS class definitions:

[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]:before { background-image: url(checked.gif); }

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_acc rich internet part 2_API

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

  Chrome Firefox Internet Explorer Opera Safari
MSAA
warning check check error error
IA2
warning check error error error
UI Automation
error error check error error
AXaccessibility
warning error information warning check
AT-SPI
error check information error information
ARIA 1.0
warning check check error check
UAAG 1.0
warning warning warning warning warning

  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.

The actual mapping definitions are documented in much more detail in the W3C HTML to Platform Accessibility APIs Implementation Guide.  

Host Language Implications

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.

The following roles act as composite user interface widgets. These roles typically act as containers that manage other, contained 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_acc rich internet part 2_slider Figure 11: A slider element  

...
"image"
	   tabindex="0"
       src="thumb.gif"
       alt="Effectiveness"
       role="slider"
       aria-valuemin="0"
       aria-valuemax="100"
       aria-valuenow="42"
       aria-valuetext="42 percent"
       aria-labelledby="leffective">
...

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.
        “tree1” role=

    “tree”

        tabindex=

    “0”

      >

    • “treeitem” tabindex=“-1” aria-expanded=true> Fruits

    States and Properties

    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_acc rich internet part 2_jawslandmarks

    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_acc rich internet part 2_landmarks

    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:

    “region” aria-labelledby=“sh1”>> “sh1” role=“heading” aria-level=“1”>First level

    “region” aria-labelledby=“sh2”> “sh2” role=“heading” aria-level=“2”>Second level

    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.

    Drag and Drop

    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_acc rich internet part 2_dialog 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:   figure 15_acc rich internet part 2_message 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:

    
    "text" id="Text8" aria-labelledby="Label22 Span1" value="123"/>
      "Span1">Dollar
    

    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:

    
    "text" class="textinput" aria-labelledby="Label25 Label26" />
    
    

    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.  

    References and Acknowledgements

    This article waspartially based on the excellent Introduction to WAI ARIA article by Gez Lemon and was updated and extended with current information. The IBM Human Ability and Accessibility Center offers central information about Accessibility and ARIA. A valuable source is the Web site of the Paciello Group. Its blog section has many articles on Web accessibility and the ARIA topic. The pages of the Illinois Center for Information Technology and Web Accessibility are a good address for HTML Best Practices and using ARIA. I would like to express my special gratitude to former and actual members of the WAI-PF working group for many constructive discussions and deep insights in the process of developing standards for the Web.    

    Related Links

     

     

    Background Links

     

Not logged in