Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://w3c.github.io/core-aam/ below:

Core Accessibility API Mappings 1.2

W3C Editor's Draft 14 October 2025

This version:

https://w3c.github.io/core-aam/

Latest published version:

https://www.w3.org/TR/core-aam-1.2/

Latest editor's draft:

https://w3c.github.io/core-aam/

History:

https://www.w3.org/standards/history/core-aam-1.2/

Commit history

Implementation report:

https://w3c.github.io/test-results/core-aam-1.2/

Latest Recommendation:

https://www.w3.org/TR/core-aam-1.1/

Editors:

Cynthia Shelly (W3C Invited Expert)

Former editors:

Alexander Surkov (Igalia, S.L.) (Editor until August 2025)

Joanmarie Diggs (Igalia, S.L.) (Editor until October 2022)

Richard Schwerdtfeger (Knowbility) (Editor until October 2017)

Joseph Scheuhammer (Inclusive Design Research Centre, OCAD University) (Editor until May 2017)

Andi Snow-Weaver (IBM) (Editor until December 2012)

Aaron Leventhal (IBM) (Editor until January 2009)

Michael Cooper (W3C) (Editor until July 2023)

Platform Mapping Maintainers:

Benjamin Beaudry (Microsoft Corp.) (UIA)

James Craig (Apple, Inc.) (AX API)

Joanmarie Diggs (Igalia, S.L.) (ATK / AT-SPI)

Alexander Surkov (Igalia, S.L.) (MSAA, IAccessible2)

Feedback:

GitHub w3c/core-aam (pull requests, new issue, open issues)

Copyright © 2014-2025 World Wide Web Consortium. W3C^® liability, trademark and permissive document license rules apply.

This document describes how user agents should expose semantics of web content languages to accessibility APIs. This helps users with disabilities to obtain and interact with information using assistive technologies. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.

This Core Accessibility API Mappings specification defines support that applies across multiple content technologies, including general keyboard navigation support and mapping of general-purpose roles, states, and properties provided in Web content via WAI-ARIA [WAI-ARIA-1.2]. Other Accessibility API Mappings specifications depend on and extend this Core specification for specific technologies, including native technology features and WAI-ARIA extensions. This document updates and will eventually supersede the guidance in the Core Accessibility API Mappings 1.1 [CORE-AAM-1.1] W3C Recommendation. It is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.

The Accessible Rich Internet Applications Working Group seeks feedback on any aspect of the specification. When submitting feedback, please consider issues in the context of the companion documents. To comment, file an issue in the W3C core-aam GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). In-progress updates to the document may be viewed in the publicly visible editors' draft.

Living specification — This document is maintained as a living specification. For the latest normative version, visit Core Accessibility API Mappings.

This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 18 August 2025 W3C Process Document.

1. Abstract
2. Status of This Document
3. 1. Introduction
   1. 1.1 Accessibility APIs
   2. 1.2 Comparing Accessibility APIs
      1. 1.2.1 ATK/AT-SPI
      2. 1.2.2 UIA (UI Automation)
      3. 1.2.3 Accessible Names and Descriptions
4. 2. Conformance
   1. 2.1 Features Deprecated in WAI-ARIA
