From 6bf835b4b8c1f4f9bfbd34a3de345712bb882e81 Mon Sep 17 00:00:00 2001 From: Ian Pouncey Date: Mon, 26 Mar 2018 17:57:04 +0100 Subject: [PATCH] Partially updates SVG AAM links and references All incorrect text other than the following outstanding issues are fixed in this commit: - "Normative" and "Informative" definitions do not appear in Important Terms section, and therefore the links do not work. - #issue-2 link in A.2 Issue Summary only works if mapping table is in table view or the textPath details element is expanded. - Links to core-aam mapping table don't work, as all IDs on the summary elements are 'undefined', and the details elements don't open automatically. Suggest linking to ARIA draft, i.e. https://w3c.github.io/aria/#link instead of https://w3c.github.io/core-aam/#role-map-link --- common/biblio.js | 2 +- index.html | 852 +++++++++++++++++++++++------------------------ 2 files changed, 427 insertions(+), 427 deletions(-) diff --git a/common/biblio.js b/common/biblio.js index 1334315..cbc2bdc 100644 --- a/common/biblio.js +++ b/common/biblio.js @@ -203,7 +203,7 @@ var biblio = { }, "SVG2": { "title": "Scalable Vector Graphics (SVG) 2", - "href": "http://www.w3.org/TR/2015/WD-SVG2-20150915/", + "href": "https://www.w3.org/TR/SVG2/", "status": "WD", "publisher": "W3C", "authors": [ diff --git a/index.html b/index.html index f6b4405..76a3edd 100644 --- a/index.html +++ b/index.html @@ -13,7 +13,7 @@ @@ -182,43 +182,43 @@

- SVG Accessibility API Mappings (SVG-AAM) defines how - user agents map - Scalable Vector Graphics (SVG) [[!SVG2]] markup - to platform accessibility - application programming interfaces (APIs). - It is intended for SVG user agent developers + SVG Accessibility API Mappings (SVG-AAM) defines how + user agents map + Scalable Vector Graphics (SVG) [[!SVG2]] 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 + 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 + The SVG-AAM is part of the + WAI-ARIA suite described in the WAI-ARIA Overview.

- This is an Editor's Draft of SVG Accessibility API Mappings 1.0 by the SVG Accessibility Task Force, a joint task force of the Accessible Rich Internet Applications Working Group and the SVG Working Group. It extends Core Accessibility API Mappings 1.1 [[!CORE-AAM]] and Accessible Name and Description: Computation and API Mappings 1.1 [[!ACCNAME-AAM]], and is part of a suite of similar technology-specific Accessibility API Mappings specifications. This version expands the set of mappings for SVG features. + This is an Editor's Draft of SVG Accessibility API Mappings 1.0 by the SVG Accessibility Task Force, a joint task force of the Accessible Rich Internet Applications Working Group and the SVG Working Group. It extends Core Accessibility API Mappings 1.1 [[!CORE-AAM]] and Accessible Name and Description: Computation and API Mappings 1.1 [[!ACCNAME-AAM]], and is part of a suite of similar technology-specific Accessibility API Mappings specifications. This version expands the set of mappings for SVG features.

- Feedback on any aspect of the specification is accepted. - For this publication, the SVG Accessibility Task Force + Feedback on any aspect of the specification is accepted. + For this publication, the SVG Accessibility Task Force particularly seeks feedback on the following questions:

The editors have highlighted particularly problematic - aspects of the specification, + aspects of the specification, or areas where further clarification is likely to be required, in the form of Editor's Notes boxes throughout the text. Comments on these issues would be particularly appreciated.

- To comment, file an issue in the W3C ARIA GitHub repository, using the "graphics" label in the issue. If this is not feasible, send email to public-svg-a11y@w3.org (comment archive). Comments are requested by 30 September 2016. In-progress updates to the document may be viewed in the publicly visible editors' draft. + To comment, file an issue in the W3C SVG Accessibility API Mappings GitHub repository. If this is not feasible, send email to public-svg-a11y@w3.org (comment archive). In-progress updates to the document may be viewed in the publicly visible editors' draft.

Introduction

