From 19a7aa060a98f984398329c0ad86316ab8a4ccc4 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Fri, 20 Feb 2015 17:46:44 -0500 Subject: [PATCH 01/15] Fixing issues found by HTML validator on generated ouptut --- svg-aam/svg-aam.html | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 13027455e..cd5385165 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -384,7 +384,7 @@

Normative User Agent Implementation Requirements for

Important Terms

-
Placeholder for glossary
+
Placeholder for glossary

Supporting Keyboard Navigation

@@ -752,9 +752,11 @@

SVG Element Mapping Table

text

The 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.

group +  textPath

The 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.

group +  title none @@ -766,6 +768,7 @@

SVG Element Mapping Table

tspan

The 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.

group +  use none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappings From b338ea57f577fb3cd0a8ffb720826dd520377222 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Fri, 20 Feb 2015 18:16:25 -0500 Subject: [PATCH 02/15] Link fixes, first pass --- svg-aam/svg-aam.html | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index cd5385165..73fa6987b 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -88,12 +88,13 @@ ariaSpecURLs: { "ED": "http://w3c.github.io/aria/aria/aria.html", "WD" : "http://www.w3.org/TR/wai-aria-1.1/", + "FPWD" : "http://www.w3.org/TR/wai-aria-1.1/", "REC": "http://www.w3.org/TR/wai-aria/" }, accNameURLs: { "ED": "http://w3c.github.io/aria/accname-aam/accname-aam.html", - "WD" : "http://www.w3.org/TR/accname-1.1/", - "FPWD": "http://www.w3.org/TR/accname-1.1/", + "WD" : "http://www.w3.org/TR/accname-aam-1.1/", + "FPWD": "http://www.w3.org/TR/accname-aam-1.1/", "REC": "http://www.w3.org/TR/accname-aam/" }, @@ -329,7 +330,7 @@
-

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.

+

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 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.

The SVG-AAM is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

@@ -337,16 +338,16 @@

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 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:

  • Accessible Rich Internet Applications (WAI-ARIA) 1.1 [[WAI-ARIA]], a planned W3C recommendation follow on, to the [[WAI-ARIA-10]] standard standard.
  • WAI-ARIA Authoring Practices Guide [[ARIA-PRACTICES]], a planned W3C Working Group Note, 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.
-

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:

    @@ -357,29 +358,29 @@

    Introduction

    Accessibility APIs

    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

-

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.

Normative User Agent Implementation Requirements for SVG

-

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.

@@ -412,7 +413,7 @@

Exposing attributes that do not directly map to accessibility

Role mapping

-

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.

General Rules

[[SVG]] user agents MUST conform to the Role Mapping General Rules accessibility API computational requirements in [[!CORE-AAM]]. @@ -465,7 +466,7 @@

SVG Element Mapping Table

Role Mappings circle -none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mapping +none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mapping Role Mappings @@ -495,7 +496,7 @@

SVG Element Mapping Table

ellipse -none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mapping +none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mapping Role Mappings @@ -712,7 +713,7 @@

SVG Element Mapping Table

No role may be applied. rect -none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappings +none role mapping, provided no associated ‘title’ element, ‘desc’ element, ‘aria-label’ attribute, ‘aria-labelledby’ attribute, or ‘aria-describedby’ attribute; otherwise, group role mappingRole Mappings script none @@ -790,7 +791,7 @@

SVG Element Mapping Table

State and Property Mapping

-

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]]. +

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]].

@@ -828,7 +829,7 @@

Actions

Events

-

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.

From 7f562877c51fb463e03e258991ff3097a2d4fd99 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Fri, 20 Feb 2015 18:37:23 -0500 Subject: [PATCH 03/15] Trying to get glossary loaded properly --- svg-aam/svg-aam.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 73fa6987b..4fac869e0 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -385,7 +385,7 @@

Normative User Agent Implementation Requirements for

Important Terms

-
Placeholder for glossary
+
Placeholder for glossary

Supporting Keyboard Navigation

From b25f42ff9bb3295f4910932a4aafb26cf444bf46 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Mon, 23 Feb 2015 10:01:26 -0500 Subject: [PATCH 04/15] SVG-AAM acknowledgements, first pass --- svg-aam/svg-aam.html | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 4fac869e0..58cfa5fbc 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -843,7 +843,33 @@

Appendices

References

Placeholder for references

-
+ +
+

Acknowledgments

+

The following people contributed to the development of this document.

+
+

Participants active in the SVG Accessibility Task Force active at the time of publication