5. 3. Mapping WAI-ARIA to Accessibility APIs
   1. 3.1 General rules for exposing WAI-ARIA semantics
   2. 3.2 Conflicts between native markup semantics and WAI-ARIA
   3. 3.3 Exposing attributes that do not directly map to accessibility API properties
   4. 3.4 Role mapping
      1. 3.4.1 General rules
      2. 3.4.2 Computed Role
      3. 3.4.3 Role Mapping Tables
         1. 3.4.3.1 alert
         2. 3.4.3.2 alertdialog
         3. 3.4.3.3 application
         4. 3.4.3.4 article
         5. 3.4.3.5 banner
         6. 3.4.3.6 blockquote
         7. 3.4.3.7 button with default values for aria-pressed and aria-haspopup
         8. 3.4.3.8 button with non-false value for aria-haspopup
         9. 3.4.3.9 button with defined value for aria-pressed
         10. 3.4.3.10 caption
         11. 3.4.3.11 cell
         12. 3.4.3.12 checkbox
         13. 3.4.3.13 code
         14. 3.4.3.14 columnheader
         15. 3.4.3.15 combobox
         16. 3.4.3.16 comment
         17. 3.4.3.17 complementary
         18. 3.4.3.18 contentinfo
         19. 3.4.3.19 definition
         20. 3.4.3.20 deletion
         21. 3.4.3.21 dialog
         22. 3.4.3.22 directory (deprecated)
         23. 3.4.3.23 document
         24. 3.4.3.24 emphasis
         25. 3.4.3.25 feed
         26. 3.4.3.26 figure
         27. 3.4.3.27 form with an accessible name
         28. 3.4.3.28 form without an accessible name
         29. 3.4.3.29 generic
         30. 3.4.3.30 grid
         31. 3.4.3.31 gridcell
         32. 3.4.3.32 group
         33. 3.4.3.33 heading
         34. 3.4.3.34 image
         35. 3.4.3.35 img
         36. 3.4.3.36 insertion
         37. 3.4.3.37 link
         38. 3.4.3.38 list
         39. 3.4.3.39 listbox without an accessibility parent of combobox
         40. 3.4.3.40 listbox with an accessibility parent of combobox
         41. 3.4.3.41 listitem
         42. 3.4.3.42 log
         43. 3.4.3.43 main
         44. 3.4.3.44 mark
         45. 3.4.3.45 marquee
         46. 3.4.3.46 math
         47. 3.4.3.47 menu
         48. 3.4.3.48 menubar
         49. 3.4.3.49 menuitem
         50. 3.4.3.50 menuitemcheckbox
         51. 3.4.3.51 menuitemradio
         52. 3.4.3.52 meter
         53. 3.4.3.53 navigation
         54. 3.4.3.54 none
         55. 3.4.3.55 note
         56. 3.4.3.56 option not inside combobox
         57. 3.4.3.57 option inside combobox
         58. 3.4.3.58 paragraph
         59. 3.4.3.59 presentation
         60. 3.4.3.60 progressbar
         61. 3.4.3.61 radio
         62. 3.4.3.62 radiogroup
         63. 3.4.3.63 region with an accessible name
         64. 3.4.3.64 region without an accessible name
         65. 3.4.3.65 row not inside treegrid
         66. 3.4.3.66 row inside treegrid
         67. 3.4.3.67 rowgroup
         68. 3.4.3.68 rowheader
         69. 3.4.3.69 scrollbar
         70. 3.4.3.70 search
         71. 3.4.3.71 searchbox
         72. 3.4.3.72 sectionfooter
         73. 3.4.3.73 sectionheader
         74. 3.4.3.74 separator (non-focusable)
         75. 3.4.3.75 separator (focusable)
         76. 3.4.3.76 slider
         77. 3.4.3.77 spinbutton
         78. 3.4.3.78 status
         79. 3.4.3.79 strong
         80. 3.4.3.80 subscript
         81. 3.4.3.81 suggestion
         82. 3.4.3.82 superscript
         83. 3.4.3.83 switch
         84. 3.4.3.84 tab
         85. 3.4.3.85 table
         86. 3.4.3.86 tablist
         87. 3.4.3.87 tabpanel
         88. 3.4.3.88 term
         89. 3.4.3.89 textbox when aria-multiline is false
         90. 3.4.3.90 textbox when aria-multiline is true
         91. 3.4.3.91 time
         92. 3.4.3.92 timer
         93. 3.4.3.93 toolbar
         94. 3.4.3.94 tooltip
         95. 3.4.3.95 tree
         96. 3.4.3.96 treegrid
         97. 3.4.3.97 treeitem
   5. 3.5 State and Property Mapping
      1. 3.5.1 General rules
      2. 3.5.2 State and Property Mapping Tables
         1. 3.5.2.1 Not Mapped
         2. 3.5.2.2 aria-activedescendant
         3. 3.5.2.3 aria-atomic=true
         4. 3.5.2.4 aria-atomic=false
         5. 3.5.2.5 aria-autocomplete=inline, list, or both
         6. 3.5.2.6 aria-autocomplete=none
         7. 3.5.2.7 aria-braillelabel
         8. 3.5.2.8 aria-brailleroledescription
         9. 3.5.2.9 aria-brailleroledescription is undefined or the empty string
         10. 3.5.2.10 aria-busy=true
         11. 3.5.2.11 aria-busy=false
         12. 3.5.2.12 aria-checked=true
         13. 3.5.2.13 aria-checked=false
         14. 3.5.2.14 aria-checked=mixed
         15. 3.5.2.15 aria-checked is undefined
         16. 3.5.2.16 aria-colcount
         17. 3.5.2.17 aria-colindex
         18. 3.5.2.18 aria-colindextext
         19. 3.5.2.19 aria-colspan
         20. 3.5.2.20 aria-controls
         21. 3.5.2.21 aria-current with non-false allowed value
         22. 3.5.2.22 aria-current with unrecognized value
         23. 3.5.2.23 aria-current is false or undefined
         24. 3.5.2.24 aria-describedby
         25. 3.5.2.25 aria-description
         26. 3.5.2.26 aria-details
         27. 3.5.2.27 aria-disabled=true
         28. 3.5.2.28 aria-disabled=false
         29. 3.5.2.29 aria-dropeffect=copy, move, link, execute, or popup (deprecated)
         30. 3.5.2.30 aria-dropeffect=none (deprecated)
         31. 3.5.2.31 aria-errormessage
         32. 3.5.2.32 aria-expanded=true
         33. 3.5.2.33 aria-expanded=false
         34. 3.5.2.34 aria-expanded is undefined
         35. 3.5.2.35 aria-flowto
         36. 3.5.2.36 aria-grabbed=true
         37. 3.5.2.37 aria-grabbed=false
         38. 3.5.2.38 aria-grabbed is undefined
         39. 3.5.2.39 aria-haspopup=true
         40. 3.5.2.40 aria-haspopup=false
         41. 3.5.2.41 aria-haspopup=dialog
         42. 3.5.2.42 aria-haspopup=grid
         43. 3.5.2.43 aria-haspopup=listbox
         44. 3.5.2.44 aria-haspopup=menu
         45. 3.5.2.45 aria-haspopup=tree
         46. 3.5.2.46 aria-hidden=true on unfocused element
         47. 3.5.2.47 aria-hidden=true when element is focused or fires an accessibility event
         48. 3.5.2.48 aria-hidden=false
         49. 3.5.2.49 aria-invalid=true
         50. 3.5.2.50 aria-invalid=false
         51. 3.5.2.51 aria-invalid=spelling or grammar
         52. 3.5.2.52 aria-invalid with unrecognized value
         53. 3.5.2.53 aria-keyshortcuts
         54. 3.5.2.54 aria-label
         55. 3.5.2.55 aria-labelledby
         56. 3.5.2.56 aria-level on non-heading
         57. 3.5.2.57 aria-level on heading
         58. 3.5.2.58 aria-live=assertive
         59. 3.5.2.59 aria-live=polite
         60. 3.5.2.60 aria-live=off
         61. 3.5.2.61 aria-modal=true
         62. 3.5.2.62 aria-modal=false
         63. 3.5.2.63 aria-multiline=true
         64. 3.5.2.64 aria-multiline=false
         65. 3.5.2.65 aria-multiselectable=true
         66. 3.5.2.66 aria-multiselectable=false
         67. 3.5.2.67 aria-orientation=horizontal
         68. 3.5.2.68 aria-orientation=vertical
         69. 3.5.2.69 aria-orientation is undefined
         70. 3.5.2.70 aria-owns
         71. 3.5.2.71 aria-placeholder
         72. 3.5.2.72 aria-posinset
         73. 3.5.2.73 aria-pressed=true
         74. 3.5.2.74 aria-pressed=mixed
         75. 3.5.2.75 aria-pressed=false
         76. 3.5.2.76 aria-pressed is undefined
         77. 3.5.2.77 aria-readonly=true
         78. 3.5.2.78 aria-readonly=false
         79. 3.5.2.79 aria-readonly is unspecified on gridcell
         80. 3.5.2.80 aria-relevant
         81. 3.5.2.81 aria-required=true
         82. 3.5.2.82 aria-required=false
         83. 3.5.2.83 aria-roledescription
         84. 3.5.2.84 aria-roledescription is undefined or the empty string
         85. 3.5.2.85 aria-rowcount
         86. 3.5.2.86 aria-rowindex
         87. 3.5.2.87 aria-rowindextext
         88. 3.5.2.88 aria-rowspan
         89. 3.5.2.89 aria-selected=true
         90. 3.5.2.90 aria-selected=false
         91. 3.5.2.91 aria-selected is undefined
         92. 3.5.2.92 aria-setsize
         93. 3.5.2.93 aria-sort=ascending
         94. 3.5.2.94 aria-sort=descending
         95. 3.5.2.95 aria-sort=other
         96. 3.5.2.96 aria-sort=none
         97. 3.5.2.97 aria-valuemax
         98. 3.5.2.98 aria-valuemin
         99. 3.5.2.99 aria-valuenow
         100. 3.5.2.100 aria-valuetext
   6. 3.6 Special Processing Requiring Additional Computation
      1. 3.6.1 Name and Description
      2. 3.6.2 Relations
         1. 3.6.2.1 Reverse Relations
         2. 3.6.2.2 Implied reverse relations
      3. 3.6.3 Group Position
   7. 3.7 Actions
   8. 3.8 Events
      1. 3.8.1 State and Property Change Events
         1. 3.8.1.1 aria-activedescendant
         2. 3.8.1.2 aria-busy (state)
         3. 3.8.1.3 aria-checked (state)
         4. 3.8.1.4 aria-current (state)
         5. 3.8.1.5 aria-disabled (state)
         6. 3.8.1.6 aria-describedby
         7. 3.8.1.7 aria-dropeffect (property, deprecated)
         8. 3.8.1.8 aria-expanded (state)
         9. 3.8.1.9 aria-grabbed (state, deprecated)
         10. 3.8.1.10 aria-hidden (state)
         11. 3.8.1.11 aria-invalid (state)
         12. 3.8.1.12 aria-label and aria-labelledby
         13. 3.8.1.13 aria-pressed (state)
         14. 3.8.1.14 aria-readonly
         15. 3.8.1.15 aria-required
         16. 3.8.1.16 aria-selected (state)
         17. 3.8.1.17 aria-valuenow
         18. 3.8.1.18 aria-valuetext
      2. 3.8.2 Changes to document content or node visibility
      3. 3.8.3 Focus Changes
      4. 3.8.4 Selection
      5. 3.8.5 Special Events for Menus