- 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 - semantics - about the user interface to - assistive technologies + 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 + semantics + about the user interface to + assistive technologies 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 or complex documents. - For example, screen-reading software for blind users can determine - whether a particular UI component + 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 or complex documents. + For example, screen-reading software for blind users can determine + whether a particular UI component is a menu, button, text field, list box, etc. It can also present the information in tables or lists in a way that provides context for each piece of text. -

+

- For web documents and applications, - the essential semantic information is encapsulated - within the Document Object Model (DOM). - Assistive technologies obtain this information from the user agent (web browser), - which maps elements and attributes + For web documents and applications, + the essential semantic information is encapsulated + within the Document Object Model (DOM). + Assistive technologies obtain this information from the user agent (web browser), + which maps elements and attributes to the platform Accessibility API.

- In Scalable Vector Graphics (SVG) documents, + In Scalable Vector Graphics (SVG) documents, most SVG elements - do not provide semantic information of value to assistive technologies. - Instead, they represent low-level vector graphics drawing directives. - That element only has meaning to assistive technologies + do not provide semantic information of value to assistive technologies. + Instead, they represent low-level vector graphics drawing directives. + That element only has meaning to assistive technologies if the author provides alternative text, descriptions, or WAI-ARIA semantics.

Both version 1 [[SVG1]] and version 1.1 [[SVG11]] of the SVG specifications - included elements for defining accessible names and descriptions - (<title> and <desc>). - However, prior to this specification, there was no normative guidance - as to how user agents should expose this information to assistive technologies, + included elements for defining accessible names and descriptions + (<title> and <desc>). + However, 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. There was similarly no guidance on how user agents should make interactive SVG keyboard accessible.

- SVG 2 now incorporates keyboard navigation based on the established model from HTML 5. - The user agent - provides sequential focus navigation to SVG elements - that are interactive by default (links and audio/video elements with controls), - or that the author has indicated may receive focus - (through the use of tabindex attribute). + SVG 2 now incorporates keyboard navigation based on the established model from HTML 5. + The user agent + provides sequential focus navigation to SVG elements + that are interactive by default (links and audio/video elements with controls), + or that the author has indicated may receive focus + (through the use of tabindex attribute). Focus may also be set or removed programmatically by scripts, - so that authors may implement + so that authors may implement more complex keyboard focus patterns.

SVG closely aligns with the core DOM Standard [[DOM]], supporting JavaScript manipulation of the graphic in interactive environments. - Through the use of JavaScript, CSS, and related APIs, - authors can make SVG look and behave as an interactive application, + Through the use of JavaScript, CSS, and related APIs, + authors can make SVG look and behave as an interactive application, to produce rich interactive charts and drawings.

To allow the author to express and dynamically update their intended semantics - in both static and interactive graphics, - SVG 2 supports the use of + in both static and interactive graphics, + SVG 2 supports the use of WAI-ARIA roles, states, and properties. - Authors may include - WAI-ARIA attributes in their markup - and user agents will translate it + Authors may include + WAI-ARIA attributes in their markup + and user agents will translate it to the platform accessibility APIs.

- WAI-ARIA enables rich SVG-drawn Internet applications - to have the same accessibility features as + WAI-ARIA enables rich SVG-drawn Internet applications + to have the same accessibility features as GUI applications installed on their operating system. In complex static graphics, WAI-ARIA provides the missing document structure that is provided in HTML by semantic elements.

- For an introduction to WAI-ARIA, - see the WAI-ARIA Overview. - The SVG Accessibility API Mappings specification (this document) - defines how WAI-ARIA features - interact with the native semantics of the SVG language. - It is part of a set of resources that define and support - the WAI-ARIA specification, - including the following documents: + For an introduction to WAI-ARIA, + see the WAI-ARIA Overview. + The SVG Accessibility API Mappings specification (this document) + defines how WAI-ARIA features + interact with the native semantics of the SVG language. + It is part of a set of resources that define and support + the WAI-ARIA specification, + including the following documents:

- This specification begins by providing - a general overview of accessibility APIs - and the hierarchy of accessible objects - known as the accessibility tree. - The following sections define how SVG host language elements and content — - with or without WAI-ARIA + This specification begins by providing + a general overview of accessibility APIs + and the hierarchy of accessible objects + known as the accessibility tree. + The following sections define how SVG host language elements and content — + with or without WAI-ARIA roles, states, and properties applied — - map to accessibility APIs. - Other sections give guidance on calculating text alternatives, - mapping actions to events, + map 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 + This guide relies heavily on the + accessibility API mappings defined in the Core Accessibility API Mappings and Accessible Name and Description specifications ([[CORE-AAM]] and [[ACCNAME-AAM]]) - but defines changes in mappings due to features in the SVG host language [[SVG2]]. + but defines changes in mappings due to features in the SVG host language [[SVG2]]. Key areas of difference stem from the intrinsic host language semantics of SVG:

The Accessibility Tree and the DOM Tree

- The accessibility tree - and the DOM tree are parallel structures. - Roughly speaking, the accessibility tree is a subset + The accessibility tree + and the DOM tree are parallel structures. + Roughly speaking, the accessibility tree is a subset of the flattened DOM tree, which is then augmented to - include the user interface objects - of the user agent + include the user interface objects + of the user agent as well as 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. - An element could be exposed because it may fire an accessibility event - or because it has a property, - relationship or feature which needs to be exposed. + Accessible objects are created + in the accessibility tree for every + DOM element + that should be exposed to an + assistive technology. + An element could be exposed because it may fire an accessibility event + or because it has a property, + relationship or feature which needs to be exposed.

Generally, if a DOM element can be omitted from the accessibility tree - without affecting meaning, 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, + without affecting meaning, 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.

@@ -526,41 +526,41 @@

The Accessibility Tree and the DOM

Normative User Agent Implementation Requirements for SVG

- This specification marks certain sections - as non-normative, also called informative. + This specification marks certain sections + as non-normative, also called informative. The classification applies to the entire section. - All other sections provide normative requirements. - A statement "This section is non-normative" + All other sections provide normative requirements. + A statement "This section is non-normative" applies to all its sub-sections, unless otherwise indicated. In addition, all text boxes labelled "Note" are informative.

- 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 an - 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. + 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 an + 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 and notes provide information useful - to understanding the specification. - Such sections may contain examples of recommended practice, - but it is not required to follow such recommendations + Informative sections and notes 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.

@@ -571,32 +571,32 @@

Important Terms

Supporting Keyboard Navigation

- Enabling keyboard navigation in web applications - is a necessary step toward making accessible web applications possible. + Enabling keyboard navigation in web applications + is a necessary step toward making accessible web applications possible. Not only is the keyboard the primary input device for many users, - but other accessibile input devices use keyboard events + but other accessibile input devices use keyboard events to communicate with the user agent.

- The Scalable Vector Graphics (SVG) 1 [[SVG1]] and + The Scalable Vector Graphics (SVG) 1 [[SVG1]] and 1.1 [[SVG11]] specifications included only very limited keyboard support - (access keys for animations). - Many user agents implemented tabbed focus for links, - but there was no declarative or scripted means + (access keys for animations). + Many user agents implemented tabbed focus for links, + but there was no declarative or scripted means for authors to control this behavior. Scalable Vector Graphics (SVG) 2 [[SVG2]] introduces keyboard navigation - and focus control + and focus control based on the HTML tabindex model.

-

- Conforming user agents MUST conform to - Supporting Keyboard Navigation +

+ Conforming user agents MUST conform to + Supporting Keyboard Navigation requirements in the Core Accessibility API Mappings [[!CORE-AAM]].

- +

- The SVG Accessibility Task Force intends to develop - more detailed guidelines for authors and user agents + The SVG Accessibility Task Force intends to develop + more detailed guidelines for authors and user agents regarding navigation in graphical documents.

@@ -604,62 +604,62 @@

Supporting Keyboard Navigation

Mapping WAI-ARIA to Accessibility APIs

