This section is informative.
This section sets out normative conditions for conforming document instances and user agent processors, along with informative remarks about the role of other processors such as authoring tools and assistive technologies.
As discussed above in section 6.1.1, an implementing host language will provide a role attribute with a value which will be a space-separated sequence of tokens. If the element does not have a role attribute, or if the role attribute contains no tokens matching the name of a concrete WAI-ARIA role, zero WAI-ARIA roles will be applied.
The applicable WAI-ARIA role is the concrete WAI-ARIA role whose name is matched by the first token in the sequence of tokens in the role attribute value which matches, on case-sensitive comparison, the name of any concrete WAI-ARIA role.
A concrete WAI-ARIA role is any of the role types described above except abstract roles (roles for which isAbstract is true) and the roles imported from the Role Module, that is those that are introduced in sections 4.4.6 and 4.4.7.
The following steps will correctly identify the applicable WAI-ARIA role.
role and to identify the attribute value string for that attribute.When using an accessibility API that accepts only one role value, user agents MUST determine the applicable WAI-ARIA role from the list of roles defined in the role attribute and, if there is one, user agents MUST map that role value to the accessibility API. User agents MUST use an explicit, applicable WAI-ARIA role as overriding any implicit role inferred from the host language markup in performing this mapping. Note that, in conformance with section 7.3.1 above, this overriding does not result in any changes in the DOM, only in the accessibility API representation of the document.
User agents SHOULD expose role, state, and property information provided by the author to accessibility APIs available in their operating system. Refer to Mapping States and Properties to Accessibility APIs ([ARIA-PRACTICES], Section 3.5) for guidance about how to expose this information. This requirement parallels User Agent Accessibility Guidelines 1.0 Section 6.3: Programmatic Access to non-HTML/XML Content ([UAAG], Section 6.3), except that it applies even to HTML and XML content.
Note: Not all platforms provide interfaces that map to all the roles, states, and properties defined in this specification. User agents should expose those roles, states, and properties that are supported. The remaining roles, states, and properties are available to assistive technologies via the DOM, for those that provide explicit support for this specification.
Many of the requirements in the definitions of WAI-ARIA roles, states, and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating custom widgets, authoring tools may compare widget roles, states, and properties to those supported in WAI-ARIA as well as those supported in related ancestor and descendant elements. Authoring tools may notify authors of errors in widget design patterns, and may also prompt developers for information that cannot be determined from context alone. For example, a scripting library can determine the labels for the tree items in a tree view, but would need to prompt the author to label the entire tree. To help authors visualize a logical accessibility structure, authoring environments may provide an outline view of a web resource based on the WAI-ARIA markup. Authoring tools may also provide additional feedback on important accessibility information for a particular implementation of WAI-ARIA.
In HTML, tabindex is an important way browsers support keyboard focus navigation for implementations of WAI-ARIA; authoring and debugging tools may check to make sure tabindex values are properly set. For example, error conditions may include cases where more than one treeitem in a tree has a tabindex value greater than or equal to 0, where tabindex is not set on any treeitem, or where aria-activedescendent is not defined when the element with the role tree has a tabindex value of greater than or equal to 0.
The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction.
Programmatic access to accessibility semantics is essential for assistive technologies. Most assistive technology interacts with user agents, like other applications, through a recognized accessibility API. Perceivable objects in the user interface are exposed to assistive technologies as accessible objects, defined by the accessibility API interfaces. To do this properly, accessibility information – role, states, properties as well as contextual information – needs to be accurately conveyed to the assistive technology through the accessibility API. The accessibility API provides programmatic access to this information. When a state change occurs, the user agent provides the appropriate event notification to the assistive technology. Contextual information, in many host languages like HTML, can be determined from the DOM itself as it provides a contextual tree hierarchy.
While some assistive technologies interact with these accessibility APIs, others may access the content directly from the DOM. These technologies can restructure, simplify, style, or reflow the content to help a different set of users. Common use cases for these types of adaptations may be the aging population, cognitive impairments, or the situationally disabled. The availability of WAI-ARIA semantics facilitates the adaptation process. For example, the availability of regional navigational landmarks may allow for a mobile device adaptation that shows only portions of the content at any one time based on their semantics. This also reduces the amount of information a user needs to process at any one time. In other situations it may be easier to replace a user interface control with something that is easier to navigate with a keyboard, or touch screen device.
These requirements for semantic programmatic access parallel User Agent Accessibility Guidelines 1.0 Section 6.5: Programmatic operation of user agent user interface and Section 6.6: Programmatic notification of changes ([UAAG], Section 6.5 and 6.6) except that it applies to content, not just to the user agent.