6. 4. Privacy considerations
7. 5. Security considerations
8. A. Change Log
   1. A.1 Substantive changes since the last Candidate Recommendation Snapshot
   2. A.2 Substantive changes since the Core Accessibility API Mappings 1.1 Recommendation
9. B. Acknowledgments
   1. B.1 ARIA WG participants at the time of publication
   2. B.2 Enabling funders
10. C. References
    1. C.1 Normative references
    2. C.2 Informative references

This section is non-normative.

The Core Accessibility API Mappings specifies how WAI-ARIA roles, states, and properties are expected to be exposed by user agents via platform accessibility APIs. It is part of a set of resources that define and support the WAI-ARIA specification which includes the following documents:

• Accessible Rich Internet Applications (WAI-ARIA) 1.2 [WAI-ARIA-1.2], a W3C recommendation, defines the WAI-ARIA standard.
• WAI-ARIA Authoring Practices Guide, describes how web content developers can develop accessible rich internet applications using WAI-ARIA. It provides detailed advice and examples directed primarily to web application developers, yet also useful to user agent and developers of assistive technologies.
• Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) [WAI-ARIA-ROADMAP], defines the path to make rich web content accessible, including steps already taken, remaining future steps, and a time line.

For an introduction to WAI-ARIA, see the WAI-ARIA Overview.

Accessibility APIs make it possible to communicate accessibility information about user interfaces to assistive technologies. This information includes:

1. Descriptive properties (role, name, value, position, etc.)
2. Transient states (pressed, focused, etc.)
3. Events (text changed, button was clicked, checkbox was toggled)
4. Actions the user might take (click, check/toggle, drag, etc.)
5. Relationships (parent/child, description/described object, previous object/next object, etc.)
6. Textual content

Accessibility APIs covered by this specification are:

• MSAA with IAccessible2 1.3 [IAccessible2]
• User Interface Automation [UI-AUTOMATION]
• ATK - Accessibility Toolkit [ATK] and Assistive Technology Service Provider Interface [AT-SPI], referred to hereafter as "ATK/AT-SPI"
• macOS Accessibility Protocol [AXAPI]

The WAI-ARIA 1.0 User Agent Implementation Guide included mappings for [UIA-EXPRESS], also known as IAccessibleEx, which was implemented in Microsoft Internet Explorer 8.0 - 11. New implementations are strongly encouraged to use UI Automation instead.

If user agent developers need to expose information using other accessibility APIs, it is recommended that they work closely with the developer of the platform where the API runs, and assistive technology developers on that platform.

For various technological and historical reasons, accessibility APIs do not all work in the same way. In many cases, there is no simple one-to-one relationship between how each of them names or exposes roles, states, and properties to assistive technologies. The following subsections describe a few of the distinguishing characteristics of some of the APIs.

MSAA, IAccessible2, UIA, and AX API each define an API that is shared by both the software application exposing information about its content and interactive components, and the assistive technology consuming that information. Conversely, Linux/GNOME separates that shared interface into its two aspects, each represented by a different accessibility API: ATK or AT-SPI.

ATK defines an interface that is implemented by software in order to expose accessibility information, whereas AT-SPI is a desktop service that gathers accessibility information from active applications and relays it to other interested applications, usually assistive technologies.

For example, the GNOME GUI toolkit [GTK], implements the relevant aspects of ATK for each widget (menu, combobox, checkbox, etc.) in order that GTK widgets expose accessibility information about themselves. AT-SPI then acquires the information from applications built with GTK and makes it available to interested parties.

ATK is most relevant to implementors, whereas AT-SPI is relevant to consumers. In the context of mapping WAI-ARIA roles, states and properties, user agents are implementors and use ATK. Assistive Technologies are consumers, and use AT-SPI.

UI Automation expresses every element of the application user interface as an automation element. Automation elements form the nodes of the application accessibility tree, that can be queried, traversed and interacted with by automation clients.

There are several concepts central to UI Automation:

• Automation element - controls and some application content are presented as automation elements.
• Element properties - Automation elements have several common properties describing native framework element characteristics in an agnostic way that all automation clients can understand. There are several ways to access element property values, described below.
• Control Patterns - Some common interactivity in different frameworks is expressed as control patterns in UIA, allowing different automation clients to interact with controls using common programmatic interfaces.
• Events - Similar to other accessibility APIs, automation elements support various events that allow automation providers to notify clients on important state changes.

All automation elements inherit from the IUIAutomationElement interface and all properties that are not specific to a particular control pattern can be queried through that interface. There are several ways to access UI Automation element properties:

• Direct property accessors to the current values - Current{PropertyName}, e.g. IUIAutomationElement::CurrentName for the Name property
• Cached property accessors - Cached{PropertyName}, e.g. IUIAutomationElement::CachedName for the Name property. Using cached values is preferred when providers and clients are used in remote environments.
• GetCurrentPropertyValue and passing the UIA Property ID enumeration value corresponding to that property to get the current value, e.g. IUIAutomationElement::GetCurrentPropertyValue(UIA_NamePropertyId) for the Name property.
• GetCachedPropertyValue and passing the UIA Property ID enumeration value corresponding to that property to get the cached value, e.g. IUIAutomationElement::GetCachedPropertyValue(UIA_NamePropertyId) for the Name property.