- WAI-ARIA support + WAI-ARIA support was formally introduced to SVG in Scalable Vector Graphics (SVG) 2 [[SVG2]], - which allows ARIA attributes to be used in the default namespace. - This section defines how WAI-ARIA semantics are exposed to assistive technologies - through platform Accessibility APIs - and how SVG elements are mapped to + which allows ARIA attributes to be used in the default namespace. + This section defines how WAI-ARIA semantics are exposed to assistive technologies + through platform Accessibility APIs + and how SVG elements are mapped to Accessibility APIs based on WAI-ARIA.

General rules for exposing WAI-ARIA semantics

- SVG user agents MUST conform to General rules for exposing WAI-ARIA semantics in the Core Accessibility API Mappings [[!CORE-AAM]], + SVG user agents MUST conform to General rules for exposing WAI-ARIA semantics in the Core Accessibility API Mappings [[!CORE-AAM]], with the additions described in the following sub-sections.

- +

Excluding Elements from the Accessibility Tree

Certain elements in the DOM are not exposed via the accessibility API. - The section Excluding Elements from the Accessibility Tree + The section Excluding Elements from the Accessibility Tree of the Core Accessibility API Mappings [[CORE-AAM]] outlines the general rules for excluding elements. One factor is whether host language semantics specify that the element should not be displayed.

- The SVG language defines numerous elements + The SVG language defines numerous elements that fit this criteria. Many SVG elements are never directly rendered to the screen, - while others may or may not be rendered or displayed, + while others may or may not be rendered or displayed, depending on context or CSS styling. Elements which are neither perceivable nor interactive - should not be included in the accessibility tree + should not be included in the accessibility tree exposed to accessibility APIs. This section details the expected interpretation of SVG host language semantics.

-

The other factors for excluding elements, +

The other factors for excluding elements, as described in the Core Accessibility API Mappings, are as follows:

  • If the first mappable role provided by the author - is none or presentation, the element must not be exposed. However, note that a number of features of an element, such as interactivity, can cause an author-supplied role of none or presentation to be ignored.
    • -
  • If the element or an ancestor has an + is none or presentation, the element must not be exposed. However, note that a number of features of an element, such as interactivity, can cause an author-supplied role of none or presentation to be ignored.
    • +
  • If the element or an ancestor has an aria-hidden value of true, it should not be exposed.
  • If an ancestor of the element has a used role which has the characteristic "Children Presentational: True" - in the WAI-ARIA specifications [[WAI-ARIA]], + in the WAI-ARIA specifications [[WAI-ARIA]], the child element should not be exposed. For example, the roles - button and + button and img exclude all child content from being directly included in the accessibility tree. @@ -668,28 +668,28 @@

    Excluding Elements from the Accessibility Tree

    In all cases, an element will not be excluded if it can currently receive focus based on user interaction. Consult the original document [[CORE-AAM]] for the normative text.

Links to CORE-AAM and ARIA 1.1 will need to be updated after clarifications with respect to these points have been pushed to the master versions of those specifications.

- +

- Elements which are never directly rendered to screen, + Elements which are never directly rendered to screen, nor represented by an interactive region in a graphic, do not need a corresponding accessible object. - User agents MUST NOT include any elements, or their descendant content, as an accessible object in the accessibility tree that are indicated as no accessible object created in the SVG Element Mapping Table. - User agents SHOULD also exclude + User agents MUST NOT include any elements, or their descendant content, as an accessible object in the accessibility tree that are indicated as no accessible object created in the SVG Element Mapping Table. + User agents SHOULD also exclude any other element defined by past or future SVG specifications or modules - that specifically indicate the element is never directly rendered. + that specifically indicate the element is never directly rendered.

- For example, elements that represent - filters, gradients, or gradient stops + For example, elements that represent + filters, gradients, or gradient stops will never create an accessible object. - Shape elements or image elements that are included + Shape elements or image elements that are included in an SVG definitions section or as part of a pattern - will also not have accessible objects, - because the semantics of the ancestor + will also not have accessible objects, + because the semantics of the ancestor defs or pattern element preclude that entire DOM subtree from being represented in the accessibility tree. -

+

Elements that are excluded from the accessibility tree might still be used in the name and description computation of another element, as defined in the Name and Description section. Non-rendered elements may also be used as the templates @@ -713,26 +713,26 @@

