ARIA Implementation Guide for AT Vendors: Internet Explorer 8

  • Article

This document explains how Windows Internet Explorer 8 supports Accessible Rich Internet Applications (ARIA) through Microsoft Active Accessibility and Microsoft UI Automation. The primary audience for this information is assistive technology (AT) vendors. Note that the implementation of ARIA in Internet Explorer 8 is based on a specification that is still under development; therefore, some features of the ARIA specification may not be fully supported.

This topic contains the following sections.

  • Introduction to W3C WAI-ARIA and UI Automation 
  • Mapping ARIA to Microsoft Active Accessibility and UI Automation 
    • How is ARIA programmatically exposed? 
    • Which markup prevails, ARIA or HTML? 
    • How are ARIA attributes exposed that don't map directly map to accessibility APIs? 
    • Mapping ARIA Roles 
    • Exposing ARIA State and Property 
  • Special Processing Requiring Additional Computation 
    • Widget Values 
    • Relationship attributes 
  • Related Topics

Introduction to W3C WAI-ARIA and UI Automation

Internet Explorer 8 now supports the Accessible Rich Internet Application (ARIA) World Wide Web link specification based on the W3C WAI-ARIA Working Draft World Wide Web link. This allows Web developers to make Web content and Web applications more accessible to people with disabilities. An increasing number of Web sites behave like full-blown applications by using a combination of technologies including script, Cascading Style Sheets (CSS), and HTML. These sites offer their users dynamic and interactive experiences, often created using custom UI objects. The W3C WAI-ARIA specification (also referred to as the ARIA draft) defines guidelines for Web developers to add properties, states, and roles to these rich internet applications, which improves the accessibility of Web sites and Web applications when using an AT (Assistive Technology Products) to interact with Web sites.

The ARIA specification properties, states, and roles cannot be entirely mapped to the Microsoft Active Accessibility specification because ARIA supports new controls and properties that Microsoft Active Accessibility does not, such as the slider control.

Windows Vista introduced a new accessibility model: the UI Automation Specification and Community Promise. For UI Automation to fully support ARIA, the UI Automation specification defines properties that can be mapped to the roles, states and properties defined by the ARIA specification. This enables Internet Explorer 8, as well as other applications, to support the ARIA object model in the context of UI Automation, without having to give up their underlying foundation on Microsoft Active Accessibility. Thus, ATs can add targeted UI Automation support to their implementation of Microsoft Active Accessibility without having to rewrite anything.

When an AT adds support for the UI Automation specification, they also benefit as follows: the UI Automation specification is more extensible than Microsoft Active Accessibility, and UI Automation Clients (such as AT vendors or automated testing tools that support the UI Automation specification) are faster, more reliable and more secure than those built on the Microsoft Active Accessibility architecture (ATs or automated testing tools that support the Microsoft Active Accessibility specification).

  • The UI Automation specification is more extensible than the Microsoft Active Accessibility specification

    The UI Automation specification defines Control Patterns that specify the available behaviors of a given UI Automation Element. Clients can use Control Patterns to anticipate the control's available behaviors or to manipulate the UI. Through Control Patterns, Web developers can map ARIA Properties that don't have an Microsoft Active Accessibility equivalent, such as aria-valuemax and aria-valuemin.

    Aria Properties Definition UI Automation Properties
    aria-valuemax Maximum allowed value for a range type of widget. MaximumProperty (RangeValuePattern)
    aria-valuemin Minimum allowed value for a range type of widget. MinimumProperty (RangeValuePattern)

    The UI Automation specification also offers a simple text object model called TextPattern. This pattern allows for embedding objects in a document object, which enables user agents and client applications to treat Web content either as an HTML document or as a traditional desktop UI, depending on the user scenario. Through patterns, the AriaRole property, and the AriaProperties property, the UI Automation specification can support and extend the W3C WAI-ARIA Working Draft (August 6, 2008) World Wide Web link without depending on a specific application or user agent.

  • UI Automation Clients are faster, more reliable and more secure than Microsoft Active Accessibility Clients

    Microsoft Active Accessibility has a "chatty" architecture — interfaces that make a lot of transitions without doing any significant work, such as getters and setters — hence, a lot of ATs prefer to access the Microsoft Active Accessibility implementations in the target application's process (often called "in-proc"). However, for better security and engineering practice, Microsoft has always recommended that accessibility tools run outside of the process ("out-of-proc"). Running an Microsoft Active Accessibility client in-proc adds complexity and instability to the Microsoft Active Accessibility Server. An in-proc Microsoft Active Accessibility client is more likely to be unstable because it constantly needs to evaluate and examine values, which can potentially affect the actual values and the timing of internal messages. In Internet Explorer 8, it is even harder to run in-proc due to the added complexity of LCIE (Loosely-Coupled IE), in which the browser runs across multiple processes.