Properties for specific UIA control patterns are queried the same way using relevant control pattern interfaces. Taking Toggle Pattern as an example, to query the ToggleState property clients can use IUIAutomationTogglePattern::CurrentToggleState or IUIAutomationTogglePattern::GetCurrentPropertyValue(UIA_ToggleToggleStatePropertyId) to get the current value.

The property mappings in this specification provide the {PropertyName} and do not specify all specific ways to access the property value. Automation clients can access current or cached values using conventions described above, depending on specific needs and coding style conventions.

Each platform accessibility API includes a way to assign and retrieve accessible name and accessible description properties for each accessible object created in the accessibility tree. How these properties are implemented and what they are called vary depending on the API.

For instance, in MSAA, all accessible objects support the accName property, which stores the object's accessible name. Where the object also supports having an accessible description, MSAA stores this property in the object's accDescription property.

Software using ATK can read and write to an object's accessible-name and accessible-description properties. In turn, AT-SPI can query the values of those properties through its atspi_accessible_get_name and atspi_accessible_get_description functions.

Automation elements in the UIA accessibility tree have a Name property. Where the object also supports having an accessible description, UIA stores this property in the object's FullDescription property.

An object's accessible description, where provided by aria-description or aria-describedby, should be exposed in the accessibilityCustomContent API. Otherwise, it should be exposed as AXHelp.

For more detail, see the Accessible Name and Description Computation specification.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Normative sections provide requirements that user agents and assistive technologies MUST follow for an implementation to conform to this specification.

Non-normative (informative) sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.

The WAI-ARIA specification lists some features as deprecated. Although this means authors are encouraged not to use such features, it is expected that the features could still be used in legacy content. Therefore, it is important that user agents continue to map these features to accessibility APIs, and doing so is part of conformance to this specification. When future versions of the WAI-ARIA specification change such features from deprecated to removed, they will be removed from the mappings as well and user agents will no longer be asked to continue support for those features.

Where supported by the platform Accessibility API, user agents expose WAI-ARIA semantics through the standard mechanisms of the desktop accessibility API. For example, for WAI-ARIA widgets, compare how the widget is exposed in a similar desktop widget. In general most WAI-ARIA widget capabilities are exposed through the role, value, Boolean states, and relations of the accessibility API.

With respect to WAI-ARIA 1.0 and 1.1, accessibility APIs operate in one direction only. User agents publish WAI-ARIA information (roles, states, and properties) via an accessibility API, and an AT can acquire that information using the same API. However, the other direction is not supported. WAI-ARIA 1.0 and 1.1 do not define mechanisms for assistive technologies to directly modify WAI-ARIA information.

The terms "exposing", "mapping", and "including" refer to the creation of accessible object nodes within the accessibility tree, and populating these objects with Accessibility API specific states and properties.

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 child elements having roles specified as Allowed Accessibility Child Roles as having presentation or none.

Note

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.

Platform accessibility APIs might have features that are not in WAI-ARIA. Likewise, WAI-ARIA exposes capabilities that are not supported by accessibility APIs at the time of publication. There typically is not a one to one relationship between all WAI-ARIA attributes and platform accessibility APIs. When WAI-ARIA roles, states and properties do not directly map to an accessibility API, and there is a mechanism in the API to expose the WAI-ARIA role, states, and properties and their values, user agents MUST expose the WAI-ARIA data using that mechanism as follows:

• In IAccessible2 and ATK/AT-SPI, use object attributes to expose semantics that are not directly supported in the APIs. Object attributes are name-value pairs that are loosely specified, and very flexible for exposing things where there is no specific interface in an accessibility API. For example, at this time, the aria-live attribute can be exposed via an object attribute because accessibility APIs have no such property available. Specific rules for exposing object attribute name-value pairs are described throughout this document, and rules for the general cases are in State and Property Mapping.
• In Microsoft UIA, use the AriaRole and AriaProperties properties to expose semantics that are not directly supported in the control type.

Note

MSAA does not provide a mechanism for exposing attributes that do not map directly to the API and among implementers, there is no agreement on how to do it.

User agents MUST also expose the entire role string through this mechanism and MAY also expose WAI-ARIA attributes and values through this mechanism even when there is a direct mapping to an accessibility API.

Browser implementers are advised to publicly document their API methods for exposing any relevant information, so that assistive technology developers can use the API to support user features.

Platform accessibility APIs traditionally have had a finite set of predefined roles that are expected by assistive technologies on that platform and only one or two roles may be exposed. In contrast, WAI-ARIA allows multiple roles to be specified as an ordered set of space-separated valid role tokens. The additional roles are fallback roles similar to the concept of specifying multiple fonts in case the first choice font type is not supported.

User agents MUST expose the WAI-ARIA role string if the API supports a mechanism to do so. This allows assistive technologies to do their own additional processing of roles.

• MSAA: not supported. User agents SHOULD NOT expose a custom role in MSAA's accRole property.
• IAccessible2: expose as an object attribute pair (xml-roles:"string")
• UIA: expose as AriaRole property. The AriaRole property can also support secondary roles using a space as a separator.
• ATK/AT-SPI: expose as an object attribute pair (xml-roles:"string")

The computedrole of an element is a string that represents the role of the element as computed by the browser engine. The computedrole is used primarily for the purposes of developer tools and specification conformance and interoperability testing.

<button> 

<a href="#" role="button"> 

Note

When an element has a role but is not contained in the required context (for example, an orphaned listitem without the required accessible parent of role list), this is an authoring error, but the user agent behavior is not specified as a single rule. For most roles, user agents can either recover the error by ignoring the role, or respect the author's intended role in scenarios deemed by the implementation to be harmless. Please note that this permissiveness in how engines treat author role errors might be overridden in a language-specific mapping document such as [HTML-AAM].

<div role="listitem"> 

<div role="list"> 
  <div role="listitem"> 

When host language elements do not have an exact or equivalent mapping to a valid, non-abstract role, the related Accessibilty API Mapping extension specification MAY specify a unique computedrole string as the return value for interoperability testing purposes, such as <video> -> "html-video" in [HTML-AAM]. However, authors MUST NOT use any host-language-prefixed computedrole string in the role attribute (such as html-video), unless the token also matches valid, defined role (such as dpub-chapter). User Agents MUST ignore any abstract or invalid role token.

<video> 

<main role="html-video"> 

alert

alertdialog

application

article

blockquote

button

button

caption

cell

code

columnheader

combobox

complementary

contentinfo

definition

deletion

dialog

list

document

emphasis

feed

figure

form

form

generic

grid

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

gridcell

group

heading

image

image

insertion

link

list

listbox

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

listbox

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

listitem

log

main

mark

marquee

math

meter

navigation

none

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 IA2_ROLE_TEXT_FRAME. user agents SHOULD prune empty descendants from the accessibility tree.

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 text pattern. user agents SHOULD prune empty descendants from the accessibility tree.

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 ROLE_SECTION. user agents SHOULD prune empty descendants from the accessibility tree.

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 AXGroup. user agents SHOULD prune empty descendants from the accessibility tree.