Excluding Elements from the Accessibility Tree

or to select between alternate versions of content.

- SVG user agents MUST NOT + SVG user agents MUST NOT expose to accessibility APIs - any elements that are not rendered + any elements that are not rendered because of conditional processing attributes on that element or because of the position of that element within a switch construct. - The switch element itself SHOULD + The switch element itself SHOULD be omitted as if it had a role of none or presentation.

- +

- The rendering of SVG elements is also affected by CSS styling properties, + The rendering of SVG elements is also affected by CSS styling properties, which may be specified using stylesheet rules, inline styles, presentation attributes, or animations. Regardless of how the style property is specified, - the effect depends on the final computed value + the effect depends on the final computed value determined by the CSS cascade [[CSS-CASCADE-3]]. - User agents MUST NOT + User agents MUST NOT expose to accessibility APIs - any element that is not rendered - because its computed style includes - a value of none + any element that is not rendered + because its computed style includes + a value of none for the display property.

@@ -751,28 +751,28 @@

Excluding Elements from the Accessibility Tree

according to the computed value of the visibility property, nor interactive to pointer users. according to the pointer-events property. - User agents SHOULD NOT + User agents SHOULD NOT expose to accessibility APIs - any element that is hidden in this sense, + any element that is hidden in this sense, unless the author explicitly overrides the hiding by setting the aria-hidden attribute to false.

In the case of container elements (such as g or svg), - the element is not considered hidden + the element is not considered hidden if any of its descendent content is visible or can receive user events, regardless of the computed value of visibility on the element itself. Similarly, a use element may include - visible or interactive component graphics, + visible or interactive component graphics, despite having style properties that would cause an individual shape element to be hidden. - The use element MUST be considered visible or interactive + The use element MUST be considered visible or interactive if any elements within its shadow tree are visible or interactive. (The container or the use element may, however, still be considered presentational if it does not have any other reason to include it in the accessibility tree.) A shape element with markers is visible or interactive if any of its markers are visible or interactive. -

+

In HTML and in other CSS-styled documents, @@ -788,7 +788,7 @@

Excluding Elements from the Accessibility Tree

In many cases, the invisible elements are of semantic importance (because they are interactive) while visible elements are presentational only. - For example, large invisible elements are often used + For example, large invisible elements are often used to provide easy-to-hit targets for points in a map or datachart. Because these elements react to pointer events, they are effectively perceivable to pointer users, @@ -812,16 +812,16 @@

Excluding Elements from the Accessibility Tree

An element that is currently positioned off-screen, or that is obscured by other elements, - is not considered hidden. + is not considered hidden. User agents should expose this state through other means, as described in the State and Property Mapping section of the Core Accessibility API Mappings [[CORE-AAM]]. - +

- +

- Various other style properties and geometric attributes (of an element itself or an ancestor element) can make an element invisible. For simplicity, flexibility, and performance reasons, these are not considered a hiding method that excludes elements from the accessibility tree. + Various other style properties and geometric attributes (of an element itself or an ancestor element) can make an element invisible. For simplicity, flexibility, and performance reasons, these are not considered a hiding method that excludes elements from the accessibility tree.

When using properties other than display or visibility to hide inactive content, authors can use the aria-hidden attribute to indicate that assistive technologies should ignore the element and its descendents. @@ -868,16 +868,16 @@

Excluding Elements from the Accessibility Tree