+
    +
  • Amelia Bellamy-Royds
    • +
  • Erik Dahlström (Opera)
    • +
  • Amy Dai (Oracle Corporation)
    • +
  • Fred Esch (IBM Corporation)
    • +
  • Cameron McCormack (Mozilla Foundation)
    • +
  • Charles Nevile (Yandex)
    • +
  • Charu Pandhi (IBM Corporation)
    • +
  • Janina Sajka
    • +
  • Doug Schepers (W3C)
    • +
  • Rich Schwerdtfeger (IBM Corporation)
    • +
  • Léonie Watson (The Paciello Group, LLC)
    • +
  • Jason White (Educational Testing Service)
    • +
+
+
+

Enabling funders

+

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.

+
+
+ From db30aed8bd62c355d42764838c3f154bc3b887f6 Mon Sep 17 00:00:00 2001 From: Joseph Scheuhammer Date: Mon, 23 Feb 2015 10:44:08 -0500 Subject: [PATCH 05/15] ACTION-1444/ACTION-1445: Mappings for role presentation/none. Modified 'none' and 'presentation' entries of role mapping table for ATK/AT-SPI and UIA platforms. Specifically, improved the decsription regarding how to map children when the children's ancestor is a table or a list that has role "presentation" or "none". --- core-aam/core-aam.html | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/core-aam/core-aam.html b/core-aam/core-aam.html index 9eaff8d7c..849ec8287 100644 --- a/core-aam/core-aam.html +++ b/core-aam/core-aam.html @@ -942,10 +942,12 @@

Role Mapping Table

If the object is in the accessibility tree, expose as ROLE_SYSTEM_PANE

See General rules for exposing WAI-ARIA semantics

-

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.

See General rules for exposing WAI-ARIA semantics

-

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.

See General rules for exposing WAI-ARIA semantics

Not mapped

See General rules for exposing WAI-ARIA semantics

@@ -982,10 +984,12 @@

Role Mapping Table

If the object is in the accessibility tree, expose as ROLE_SYSTEM_PANE

See General rules for exposing WAI-ARIA semantics

-

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.

See General rules for exposing WAI-ARIA semantics

-

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.

See General rules for exposing WAI-ARIA semantics

Not mapped

From bba5e7aba86e27b6ad9fd8dad39499cc215d1d4b Mon Sep 17 00:00:00 2001 From: Joseph Scheuhammer Date: Mon, 23 Feb 2015 11:30:24 -0500 Subject: [PATCH 06/15] Editorial: Added links to event table in accname-aam.html. Added two entries to the events section of the core-aam for aria-label/aria-labelledby and aria-describedby, linking to the events section of the accname-aam spec. --- core-aam/core-aam.html | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/core-aam/core-aam.html b/core-aam/core-aam.html index 849ec8287..b1634f8cc 100644 --- a/core-aam/core-aam.html +++ b/core-aam/core-aam.html @@ -2268,6 +2268,14 @@

State and Property Change Events

object:state-changed:enabled and object:state-changed:sensitive Not mapped + + aria-describedby + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + aria-dropeffect (property) Not mapped @@ -2296,7 +2304,7 @@

State and Property Change Events

Not mapped - aria-hidden (state) + aria-hidden (state) EVENT_OBJECT_HIDE, EVENT_OBJECT_SHOW IAccessible2: IA2_EVENT_OBJECT_ATTRIBUTE_CHANGED StructureChangedEvent @@ -2312,6 +2320,14 @@

State and Property Change Events

object:state-changed:invalid_entry AXInvalidStatusChanged + + aria-label and aria-labelledby + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + See the Name and Description Change Events section in [[!ACCNAME-AAM]]. + aria-pressed (state) EVENT_OBJECT_STATECHANGE From dbb9826461fbe9329a989691cb1acc2652118c60 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 11:03:04 -0500 Subject: [PATCH 07/15] Rejiggering abstract at JB request --- svg-aam/svg-aam.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 58cfa5fbc..eb2d34a11 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -331,7 +331,8 @@

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 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.

+

This specification allows SVG authors to create accessible rich internet applications, including charts, graphs, and other drawings. It does this by extend 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.

From 5dfeab7f141add69c353fa6738bda8d8280d1208 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 12:37:56 -0500 Subject: [PATCH 08/15] Abstract editorial style tweaks --- svg-aam/svg-aam.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index eb2d34a11..978dc8a1a 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -331,8 +331,7 @@

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 extend 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.

+

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.

From 4ee77cdb83f4007afdd135a000b226416d17062a Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 14:41:59 -0500 Subject: [PATCH 09/15] Bib link fixes --- svg-aam/svg-aam.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 978dc8a1a..fc9e0e233 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -365,8 +365,8 @@

Accessibility APIs <

Accessibility APIs covered by this document are:

From 139af20df807fb4f773a622a4bc62360bc3f6e10 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 14:48:40 -0500 Subject: [PATCH 10/15] Respec-ifying citations --- svg-aam/svg-aam.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index fc9e0e233..bd1e3724a 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -364,10 +364,10 @@