note

paragraph

none

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 IA2_ROLE_TEXT_FRAME. user agents SHOULD prune empty descendants from the accessibility tree.

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 text pattern. user agents SHOULD prune empty descendants from the accessibility tree.

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 ROLE_SECTION. user agents SHOULD prune empty descendants from the accessibility tree.

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 AXGroup. user agents SHOULD prune empty descendants from the accessibility tree.

progressbar

Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return false for all Value methods that provide a means to modify the value.

radiogroup

region

Use native host language role.

row

row

rowgroup

scrollbar

Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return false for all Value methods that provide a means to modify the value.

search

searchbox

seperator

seperator

Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return false for all Value methods that provide a means to modify the value.

slider

Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return false for all Value methods that provide a means to modify the value.

spinbutton

Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return false for all Value methods that provide a means to modify the value.

status

strong

subscript

suggestion

superscript

tab

table

tablist

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

tabpanel

term

textbox

textbox

time

timer

toolbar

tooltip

tree

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

treegrid

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return false for all Selection methods that provide a means to modify the selection.

Note

^{[Note 1]} User agent should return a user-presentable, localized string value for the AXRoleDescription.

Note

^{[Note 2]} This specification does not currently contain guidance for when user agents should fire system alert events. Some guidance may be added to the specification at a later date but it will be a recommendation (SHOULD), not a requirement (MUST).

This section describes how to expose WAI-ARIA states and properties.

1. User agents MUST compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant.
2. User agents MUST continue to expose native semantics in addition to WAI-ARIA state and property semantics except where an explicit WAI-ARIA override is allowed by the host language. For example, an HTML checkbox may have an aria-labelledby attribute but the native HTML semantics must still be exposed.
3. User agents MUST expose additional states for certain roles as defined in the Role Mapping Tables.
4. User agents MUST compute states for the relevant WAI-ARIA attributes and map to the accessibility API as specified in the State and Property Mapping Tables. To determine the relevant WAI-ARIA attributes, refer to the Definition of Roles [WAI-ARIA-1.2]]. Where the author has not provided values for required attributes, user agents SHOULD process as if the default value was provided.
5. Some WAI-ARIA properties are not global, and are only supported on certain roles. If a non-global WAI-ARIA state or property is used where it is not supported, user agents SHOULD NOT map the given WAI-ARIA property to the platform accessibility API. For example, if aria-checked="true" is specified on <div role="grid">, it should not be exposed in MSAA implementations as STATE_SYSTEM_CHECKED.
6. When an explicit or inherited role of none or presentation is applied to an element, the user agent MUST implement the rules for the none or the presentation role defined in Accessible Rich Internet Applications (WAI-ARIA) 1.2 [WAI-ARIA-1.2]].

There are a number of occurrences in the table where a given state or property is declared "Not mapped". In some cases, this occurs for the default value of the state/property, and is equivalent to its absence. User agents might find it quicker to map the value than check to see if it is the default. For computational efficiency, user agents MAY expose the state or property value if doing so is equivalent to not mapping it. These cases are marked with an asterisk.

In other cases, it is mandatory that the state/property not be mapped, since exposing it implies a related affordance. An example is aria-grabbed. Its absence not only indicates that the accessible object is not grabbed, but further defines it as not grab-able. These cases are marked as "Not mapped" without an asterisk.

User agents MAY expose the elements that are referenced by this property as children of the current element. In which case, if multiple aria-owns relationships are found, use only the first one. If the accessibility tree is not modified, expose as:

User agents MAY expose the elements that are referenced by this property as children of the current element. In which case, if multiple aria-owns relationships are found, use only the first one. If the accessibility tree is not modified, expose as:

If the author-provided value of aria-setsize is -1, the exposed value should be based on the number of objects in the DOM.

For information on how to compute an accessible name or accessible description, see the section titled Accessible Name and Description Computation of the Accessible Name and Description Computation specification.

Often in a GUI, there are relationships between the widgets that can be exposed programmatically to assistive technology. WAI-ARIA provides several relationship properties which are globally applicable to any element: aria-controls, aria-describedby, aria-flowto, aria-labelledby, aria-owns, aria-posinset, and aria-setsize. Therefore, it is not important to check the role before computing them. User agents can simply map these relations to accessibility APIs as defined in the section titled State and Property Mapping.

A reverse relation exists when an element's ID is referenced by a property in another element. For APIs that support reverse relations, user agents MUST use the mapping defined in the State and Property Mapping Tables when an element's ID is referenced by a relation property of another element and the referenced element is in the accessibility tree. All WAI-ARIA references must point to an element that is exposed as an accessible object in the accessibility tree. When the referenced object is not exposed in the accessibility tree (e.g. because it is hidden), the reference is null. aria-labelledby and aria-describedby have an additional feature, which allows them to pull a flattened string from the referenced element to populate the name or description fields of the accessibility API. This feature is described in the Name and Description section.

Special case: If both aria-labelledby and HTML <label for= … > are used, the user agent MUST use the WAI-ARIA relation and MUST ignore the HTML label relation.

Note that aria-describedby may reference structured or interactive information where users would want to be able to navigate to different sections of content. User agents MAY provide a way for the user to navigate to structured information referenced by aria-describedby and assistive technology SHOULD provide such a method.

In addition to the explicit relations defined by WAI-ARIA properties, reverse relations are implied in two other situations: elements with role="treeitem" where the ancestor does not have an aria-owns property and descendants of elements with aria-atomic property.

In the case of role="treeitem", when aria-owns is not used, user agents SHOULD do the following where reverse relations are supported by the API:

• If the current treeitem uses aria-level, then walk backwards in the tree until a treeitem is found with a lower aria-level, then set RELATION_NODE_CHILD_OF to that element. If the top of the tree is reached, then set RELATION_NODE_CHILD_OF to the tree element itself.
• If the parent of the treeitem has a role of group, then walk backwards from the group until an element with a role of treeitem is found, then set RELATION_NODE_CHILD_OF to that element.

In the case of aria-atomic, where reverse relations are supported by the API:

• User agents SHOULD check the chain of ancestor elements for aria-atomic="true". If found, user agents SHOULD set the RELATION_MEMBER_OF relation to point to the ancestor that sets aria-atomic="true".

aria-level, aria-posinset, and aria-setsize are all 1-based. When the property is not present or is "0", it indicates the property is not computed or not supported. If any of these properties are specified by the author as either "0" or a negative number, user agents SHOULD use "1" instead.

If aria-level is not provided or inherited for an element of role treeitem or comment, user agents implementing IAccessible2 or ATK/AT-SPI MUST compute it by following the explicit or computed RELATION_NODE_CHILD_OF relations.