The editors welcome feedback and suggestions (in GitHub Issue #6) - on alternative ways to represent + on alternative ways to represent this hidden alternative content in a way consistent with user agent and accessibility API implementations.

- +

Including Elements in the Accessibility Tree

- +

Many SVG elements—although rendered to the screen—do not have an intrinsic semantic meaning. Instead, they represent components of the visual presentation of the document. @@ -889,18 +889,18 @@

Including Elements in the Accessibility Tree

However, any rendered SVG element may have semantic meaning. Authors indicate the significance of the element by including - alternative text content or + alternative text content or WAI-ARIA attributes. This section defines the rules for including normally-omitted elements in the accessibility tree. -

+

- The following graphical and container elements in the SVG namespace + The following graphical and container elements in the SVG namespace SHOULD NOT be included in the accessibility tree, - except as described in this section: + except as described in this section:

    -
  • +
  • shape elements (circle, ellipse, @@ -941,10 +941,10 @@

    Including Elements in the Accessibility Tree

Although these elements are omitted from the accessibility tree, - their child content + their child content is still processed, - as if it was a direct child of the nearest ancestor node in the DOM tree that is included in the accessibility tree. + as if it was a direct child of the nearest ancestor node in the DOM tree that is included in the accessibility tree. In other words, the markup elements are treated as if they had a role of none or presentation.

@@ -958,31 +958,31 @@

Including Elements in the Accessibility Tree

(default or author-supplied) role of presentation.

- +

- SVG user agents MUST provide - an accessible object in the accessibility tree + SVG user agents MUST provide + an accessible object in the accessibility tree for rendered SVG elements that meet any of the following criteria, - unless they are excluded from the accessibility tree per the rules + unless they are excluded from the accessibility tree per the rules in Excluding Elements from the Accessibility Tree:

  • - It has at least one direct child + It has at least one direct child ‘title’ element or ‘desc' element that is not empty after trimming whitespace. User agents MAY include elements with these child elements without checking for valid text content.
  • - It has a non-empty + It has a non-empty (after trimming whitespace) - ‘aria-label’ attribute or + ‘aria-label’ attribute or ‘aria-roledescription’ attribute.
  • It has an - ‘aria-labelledby’ attribute - or + ‘aria-labelledby’ attribute + or ‘aria-describedby’ attribute containing valid IDREF tokens. User agents MAY include elements with these attributes without checking for validity.
  • @@ -990,20 +990,20 @@

    Including Elements in the Accessibility Tree

    'tabindex' attribute.
  • - The author has provided an allowed, non-abstract + The author has provided an allowed, non-abstract WAI-ARIA role other than none or presentation.
  • - It meets any of the criteria listed in the section - Including Elements in the Accessibility Tree - of the Core Accessibility API Mappings specification [[!CORE-AAM]]. + It meets any of the criteria listed in the section + Including Elements in the Accessibility Tree + of the Core Accessibility API Mappings specification [[!CORE-AAM]].

- At the time of drafting this document, + At the time of drafting this document, those criteria are as follows: @@ -1022,14 +1022,14 @@

Including Elements in the Accessibility Tree

should be consulted for the normative text.

- The exception for hidden elements means that + The exception for hidden elements means that SVG metadata elements or other non-rendered content may be used in the accessible name and description of another element without themselves being included in the accessiblity tree. - For example, current best practice + For example, current best practice for fallback browser support - is to use aria-labelledby and aria-describedby + is to use aria-labelledby and aria-describedby to redundantly link to title and desc child elements. Including these elements as separate nodes in the tree @@ -1046,9 +1046,9 @@

Including Elements in the Accessibility Tree

  • - A rendered element + A rendered element (or instance of an element in a use-element shadow tree) - with a positive integer value + with a positive integer value for the tabindex attribute, or which is focusable by default and has not been removed from the tab order with a negative integer tabindex attribute, @@ -1064,13 +1064,13 @@

    Including Elements in the Accessibility Tree

With regards to pointer events, which bubble up the DOM tree, - the exact element that receives the event may not have semantic meaning + the exact element that receives the event may not have semantic meaning (that is, it may still be presentational). - However, the ability to receive pointer events overrides any exclusion + However, the ability to receive pointer events overrides any exclusion based on the visibility: hidden style property.

- The tabindex attribute + The tabindex attribute and the pointer-events property have no impact on elements which are not rendered at all, because of the display: none property @@ -1079,16 +1079,16 @@

Including Elements in the Accessibility Tree

- +

Conflicts between native markup semantics and WAI-ARIA

- SVG user agents - MUST conform to - Conflicts between native markup semantics and WAI-ARIA in the Core Accessibility API Mappings [[!CORE-AAM]] + SVG user agents + MUST conform to + Conflicts between native markup semantics and WAI-ARIA in the Core Accessibility API Mappings [[!CORE-AAM]] where the host language is SVG and the native semantics are as described in - the SVG Element Mapping Table, + the SVG Element Mapping Table, the State and Property Mapping section, and the Special Processing Requiring Additional Computation section.

@@ -1104,70 +1104,70 @@

Conflicts between native markup semantics and ‘aria-roledescription’.

- +

Exposing attributes that do not directly map to accessibility API properties

SVG user agents MUST conform to Exposing attributes that do not directly map to accessibility API properties in the Core Accessibility API Mappings [[!CORE-AAM]].

- +

Role mapping

- Platform accessibility APIs - traditionally have had a finite set of - predefined roles that are expected - by assistive technologies + 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.

- WAI-ARIA + WAI-ARIA only supports one active role at a time. - However, multiple roles may 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 font families + However, multiple roles may 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 font families in case the first choice font is not supported. This allows the role taxonomy to be extended in future for specialized applications. The entire role string is exposed to accessibility technologies where possible, - so they can respond appropriately + so they can respond appropriately even if there is no equivalent role in the platform API.

- +

General Rules

SVG user agents MUST conform to the Role Mapping General Rules accessibility API computational requirements in the Core Accessibility API Mappings [[!CORE-AAM]].

- +

SVG Element Mapping Table

- This section defines how elements in SVG2 - map to WAI-ARIA roles and platform accessibility APIs + This section defines how elements in SVG2 + map to WAI-ARIA roles and platform accessibility APIs based on their native host language semantics, - including which WAI-ARIA roles may be applied. - This section refers directly to both the + including which WAI-ARIA roles may be applied. + This section refers directly to both the Role Mappings in the Core Accessibility API Mappings [[!CORE-AAM]] specification and the Role Mappings in the Graphics Accessibility API Mappings [[!GRAPHICS-AAM]] specification, - which define how WAI-ARIA roles are mapped to platform accessibility APIs. + which define how WAI-ARIA roles are mapped to platform accessibility APIs.

@@ -1198,15 +1198,15 @@

SVG Element Mapping Table

- - + + - + + @@ -1247,7 +1247,7 @@

SVG Element Mapping Table

@@ -1304,7 +1304,7 @@

SVG Element Mapping Table

-
- Table describing mapping of WAI-ARIA roles + Table describing mapping of WAI-ARIA roles to accessibility APIs.
SVG Element - Default Platform + Default Platform WAI-ARIA Role Mappings @@ -1183,8 +1183,8 @@

SVG Element Mapping Table

 link role - if the element has a valid href or xlink:href attribute. - For a elements that are not links, use the mapping for + if the element has a valid href or xlink:href attribute. + For a elements that are not links, use the mapping for tspan if the a element is a descendent of text, or the mapping for g otherwise. animate no accessible object createdno role may be appliedno accessible object createdno role may be applied
animateMotion no accessible object createdno role may be appliedno role may be applied
@@ -1222,7 +1222,7 @@

SVG Element Mapping Table

 Follow the recommendations for the HTML audio element in the HTML Accessibility API Mappings specification [[!HTML-AAM]]. - application role graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1285,7 +1285,7 @@

SVG Element Mapping Table

 no accessible object created, - for this element or any child content; + for this element or any child content; see Name and Description mapping no role may be applied graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1449,7 +1449,7 @@

SVG Element Mapping Table

 group role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1514,7 +1514,7 @@

SVG Element Mapping Table

 graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1569,7 +1569,7 @@

SVG Element Mapping Table

 graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1591,7 +1591,7 @@

SVG Element Mapping Table

 graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1605,7 +1605,7 @@

SVG Element Mapping Table

 graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1626,7 +1626,7 @@

SVG Element Mapping Table

 graphics-symbol role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; - otherwise, no accessible object created + otherwise, no accessible object created any role; @@ -1725,8 +1725,8 @@

SVG Element Mapping Table

 text - group role, + + group role, but with the following platform-specific API mappings:

Acknowledgments

@@ -2420,18 +2420,18 @@

Participants active in the SVG Accessibility Task Force active at the time o

Enabling funders

- This publication has been funded in part with - Federal funds from the U.S. Department of Education, + 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 + 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.

- +