UI Automation clients are no longer limited by the legacy limitations of Microsoft Active Accessibility. For scenarios like getting multiple properties from elements in the Document Object Model (DOM), out-of-proc UI Automation clients perform much better than out-of-proc Microsoft Active Accessibility clients. Instead of making one trip per request, you can now make one trip and retrieve multiple data points. Since it is faster, ATs are more likely to run their UI Automation clients out-of-proc, which translates to more stable interaction with UI Automation providers (like Windows Vista and Internet Explorer 8).

For these reasons, Internet Explorer 8 implements UI Automation to extend the existing Microsoft Active Accessibility implementations by using IAccessibleEx. Internet Explorer 8 recognizes the ARIA Role, State, and Property information and exposes it to UI Automation clients (such as ATs or automated testing tools) through the UI Automation specification's AriaRole property and AriaProperties property (defined later). IAccessibleEx also allows existing in-proc ATs to access the native UI Automation Provider interfaces added with Internet Explorer 8.

Mapping ARIA to Microsoft Active Accessibility and UI Automation

How is ARIA programmatically exposed?

ARIA widgets are exposed programmatically though desktop accessibility APIs in the format that is similar and compatible with the rest of desktop applications. Some ARIA concepts may have direct mapping to a set of desktop API properties and methods. For example, the aria-button role attribute value can be directly mapped to Microsoft Active Accessibility IAccessible::get_accRole value ROLE_SYSTEM_PUSHBUTTON or the UI Automation ControlType Button.

Which markup prevails, ARIA or HTML?

In Internet Explorer 8, whenever both the ARIA and the HTML markup try to set the value for an Microsoft Active Accessibility or UI Automation property or state, the ARIA values always prevails. The goal of ARIA is to clarify the role, state and properties of controls beyond what HTML allows, hence ARIA always overrides all other values. For example if a group of four buttons are marked up with ARIA role slider then IE doesn't expose programmatically through the accessibility APIs (Microsoft Active Accessibility and UI Automation) four buttons, but exposes a slider.

How are ARIA attributes exposed that don't map directly map to accessibility APIs?

In Internet Explorer 8, the AriaRole attribute is mapped to the corresponding UI Automation Control Type or Microsoft Active Accessibility Role property. With UI Automation, the original ARIA Role attribute is also available from the AriaRole property. The AriaRole property in UI Automation returns the raw string supplied in the markup with no mapping applied.

Internet Explorer 8 exposes the raw ARIA data as a text string through the UI Automation AriaProperties property. When applicable, they are also mapped to corresponding states and properties in Microsoft Active Accessibility and UI Automation.

AriaProperties is a string property with a collection of name/value pairs with delimiters of equal sign (=) and semicolon (;). For example, checked=true;disabled=false. A backslash (\) is used as an escape when these delimiter characters or '\' appear in the values.

Mapping ARIA Roles

Before ARIA Roles can be exposed, they are first mapped to Microsoft Active Accessibility Roles, to UI Automation control types, and to the UI Automation AriaRole Property (see Mapping ARIA Roles, States, and Properties to UI Automation for the complete mapping.) These two APIs are who expose the ARIA information to the ATs. By using the LocalizedControlType property of the UI Automation control, Internet Explorer 8 can also expose localized descriptions of the ARIA role. The W3C WAI-ARIA Working Draft (August 6, 2008) doesn't provide human readable strings for the ARIA Roles today; it could be useful in the future for that purpose. When the localized string is not specified, a default LocalizedControlType string is supplied by the system.