If aria-posinset and aria-setsize are not provided, user agents MUST compute them as follows:

• for role="treeitem" and role="comment", walk the tree backward and forward until the explicit or computed level becomes less than the current item's level. Count items only if they are at the same level as the current item.
• Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role.
• Because these value are 1-based, include the current item in the computation. For aria-posinset, include the current item and other group items if they are before the current item in the DOM. For aria-setsize, add to that the number of items in the same group after the current item in the DOM.

If the author provides one or more of aria-setsize and aria-posinset, it is the author's responsibility to supply them for all elements in the set. User agent correction of missing values in this case is not defined.

MSAA/IAccessible2 API mappings involve an additional function, groupPosition() [IAccessible2], when aria-level, aria-posinset, and/or aria-setsize are present on an element, or are computed by the user agent. When this occurs:

• aria-level is exposed in the groupLevel parameter of groupPosition(),
• aria-setsize is exposed in the similarItemsInGroup parameter, and
• aria-posinset is exposed in the positionInGroup parameter.

As part of mapping roles to accessible objects as defined in Role Mapping, users agents expose a default action on the object.

• MSAA: If an AT calls DoDefaultAction on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.
• IAccessible2: If an AT calls the IAccessibleAction on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.
• UIA Automation: If an AT calls any UIA pattern method on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.
• ATK/AT-SPI: If an AT calls an action on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.
• AX API: If an AT triggers an AXPress action on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.

Note

Authors will need to create handlers for those click events that update WAI-ARIA states and properties in the DOM accordingly, so that those updated states can be populated by the user agent in the Accessibility API.

User agents fire events for user actions, WAI-ARIA state changes, changes to document content or node visibility, changes in selection and operation of menus as defined in the following sections.

User agents MUST notify assistive technology of state changes as defined in the table below, SHOULD notify assistive technology of property changes if the accessibility API defines a change event for the property, and SHOULD NOT notify assistive technology of property changes if the accessibility API does not define a change event for the property. For example, IAccessible2 defines an event to be used when aria-activedescendant changes. WAI-ARIA properties that are expected to change include aria-activedescendant, aria-valuenow, and aria-valuetext.

Note

In some APIs, AT will only be notified of events to which it has subscribed.

For simplicity and performance the user agent MAY trim out change events for state or property changes that assistive technologies typically ignore, such as events that are happening in a window that does not currently have focus.

Note

Translators: For label text associated with the following table and its toggle buttons, see the mappingTableLabels object in the <head> section of this document.

Property: AriaProperties

Properties: AriaProperties, ToggleState as part of toggle pattern

Property: AriaProperties

Properties: AriaProperties, IsEnabled

Properties: DescribedBy

Property: AriaProperties

Properties: AriaProperties, ExpandCollapseState as part of the ExpandCollapse pattern

EVENT_OBJECT_SELECTION

IA2_EVENT_OBJECT_ATTRIBUTE_CHANGED

Property: AriaProperties

PropertyChangedEvent

Property: AriaProperties

Properties: AriaProperties, IsDataValidForForm

Property for aria-label: AriaProperties

Property for aria-labelledby: LabeledBy

Properties: AriaProperties, ToggleState as part of toggle pattern

Property: AriaProperties

Properties: AriaProperties, IsRequiredForForm

Properties: AriaProperties, also RangeValueValue if element is mapped with RangeValue Control Pattern

Property: AriaProperties

Processing document changes is important regardless of WAI-ARIA. The events described in the table below are used by user agents to inform AT of changes to the DOM via the accessibility tree. For the purposes of conformance with this standard, user agents MUST implement the behavior described in this section whenever WAI-ARIA attributes are applied to dynamic content on a Web page.

Fire the following events for node changes where the node in question is an element and has an accessible object. The accessibility subtree of a node is its accessible object in the accessibility tree and all of it's accessibility descendants. It does not include objects which have relationships other than parent-child in that tree. For example, it does not include objects linked via aria-flowto unless those objects are also descendants in the accessibility tree.

AXUIElementDestroyed

If in a live region, AXLiveRegionChanged

AXUIElementDestroyed

If in a live region, AXLiveRegionChanged

AXUIElementCreated

If in a live region, AXLiveRegionChanged

AXUIElementCreated

If in a live region, AXLiveRegionChanged

AXUIElementDestroyed/ AXUIElementCreated

If in a live region, AXLiveRegionChanged

AXUIElementDestroyed/ AXUIElementCreated

If in a live region, AXLiveRegionChanged

In some cases, node changes may occur where the node is not an element or has no accessible object. For example, a numbered list bullet ("12.") may have a node in the accessibility tree but not in the DOM tree. For text within a paragraph marked in HTML as <strong>, the <strong> element has a node in the DOM tree but may not have one in the accessibility tree. The text itself will of course be in the accessibility tree along with the identification of the range of text that is formatted as strong. If any of the changes described in the table above occur on such a node, user agents SHOULD compute and fire relevant text change events as described above.

User agents SHOULD ensure that an assistive technology, running in process can receive notification of a node being removed prior to removal. This allows an assistive technology, such as a screen reader, to refer back to the corresponding DOM node being deleted. This is important for live regions where removals are important. For example, a screen reader would want to notify a user that another user has left a chat room. The event in MSAA would be EVENT_OBJECT_HIDE. For ATK/AT-SPI this would be children_changed::remove. And in macOS, the event is AXLiveRegionChanged. This also requires the user agent to provide a unique ID in the accessibility API notification identifying the unique node being removed.

When firing any of the above-mentioned change events, it is very useful to provide information about whether the change was caused by user input (as opposed to a timeout initiated from the page load, etc.). This allows the assistive technology to have different rules for presenting changes from the real world as opposed to from user action. Mouse hovers are not considered explicit user input because they can occur from accidental bumps of the mouse.

To expose whether a change occurred from user input:

• In ATK/AT-SPI this can be provided by appending the string ":system" to the event name when the user did not cause the change.
• In IAccessible2, which screen readers typically access in process on the same thread, the best practice is to expose the object attribute event-from-user-input:true on the accessible object for the event, if the user caused the change.

Exposing additional useful information about the context of the change:

• In ATK/AT-SPI and IAccessible2, the RELATION_MEMBER_OF relation on the accessible event's target accessible object SHOULD point to any ancestor with aria-atomic="true" (if any).
• In ATK/AT-SPI and IAccessible2, the container-live, container-relevant, container-busy, container-atomic object attributes SHOULD be exposed on the accessible event object, providing the computed value for the related WAI-ARIA properties. The computed value is the value of the closest ancestor. It is recommended to not expose the object attribute if the default value is used.

Additional MSAA events may be necessary:

• If something changes in an ancestor with a mapped MSAA role of ROLE_SYSTEM_ALERT, then an EVENT_SYSTEM_ALERT event SHOULD be fired for the alert. The alert role has an implied value of "assertive" for the aria-live property.
• Menu events may need to be fired. See Special Events for Menus.

The following table defines the accessibility API keyboard focus states and events.

• detail1 = 1 for the accessible object which just gained focus.
• detail1 = 0 for the accessible object which just lost focus.

There are two cases for selection:

• Single selection
• Multiple selection

In the single selection case, selection follows focus (see the section "Focus States and Events Table" for information about focus events). User agents MUST fire the following events when aria-selected changes:

If on a gridcell, row, option, or tab, fire UIA_SelectionItem_ElementSelectedEventId.

• object:selection-changed on the current container,
• object:state-changed:selected on the descendant accessible object whose selection has changed:
  • detail1 = 1 for the descendant which just became selected.
  • detail1 = 0 for the descendant which just became unselected.

The multiple selection case occurs when aria-multiselectable="true" on an element with a role that supports that property. User agents MUST fire the following events when aria-selected changes on a descendant, as follows:

The multiple selection case occurs when aria-multiselectable="true" on an element with a role that supports that property. There are several important aspects:

1. In Microsoft UIA, the Selection and SelectionItem Control Patterns expose the selection availability, state, and methods.
2. User agents MUST fire the following events when aria-selected changes on a descendant, as follows:

• object:selection-changed on the current container,
• object:state-changed:selected on any descendant accessible object whose selection has changed:
  • detail1 = 1 for any descendant which just became selected.
  • detail1 = 0 for any descendant which just became unselected.

• object:selection-changed on the current container,
• object:state-changed:selected on any descendant accessible object whose selection has changed:
  • detail1 = 1 for any accessible object which just became selected.
  • detail1 = 0 for any accessible object which just became unselected.

• the user agent MAY fire a single object:selection-changed event on the container, vs. multiple events, for performance,
• object:state-changed:selected on any descendant accessible object whose selection has changed:
  • detail1 = 1 for any accessible object which just became selected.
  • detail1 = 0 for any accessible object which just became unselected.

In accordance with Web Platform Design Principles, this specification provides no programmatic interface to determine if information is being used by Assistive Technologies. However, this specification does allow an author to present different information to users of Assistive Technologies from the information available to users who do not use Assistive Technologies. This is possible using many features of the ARIA and CORE-AAM specifications, just as this is possible using many other parts of the web technology stack. This content disparity could be abused to perform active fingerprinting of users of Assistive Technologies.

This specification introduces no new security considerations.

• 14-Nov-2022: add new AX API mappings for colindextext/rowindextext
• 4-Jan-2024: Fix: errant computed role for treegrid row
• 31-Oct-2023: Update UIA aria-readonly mappings
• 31-Oct-2023: Add aria-haspopup='grid' mappings
• 31-Oct-2023: Correct AXAPI notifications
• 26-Oct-2023: Remove UIA_DescribedBy property from aria-describedby UIA mappings
• 12-Oct-2023: Make haspopup='true' mapping identical to haspopup='menu'
• 1-Sep-2023: Fix AX API aria-haspopup mappings
• 25-Aug-2023: Add map for role=image (synonym of img)
• 17-Aug-2023: add normative expectations and examples for computedrole
• 16-Aug-2023: Update mapping for aria-errormessage
• 15-May-2023: Add computed role section and mappings
• 8-May-2023: update UIA ins/del
• 13-Apr-2023: Add mapping for aria-braillelabel and aria-brailleroledescription
• 9-Apr-2023: Update annotation roles AXAPI mapping
• 6-Apr-2023: Update aria-describedby and aria-description AXAPI
• 6-Apr-2023: Update role='meter' subrole for AXAPI
• 1-Feb-2023: remove AXAPI-specific 'menuitem in group' guidance
• 1-Feb-2023: Update AXAPI mapping for aria-keyshortcuts
• 1-Feb-2023: Update IA2 role='blockquote' map
• 1-Feb-2023: Update MSAA mapping for paragraph and time and caption

• 1-Nov-2022: draft privacy and security
• 13-Oct-2022: fix: remove label and legend
• 12-Oct-2022: Remove mappings for label and legend.
• 05-Apr-2021: Update ATK mappings for aria-colindex, aria-colspan, aria-colcount, aria-rowindex, aria-rowspan, and aria-rowcount.
• 06-Apr-2020: Update ATK mappings for alert and alertdialog.
• 25-Feb-2020: Add mappings for comment, mark, and suggestion roles. Include comment in calculation for aria-label and group position.
• 25-Feb-2020: Add mappings for aria-description.
• 03-Nov-2019: Remove explicit AXRoleDescription values for AX API. User agents should follow the guidance described in the note.
• 22-Oct-2019: Add mappings for strong and emphasis roles for AX API.
• 22-Oct-2019: Add mappings for code role for AX API.
• 21-Oct-2019: Add mappings for aria-colindextext and aria-rowindextext roles for ATK, IA2, and UIA.
• 21-Oct-2019: Add mappings for strong and emphasis roles for ATK, IA2, and UIA.
• 21-Oct-2019: Add mappings for code role for ATK, IA2, and UIA.
• 18-Sep-2019: Update MSAA mappings for subscript and superscript
• 10-Sep-2019: Add mappings for generic role.
• 09-Jul-2019: Add mappings for insertion and deletion roles.
• 14-May-2019: Add mappings for legend role.
• 14-May-2019: Add mappings for label role.
• 14-May-2019: Add mappings for time role.
• 25-Apr-2019: Add mappings for subscript and superscript roles.
• 25-Feb-2019: Add mappings for meter role.
• 05-Feb-2019: Update UIA state and property change events.
• 06-Jun-2018: Update UIA mappings for aria-placeholder.
• 04-Jun-2018: Add mappings for blockquote, caption, and paragraph roles.
• 05-Mar-2018: Add mention of AXTitle for exposing rendered labels for AXAPI.
• 05-Mar-2018: Add events for aria-label, aria-labelledby, and aria-describedby.

This section is non-normative.

The following people contributed to the development of this document.

• Aaron Leventhal
• Benjamin Beaudry
• Bogdan Brinza
• Carolyn MacLeod
• Daniel Montalvo
• Denis Ah-Kang
• Dominique Hazael-Massieux
• James Craig
• James Nurthen
• Jason Kiss
• joanmarie
• Joseph Scheuhammer
• Matt King
• Melanie Richards
• Peter Krautzberger
• Philippe Le Hegaret
• R Brown
• Rahim Abdi
• Richard Schwerdtfeger
• Sarah Higley
• Sayan Sivakumaran
• Scott O'Hara
• Steve Faulkner