Accessibility APIs <

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.

@@ -380,7 +380,7 @@

The Accessibility Tree and the DOM

Normative User Agent Implementation Requirements for SVG

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.

+

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.

From 5cfccecec8ad5dfcc56a4a759f9901310ab83db2 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 15:04:28 -0500 Subject: [PATCH 11/15] MSDN https redirects --- common/terms.html | 4 ++-- svg-aam/svg-aam.html | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/common/terms.html b/common/terms.html index 557c48d3c..931069222 100644 --- a/common/terms.html +++ b/common/terms.html @@ -6,8 +6,8 @@ expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. - Examples of accessibility APIs are Microsoft - Active Accessibility [[MSAA]], Microsoft User Interface Automation [[UI-AUTOMATION]], MSAA with UIA Express [[UIA-EXPRESS]], the + Examples of accessibility APIs are Microsoft + Active Accessibility [[MSAA]], Microsoft User Interface Automation [[UI-AUTOMATION]], MSAA with UIA Express [[UIA-EXPRESS]], the Mac OS X Accessibility Protocol [[AXAPI]], the Linux/Unix Accessibility Toolkit [[ATK]] and Assistive Technology Service Provider Interface [[AT-SPI]], and IAccessible2 [[IAccessible2]].

diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index bd1e3724a..36025fcbd 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -284,7 +284,7 @@ }, // Custom reference for UIA Express (not available from SpecRef biblio). "UIA-EXPRESS": { - "href": "http://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx", + "href": "https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx", "title": "The IAccessibleEx Interface", "publisher": "Microsoft Corporation" }, @@ -364,9 +364,9 @@

Accessibility APIs <

Accessibility APIs covered by this document are:

From 49db711dd00f42dd120a751dbe615bfd62e37047 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Tue, 24 Feb 2015 15:07:03 -0500 Subject: [PATCH 12/15] Case link redirect --- svg-aam/svg-aam.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 36025fcbd..35b479589 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -437,7 +437,7 @@

SVG Element Mapping Table

-a +a link Role Mappings From fce9d3f2fbdb9008a2f1ef1553f23b7f7abfb0d5 Mon Sep 17 00:00:00 2001 From: Joseph Scheuhammer Date: Wed, 25 Feb 2015 15:02:20 -0500 Subject: [PATCH 13/15] Editorial: Fixed spelling.. --- accname-aam/accname-aam.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/accname-aam/accname-aam.html b/accname-aam/accname-aam.html index fb8c2b31c..d42a61a8b 100644 --- a/accname-aam/accname-aam.html +++ b/accname-aam/accname-aam.html @@ -496,7 +496,7 @@

Name and Description Change Events

accessible name EVENT_OBJECT_NAMECHANGE EVENT_OBJECT_NAMECHANGE - ProperyChangeEvent + PropertyChangeEvent object:property-change:accessible-name TitleChangedNotification @@ -504,7 +504,7 @@

Name and Description Change Events

accessible description EVENT_OBJECT_DESCRIPTIONHANGE EVENT_OBJECT_DESCRIPTIONCHANGE - ProperyChangeEvent + PropertyChangeEvent object:property-change:accessible-description TBD. From cc296d585cd162d6ad4feac016f8668a3d21a446 Mon Sep 17 00:00:00 2001 From: Michael Cooper Date: Wed, 25 Feb 2015 18:16:15 -0500 Subject: [PATCH 14/15] broken link fragment hope I got the right target --- svg-aam/svg-aam.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/svg-aam/svg-aam.html b/svg-aam/svg-aam.html index 35b479589..96960d2ea 100644 --- a/svg-aam/svg-aam.html +++ b/svg-aam/svg-aam.html @@ -416,7 +416,7 @@

Role mapping

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.

General Rules

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

SVG Element Mapping Table

From 2c158fbacb2cc003cf835298829c8573e35bf55d Mon Sep 17 00:00:00 2001 From: Joseph Scheuhammer Date: Mon, 2 Mar 2015 16:42:03 -0500 Subject: [PATCH 15/15] ACTION-1563: Provide AX API mapping for role="switch". Added mappings as per Joanie's recommendation, but guessed that the AXRoleDescription is 'switch'. --- core-aam/core-aam.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/core-aam/core-aam.html b/core-aam/core-aam.html index b1634f8cc..08d67297c 100644 --- a/core-aam/core-aam.html +++ b/core-aam/core-aam.html @@ -1144,7 +1144,9 @@

Role Mapping Table

TBD (ACTION-1564) Control type/role is Button + Toggle Pattern. Localized Control Type is "toggleswitch". ROLE_TOGGLE_BUTTON - TBD (ACTION-1563) + AXRole: AXCheckBox
+ AXSubrole: AXSwitch
+ AXRoleDescription: 'switch' Double check the role description tab