For example, the ARIA Role checkbox is supported in Microsoft Active Accessibility by the role ROLE_SYSTEM_CHECKBUTTON and in UI Automation it is supported by both the Checkbox control type and the AriaRole checkbox.

Exposing ARIA State and Property

In Internet Explorer 8 most of the W3C ARIA draft's States and Properties are mapped one-to-one to various properties and functions of the Microsoft Active Accessibility and the UI Automation specifications. See Mapping ARIA Roles, States, and Properties to UI Automation for the complete mapping and list of supported ARIA Roles, States, and Properties.

We also have the UI Automation AriaProperties, which is a string property that returns a collection of name-value pairs for most of the ARIA States and Properties.

Internet Explorer 8 only recognizes the States and Properties listed in the W3C ARIA draft, and these are the only values it will return via the UI Automation AriaProperties property. So, if a Web developer adds to an element a custom ARIA State (for example myAriaProp=true), the AriaProperties property won't return myAriaProp=true as a name/value pair.

For example, the ARIA state checked is supported in Microsoft Active Accessibility by the state STATE_SYSTEM_CHECKED and in UI Automation by the Toggle Pattern ToggleState property and the AriaProperties property.

Special Processing Requiring Additional Computation

Widget Values

In Internet Explorer 8, when a widget's role contains aria-valuenow it can be accessed programmatically in two different ways:

  • Microsoft Active Accessibility exposes it through IAccessible::get_accValue.
  • UI Automation exposes it through the ValueProperty (RangeValue Pattern).

In Internet Explorer 8, aria-valuemin and aria-valuemax are also supported through the RangeValue Pattern and with MinimumProperty (RangeValue Pattern) and MaximumProperty (RangeValue Pattern). However, these two attributes do not have mappings to Microsoft Active Accessibility properties and cannot be accessed through it.

The aria-valuetext attribute can potentially be mapped to both Microsoft Active Accessibility and UI Automation; however Internet Explorer 8 does not expose it through UI Automation. The following rules apply:

  • Microsoft Active Accessibility exposes aria-valuetext through IAccessible::get_accvalue. If both the aria-valuenow and aria-valuetext ARIA properties are set, then get_accValue will hold the data from the aria-valuetext property.
  • As indicated in the UI Automation Community Promise, UI Automation maps the ValueProperty (Value Pattern) to aria-valuetext. However, Internet Explorer 8 only implements the RangeValue Pattern, so aria-valuetext is not exposed in Internet Explorer 8 through UI Automation. If an application where to implement both the RangeValue Pattern and Value Pattern, then if aria-valuetext and aria-valuenow are both specified, both of their values could be accessed independently.

The January Draft of the W3C ARIA Implementation Guide outlines additional behaviors and value validation techniques that Microsoft Active Accessibility and UI Automation can potentially support. A lot of these recommendations came in too late in the product cycle; hence the following limitations:

  • Firing value change events for dynamic changes to aria-valuenow is not supported.
  • There are no checks to see if all required values are present for a control.
  • Before setting a value through Microsoft Active Accessibility or UI Automation, there is no check to see if the object's state is readonly or disabled.
  • There is no validation that a new or updated aria-valuenow value lays within the aria-valuemin and the aria-valuemax values.

Relationship attributes

Two or more elements can be related through attributes; we call these attributes "relationship attributes." Relations can be set between elements regardless of the roles of the element.

Internet Explorer 8 only implements forward relations; it does no compute reverse relations. If needed the AT can use the DOM to calculate the reverse relations. Internet Explorer 8 does not calculate reverse relations because in the current architecture these calculations result on routinely degradations of performance. ATs have the option of calculating these reverse relations on a case by case basis; virtually eliminating performance degradation since the number of actual reverse calculations is fully scoped.

The following relationship properties are implemented in Internet Explorer 8 and exposed through UI Automation:

  • aria-controls is exposed through the UI Automation ControllerFor property.
  • aria-describedby is exposed through the UI Automation DescribedBy property.
  • aria-flowto is exposed through the UI Automation FlowsTo property.
  • aria-labelledby is exposed through the UI Automation LabelledBy property.

The aria-owns attribute does not have a relationship property it can be mapped to in UI Automation. However the Accessibility Object Tree reflects the effects of setting this property by transposing a node, or even a branch, based on the relationship between the elements.