WAI-ARIA roles, states, and properties are intended to add semantic information when native host language elements with these semantics are not available, and are generally used on elements that have no native semantics of their own. They can also be used on elements that have similar but not identical semantics to the intended object (for instance, a nested list could be used to represent a tree structure). This method can be part of a fallback strategy for older browsers that have no WAI-ARIA implementation, or because native presentation of the repurposed element reduces the amount of style and/or script needed. Except for the cases outlined below, [=user agents=] MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.
-Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided that has a corresponding role in the accessibility API, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties, and because authors are expected to have a valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed. For example, spin buttons are typically constructed from text fields (<input type="text">) in order to get most of the default keyboard support. But, the native role, "text field", is not correct because it does not properly communicate the additional features of a spin button. The author adds the WAI-ARIA role of spinbutton (<input type="text" role="spinbutton" ...>) so that the control is properly mapped in the accessibility API. When a WAI-ARIA role is provided that does not have a corresponding role in the accessibility API, user agents MAY expose the native semantic in addition to the WAI-ARIA role. If the host language element is overridden by a WAI-ARIA role whose semantics or structure is not equivalent to the native host language semantics or to a subclass of those semantics, then treat any required [=ARIA/owned=] elements of the native role as having role presentation or none.
Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided that has a corresponding role in the accessibility API, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties, and because authors are expected to have a valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed. For example, spin buttons are typically constructed from text fields (<input type="text">) in order to get most of the default keyboard support. But, the native role, "text field", is not correct because it does not properly communicate the additional features of a spin button. The author adds the WAI-ARIA role of spinbutton (<input type="text" role="spinbutton" ...>) so that the control is properly mapped in the accessibility API. When a WAI-ARIA role is provided that does not have a corresponding role in the accessibility API, user agents MAY expose the native semantic in addition to the WAI-ARIA role. If the host language element is overridden by a WAI-ARIA role whose semantics or structure is not equivalent to the native host language semantics or to a subclass of those semantics, then treat any child elements having roles specified as Allowed Accessibility Child Roles as having presentation or none.
The above text differs slightly from the WAI-ARIA specification. The requirement for user agents to expose the WAI-ARIA role instead of the native role was intended to only apply in cases where there is a direct mapping from the WAI-ARIA role to a corresponding role in the accessibility API. The wording of the requirement is not clear in the WAI-ARIA specification, however, and has been interpreted differently by implementers. The requirement has been clarified here and an additional statement added to indicate that user agents may expose native semantics if there is not a direct mapping to a role in the accessibility API. Because there are differing implementations, authors will be advised against adding such WAI-ARIA roles to native elements that have their own semantics in the WAI-ARIA Authoring Practices Guide.
When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be problematic if the values become out of sync. For example, the HTML checked attribute and the aria-checked attribute could have conflicting values. Therefore to prevent providing conflicting states and properties to assistive technologies, host languages will explicitly declare where the use of WAI-ARIA attributes on a host language element conflict with native attributes for that element. When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.
Host languages might also document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics"). These can be features that have implicit WAI-ARIA semantics as well as features where the processing would be uncertain if the semantics were changed with WAI-ARIA. While conformance checkers might signal an error or warning when a WAI-ARIA role is used on elements with strong native semantics, user agents MUST still use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs.
@@ -2064,13 +2064,13 @@listlistbox not owned by or child of comboboxlistbox without an accessibility parent of combobox| ARIA Specification |
- listbox not owned by or child of combobox
+ listbox
|
|---|---|
listbox owned by or child of comboboxlistbox with an accessibility parent of combobox| ARIA Specification |
- listbox owned by or child of combobox
+ listbox
|
|---|---|
| MSAA + IAccessible2 |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |
| UIA |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it using the For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it using the |
| ATK/AT-SPI |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |
| AX API[Note 1] |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |
| MSAA + IAccessible2 |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |
| UIA |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it using the For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it using the |
| ATK/AT-SPI |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |
| AX API[Note 1] |
- For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the accessibility tree, expose it as For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the accessibility tree, expose it as |