accessible nameEVENT_OBJECT_NAMECHANGEEVENT_OBJECT_NAMECHANGEProperyChangeEventPropertyChangeEventobject:property-change:accessible-nameTitleChangedNotificationaccessible descriptionEVENT_OBJECT_DESCRIPTIONHANGEEVENT_OBJECT_DESCRIPTIONCHANGEProperyChangeEventPropertyChangeEventobject:property-change:accessible-descriptionROLE_SYSTEM_PANE
If the object is in the accessibility tree, expose using the text pattern. In particular, this applies to cells within a table or grid with role="none", and to list items within a list with role="none".
If the object is in the accessibility tree, expose using the text pattern.
+
For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), expose each leaf descendant using the text pattern.
If the object is in the accessibility tree, expose as ROLE_SECTION. In particular, this applies to cells within a table or grid with role="none", and to list items within a list with role="none".
If the object is in the accessibility tree, expose as ROLE_SECTION
+
For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), expose each leaf descendant as ROLE_SECTION.
Not mapped
ROLE_SYSTEM_PANE
If the object is in the accessibility tree, expose using the text pattern. In particular, this applies to cells within a table or grid with role="presentation", and to list items within a list with role="presentation".
If the object is in the accessibility tree, expose using the text pattern.
+
For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), expose each leaf descendant using the text pattern.
If the object is in the accessibility tree, expose as ROLE_SECTION. In particular, this applies to cells within a table or grid with role="presentation", and to list items within a list with role="presentation".
If the object is in the accessibility tree, expose as ROLE_SECTION
+
For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), expose each leaf descendant as ROLE_SECTION.
Not mapped
@@ -1140,7 +1144,9 @@Button + Toggle Pattern. Localized Control Type is "toggleswitch".ROLE_TOGGLE_BUTTONAXCheckBoxAXSwitch'switch' Double check the role descriptiontab
@@ -2264,6 +2270,14 @@ object:state-changed:enabled and object:state-changed:sensitivearia-describedbyaria-dropeffect (property)aria-label and aria-labelledbyaria-pressed (state)EVENT_OBJECT_STATECHANGESVG Accessibility API Mappings (SVG-AAM) defines how user agents map Scalable Vector Graphics (SVG) [[!SVG]] markup to platform accessibility application programming interfaces (APIs). It is intended for SVG user agent developers responsible for SVG accessibility in their user agent.
-This specification extends the Core Accessibility API Mappings 1.1 (CORE-AAM) [[!CORE-AAM]] and the Accessible Name and Description: Computation and API Mappings 1.1 (ACCNAME-AAM) [[!ACCNAME-AAM]] specifications for user agents. It leverages those core mappings and provides SVG-specific guidance to define how the SVG user agent must respond to keyboard focus and Role; State and Property attributes provided in Web content via WAI-ARIA [[!WAI-ARIA]]. The SVG-AAM also adapts the ACCNAME-AAM to make use of standard SVG features used to compute accessible names and description information exposed by platform accessibility APIs. These features allow SVG authors to create accessible rich internet applications, including charts, graphs, and other drawings.
+SVG Accessibility API Mappings (SVG-AAM) defines how user agents map Scalable Vector Graphics (SVG) [[!SVG]] markup to platform accessibility application programming interfaces (APIs). It is intended for SVG user agent developers responsible for SVG accessibility in their user agent.
+This specification allows SVG authors to create accessible rich internet applications, including charts, graphs, and other drawings. It does this by extending the Core Accessibility API Mappings 1.1 (CORE-AAM) [[!CORE-AAM]] and the Accessible Name and Description: Computation and API Mappings 1.1 (ACCNAME-AAM) [[!ACCNAME-AAM]] specifications for user agents. It leverages those core mappings and provides SVG-specific guidance to define how the SVG user agent must respond to keyboard focus and role, state, and property attributes provided in Web content via WAI-ARIA [[!WAI-ARIA]]. The SVG-AAM also adapts the ACCNAME-AAM to make use of standard SVG features used to compute accessible names and description information exposed by platform accessibility APIs.
The SVG-AAM is part of the WAI-ARIA suite described in the WAI-ARIA Overview.
In traditional Graphical User Interface (GUI) applications, components of the User Interface (UI) are displayed when needed and hidden when not needed based on user interactions. Accessibility APIs are used to communicate semantic information about the user interface to assistive technology software used by people with disabilities. These APIs constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular UI component is a menu, button, text field, list box, etc.
-In traditional SVG documents most SVG elements do not provide semantic information of value to assistive technologies as they represent low level vector graphics drawing directives. Consequently, it is when the author provides alternative text, descriptions, or WAI-ARIA semantics when that element has meaning to assistive technologies. SVG 2 now incorporates traditional keyboard navigation from HTML 5. Therefore, the user agent provides focus navigation to SVG elements known to receive focus by default or to that may receive focus through the use of tabindex. Assistive technologies obtain the essential semantic information from the Document Object Model (DOM) through user agent mappings to platform Accessibility API.
+In traditional Graphical User Interface (GUI) applications, components of the User Interface (UI) are displayed when needed and hidden when not needed based on user interactions. Accessibility APIs are used to communicate semantic information about the user interface to assistive technology software used by people with disabilities. These APIs constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular UI component is a menu, button, text field, list box, etc.
+In traditional SVG documents most SVG elements do not provide semantic information of value to assistive technologies as they represent low level vector graphics drawing directives. Consequently, it is when the author provides alternative text, descriptions, or WAI-ARIA semantics when that element has meaning to assistive technologies. SVG 2 now incorporates traditional keyboard navigation from HTML 5. Therefore, the user agent provides focus navigation to SVG elements known to receive focus by default or to that may receive focus through the use of tabindex. Assistive technologies obtain the essential semantic information from the Document Object Model (DOM) through user agent mappings to platform Accessibility API.
Both Scalable Vector Graphics (SVG) 1 [[SVG1]] and Scalable Vector Graphics (SVG) 1.1 [[SVG11]] included elements for accessibility purposes, such as <title> and <desc> , but prior to this specification there was no normative guidance as to how user agents should expose this information to assistive technologies, or how to integrate it with host languages and validators that support WAI-ARIA.
SVG closely aligns with the DOM Level 3 Core and HTML5 events to facilitate JavaScript use. Through the use of technologies such as JavaScript, Ajax, and CSS authors can make SVG look and behave more interactive without having to reload the page with each user interaction. In SVG, authors are able to produce accessible rich interactive charts, and drawings allowing the author to dynamically supply their intended semantics through through the use of WAI-ARIA. WAI-ARIA enables rich SVG drawn Internet applications to have the same accessibility features as GUI applications. Authors may include WAI-ARIA in their markup and user agents translate the WAI-ARIA markup to the platform accessibility APIs.
-For an introduction to WAI-ARIA, see the WAI-ARIA Overview. The Core Accessibility API Mappings specification how WAI-ARIA roles, states, and properties should be supported in user agents using platform accessibility APIs. It is part of a set of resources that define and support the WAI-ARIA specification which includes the following documents:
+For an introduction to WAI-ARIA, see the WAI-ARIA Overview. The Core Accessibility API Mappings specification how WAI-ARIA roles, states, and properties should be supported in user agents using platform accessibility APIs. It is part of a set of resources that define and support the WAI-ARIA specification which includes the following documents:
This specification begins by providing a general overview of accessibility APIs and the accessible object hierarchy known as the accessibility tree. The following sections define how SVG host language elements, with or without WAI-ARIA roles, states, and properties applied map content to accessibility APIs. Other sections give guidance on calculating text alternatives, mapping actions to events, event processing, special document handling procedures, and error handling.
+This specification begins by providing a general overview of accessibility APIs and the accessible object hierarchy known as the accessibility tree. The following sections define how SVG host language elements, with or without WAI-ARIA roles, states, and properties applied map content to accessibility APIs. Other sections give guidance on calculating text alternatives, mapping actions to events, event processing, special document handling procedures, and error handling.
This guide relies heavily on the accessibility API mappings defined in the [[CORE-AAM]] and [[ACCNAME-AAM]] specifications but defines changes in mappings due to features in the [[SVG]] host language. Key areas of difference are:
To provide access to desktop GUI applications, assistive technologies originally used heuristic techniques to determine the meaning of the user interface and build an alternative off-screen model. For example, a row of labels displayed horizontally near the top of an application window might be a menu. Labels with a border drawn around them might be buttons. Heuristic techniques are not always accurate, however, and require assistive technologies to be updated whenever the software application is updated.
A much better technique is for the software application to provide the necessary information for interoperability with assistive technology. To meet this need, platform owners have developed specialized interfaces, called accessibility API s, which can be used to communicate accessibility information about user interfaces to assistive technologies.
-In Web pages the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. User agents map DOMto accessibility APIs in the same way desktop applications map UI components do to support assistive technologies with the expectation that the information passed from the DOM matches the semantic intent of the author.
+In Web pages the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. User agents map DOMto accessibility APIs in the same way desktop applications map UI components do to support assistive technologies with the expectation that the information passed from the DOM matches the semantic intent of the author.
When the first rich Internet applications came out, authors created custom UI controls where the author created content that visibly matched the intent of the author but not the semantic intent. This is because there was no vehicle in early versions of HTML or SVG to provide the necessary semantics needed for user agents to expose them to assistive technologies through the platform accessibility APIs of the underlying operating system, throughout a web applications life cycle. This problem is worse in SVG as most its elements have no intrinsic host language semantics that make sense to users of assistive technologies as it consists primarily of low level drawing calls. Today, the information needed is provided when developers use WAI-ARIA to supply semantics in the form of role, state, and property information for elements. The screen reader or other assistive technology uses the semantic information exposed via the accessibility API to provide an alternative rendering of an application that is meaningful to a user.
Accessibility APIs covered by this document are:
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.
The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.
The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.
This specification indicates whether a section is normative or informative and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.
-Normative sections provide requirements that user agents must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Keywords for use in RFCs to indicate requirement levels [RFC2119]. RFC-2119 keywords are formatted in uppercase and contained in a strong element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.
This specification indicates whether a section is normative or informative and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.
+Normative sections provide requirements that user agents must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Keywords for use in RFCs to indicate requirement levels [[rfc2119]]. RFC-2119 keywords are formatted in uppercase and contained in a strong element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.
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.
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.
+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.
aalinkRole MappingsRole Mappingscirclenone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingnone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappingsellipsenone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingnone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappingsrectnone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappingsnone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole MappingsscriptnonetextThe use of the group role here is that of generic container for text. More work is required to address what additional text interfaces are exposed through platform accessibility API services.
grouptextPathThe use of the group role here is that of generic container for text. More work is required to address what additional text interfaces are exposed through platform accessibility API services.
grouptitlenonetspanThe use of the group role here is that of generic container for text. More work is required to address what additional text interfaces are exposed through platform accessibility API services.
groupusenone role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole MappingsThis section describes how to expose WAI-ARIA states and object properties. SVG user agents MUST conform to the State and Property Mapping accessibility API computational requirements in [[!CORE-AAM]]. +
This section describes how to expose WAI-ARIA states and object properties. SVG user agents MUST conform to the State and Property Mapping accessibility API computational requirements in [[!CORE-AAM]].
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. Conforming user agents MUST support the [[!CORE-AAM]] Events mappings.
+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. Conforming user agents MUST support the [[!CORE-AAM]] Events mappings.
Placeholder for references
- + +The following people contributed to the development of this document.
+This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR) under contract number ED-OSE-10-C-0067. 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.
+