• Rahim Abdi (Apple Inc.)
• NAVYA AGARWAL (Adobe)
• Mario Batušić (Fabasoft)
• Benjamin Beaudry (Microsoft Corporation)
• Curt Bellew (Oracle Corporation)
• Zoë Bijl (W3C Invited Experts)
• Gautier Chomel (EDRLab)
• Aleksandar Cindrikj (Netcetera)
• Keith Cirkel (Mozilla Foundation)
• Daniel Clark (Microsoft Corporation)
• James Craig (Apple Inc.)
• Chris Cuellar (Bocoup)
• Hidde de Vries (Logius)
• Joanmarie Diggs (Igalia)
• Howard Edwards (Bocoup)
• Tamsin Ewing (W3C)
• Mayuri Faldu (Navy Federal Credit Union)
• Betsy Fanning (PDF Association)
• Steve Faulkner (TetraLogical Services Ltd)
• Jaunita Flessas (Navy Federal Credit Union)
• Jane Fulton (Cisco)
• Bryan Garaventa (W3C Invited Experts)
• Rashmi Garimella (Google LLC)
• Matt Garrish (DAISY Consortium)
• Doug Geoffray (Microsoft Corporation)
• Ariella Gilmore (IBM Corporation)
• Taylore Givens (Microsoft Corporation)
• Shirisha Gubba (Google LLC)
• Eloisa Guerrero (Rakuten Group, Inc.)
• Jon Gunderson (University of Illinois)
• Oliver Habersetzer (SAP SE)
• Theo Hale (Microsoft Corporation)
• Sunny Hardasani (Adobe)
• Matthew Hardy (Adobe)
• Chris Harrelson (Google LLC)
• Peter Heumader (Fabasoft)
• Sarah Higley (Microsoft Corporation)
• Hans Hillen (TPGi)
• Isabel Holdsworth (TPGi)
• Stanley Hon (Microsoft Corporation)
• Michael Jackson (Microsoft Corporation)
• Jilin Jiang (Ant Group Co., Ltd.)
• Duff Johnson (PDF Association)
• Summer Jones (Thomson Reuters Corp.)
• Yuki Kamahori (Cybozu)
• William Kilian (Kilian Codes LLC)
• Matthew King (Meta)
• Zachary Kinsey (TargetStream Technologies)
• Daisuke Kobayashi (Cybozu)
• Greta Krafsig (The Washington Post)
• Peter Krautzberger (krautzource UG)
• Nina Krauß (SAP SE)
• JaEun Jemma Ku (University of Illinois)
• Joe Lamyman (TetraLogical Services Ltd)
• Charles LaPierre (Benetech)
• Philip Lazarevic (Level Access)
• Leo Lee (Microsoft Corporation)
• Aaron Leventhal (Google LLC)
• Brett Lewis (TPGi)
• Andy Luhrs (Microsoft Corporation)
• Sazzad Mahamud (Google LLC)
• Alison Maher (Microsoft Corporation)
• Gurpreet Kaur Mangera (Rakuten Group, Inc.)
• Mark McCarthy (University of Illinois)
• Eduardo Meza Etienne (Navy Federal Credit Union)
• Clay Miller (Microsoft Corporation)
• Hirotaka Minamida (Cybozu)
• Daniel Montalvo (W3C)
• Baldino Morelli (UsableNet)
• Jacques Newman (Microsoft Corporation)
• James Nurthen (Adobe)
• Scott O'Hara (Microsoft Corporation)
• Lola Odelola (W3C Invited Experts)
• Neil Osman (Evinced Inc.)
• Yusuke Oyama (Cybozu)
• Adam Page (Hilton)
• Michael Pennisi (Bocoup)
• Giacomo Petri (UsableNet)
• Noah Praskins (TPGi)
• Daniel Pöll (Fabasoft)
• Paul Rayius (Allyant)
• Adrian Roselli (W3C Invited Experts)
• Marco Sabidussi (UsableNet)
• Trisha Salas (Level Access)
• Stefan Schnabel (SAP SE)
• Harris Schneiderman (Deque Systems, Inc.)
• Raymond Schwartz (Navy Federal Credit Union)
• Cynthia Shelly (W3C Invited Experts)
• Tzviya Siegman (W3C)
• Arturo Silva (The Washington Post)
• Avneesh Singh (DAISY Consortium)
• Michael[tm] Smith (sideshowbarker) (W3C)
• Francis Storr (Intel Corporation)
• Jennifer Strickland (MITRE Corporation)
• Nobukiyo Sugisaki (Cybozu)
• Melanie Sumner (IBM Corporation)
• Alexander Surkov (Igalia)
• James Teh (Mozilla Foundation)
• Jocelyn Tran (Google LLC)
• Cybozu W3C (Cybozu)

This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

[HTML-AAM]

HTML Accessibility API Mappings 1.0. Scott O'Hara; Rahim Abdi. W3C. 10 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/html-aam-1.0/

[IAccessible2]

IAccessible2. Linux Foundation. URL: https://wiki.linuxfoundation.org/accessibility/iaccessible2/

[infra]

Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

[wai-aria]

Accessible Rich Internet Applications (WAI-ARIA) 1.0. James Craig; Michael Cooper et al. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria/

[WAI-ARIA-1.2]

Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper; Carolyn MacLeod. W3C. 6 June 2023. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/

[accname-1.2]

Accessible Name and Description Computation 1.2. Bryan Garaventa; Melanie Sumner. W3C. 10 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/accname-1.2/

[AT-SPI]

Assistive Technology Service Provider Interface. The GNOME Project. URL: https://gnome.pages.gitlab.gnome.org/at-spi2-core/libatspi/

[ATK]

ATK - Accessibility Toolkit. The GNOME Project. URL: https://developer.gnome.org/atk/stable/

[AXAPI]

The NSAccessibility Protocol for macOS. Apple, Inc. URL: https://developer.apple.com/documentation/appkit/nsaccessibility

[CORE-AAM-1.1]

Core Accessibility API Mappings 1.1. Joanmarie Diggs; Joseph Scheuhammer; Richard Schwerdtfeger; Michael Cooper; Andi Snow-Weaver; Aaron Leventhal. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/core-aam-1.1/

[dom]

DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/

[UI-AUTOMATION]

UI Automation. Microsoft Corporation. URL: https://docs.microsoft.com/en-us/windows/win32/winauto/ui-automation-specification

[UIA-EXPRESS]

The IAccessibleEx Interface. Microsoft Corporation. URL: https://docs.microsoft.com/en-us/windows/win32/winauto/iaccessibleex

[WAI-ARIA-ROADMAP]

Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap). Richard Schwerdtfeger. W3C. 4 February 2008. W3C Working Draft. URL: https://www.w3.org/TR/wai-aria-roadmap/

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.5