- From: Fred Esch <fesch@us.ibm.com>
- Date: Fri, 4 Mar 2016 12:43:09 -0500
- To: Joseph Scheuhammer <clown@alum.mit.edu>
- Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>
- Message-Id: <201603041750.u24HoPGn002277@d01av02.pok.ibm.com>
Joseph,
For SVG it is imperative that an author be able to mark an element with the
role none or presentation and know that the element will not appear in the
accessibility tree. SVG is too messy to force authors and authoring tools
to work through anything but the simplest rule.
Case 1: A group element is only present in the SVG to pass along common
attributes to their children. For instance you may group text elements for
labeling items around a circle, by their anchor location. This group
element has no semantic meaning. This is a common use for group elements as
it makes the SVG smaller and makes it easier to edit reused styles. This
group element should not be included in the accessibility tree.
Case 2: A group element has semantic meaning and the parent/child
relationship is significant. An example, would be a group element
representing a stack in a stacked bar chart. The children of the stack
group element are the individual bars that make up the stack and the stack
group element may contain stack level information, for example the total
value (height) of the stack. A good chart navigation tool would let a user
visit the stack and the user could either visit the individual bars in the
stack or move to another stack. Without using stack level objects in the
accessibility tree the concept of a stacked chart would be lost. This group
element should appear in the accessibility tree.
Programmatically, both Case 1 and Case 2 group elements may look similar.
Authoring tools (few developer hand edit SVG) need to provide a straight
forward way to disallow elements from being in the accessibility tree.
Authors need a straight forward way of to disallow elements from being in
the accessibility tree. Without an author friendly way of identifying case
1 from case 2 the underlying concept of the graphic can be lost.
The SVG accessibility task force decided that using a role of none or
presentation was the golden hammer that developers and authoring tools need
to exclude elements from the accessibility tree. Amelia is add the changes
in. If we need to change the ARIA spec lets change it.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Joseph Scheuhammer <clown@alum.mit.edu>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Richard
Schwerdtfeger <richschwer@gmail.com>
Cc: ARIA Working Group <public-aria@w3.org>
Date: 03/03/2016 10:57 AM
Subject: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group
On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote:
>
> /... That said/, I would like it to be more clear. I think the easiest
> change would be to modify the bullet point (in section 5.1.2 of the
> Core-AAM) that currently says:
>
> * Elements that have a global WAI-ARIA attribute but do not have
> aria-hidden="true". (See Excluding Elements in the
> Accessibility Tree for additional guidance on aria-hidden.)
>
> To instead say
>
> * Elements that have a global WAI-ARIA attribute but do not have
> aria-hidden="true" or a mapped role of presentation or none.
> (See Excluding Elements in the Accessibility Tree for
> additional guidance on aria-hidden and presentational roles.)
>
I don't believe that is consistent with the specification of the
presentation role. Either that, or the specification needs to change.
I filed ISSUE-708 about this in Mar 2015 [1]. There have been
discussions at the AAPI teleconferences, and we have been approaching
agreement on changes to the core-aam inclusion rules. Here's a summary:
1. Using role="presentation" on an element that is interactive is an
author error, and the role will be ignored. Here, "interactive" means
any of (1) the element is focusable, or (2) can cause an AAPI event
[2]. The reason that presentation is ignored in these cases is that the
presentation role will stop neither a DOM event nor the corresponding
AAPI event from occurring, and the event will have an associated
source/target. That is, there will be an accessible object in the a11y
tree as the target of the event.
The ARIA specification for role="presentation" at least documents the
focusable case:
"If an element with a role of presentation is focusable, user agents
MUST ignore the normal effect of the role and expose the element with
implicit native semantics, in order to ensure that the element is both
understandable and operable" [3].
2. Using role="presentation" in conjunction with a global aria property
is also an author error. The role says that the element has no meaning,
whereas the aria-* says that it does. In this case, the ARIA
specification states:
" ...the user agent MUST always expose global WAI-ARIAstates and
properties to accessibility APIs, even if an element has an explicit or
inherited role of presentation" [3].||||||
In summary, the core-aam inclusion rules need changes, but those changes
must be in accordance with the ARIA spec. If it's necessary that there
are cases where role="presentation" *always* excludes an element from
the accessibility tree, then the ARIA specification *itself* must be
modified.
[1] https://www.w3.org/WAI/ARIA/track/issues/708
[2]
http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change
[3] http://w3c.github.io/aria/aria/aria.html#presentation
On 2016-03-02 10:31 PM, Amelia Bellamy-Royds wrote:
> If there's time, I'd appreciate the group taking a look at GitHub
> Issue #136, on the interaction of role=none/presentation and other
> global ARIA attributes. Joanmarie filed the issue when trying to
> implement SVG-AAM, but it really stems from the Core mapping spec.
>
> https://github.com/w3c/aria/issues/136
>
> I'd like to confirm that the interpretation we're taking for SVG-AAM
> matches how others think Core-AAM should be interpreted. And it would
> be nice to get clarified language into both specs in time for
> publication of the new drafts next week.
>
> ~Amelia
>
--
;;;;joseph.
'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
- C. Carter -
--1__
BBF5FFDFCE3EC08f9e8a93df938690918c0ABBF5FFDFCE3EC0
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
<html><body><p>Joseph,<br><br>For SVG it is imperative that an author be able to mark an element with the role none or presentation and know that the element will not appear in the accessibility tree. SVG is too messy to force authors and authoring tools to work through anything but the simplest rule.<br><br>Case 1: A group element is only present in the SVG to pass along common attributes to their children. For instance you may group text elements for labeling items around a circle, by their anchor location. This group element has no semantic meaning. This is a common use for group elements as it makes the SVG smaller and makes it easier to edit reused styles. This group element should not be included in the accessibility tree.<br><br>Case 2: A group element has semantic meaning and the parent/child relationship is significant. An example, would be a group element representing a <i>stack</i> in a <i>stacked</i> bar chart. The children of the <i>stack</i> group element are the individual bars that make up the stack and the <i>stack</i> group element may contain <i>stack</i> level information, for example the total value (height) of the <i>stack</i>. A good chart navigation tool would let a user visit the <i>stack</i> and the user could either visit the individual bars in the <i>stack</i> or move to another <i>stack</i>. Without using <i>stack</i> level objects in the accessibility tree the concept of a <i>stacked</i> chart would be lost. This group element should appear in the accessibility tree.<br><br>Programmatically, both Case 1 and Case 2 group elements may look similar. Authoring tools (few developer hand edit SVG) need to provide a straight forward way to disallow elements from being in the accessibility tree. Authors need a straight forward way of to disallow elements from being in the accessibility tree. Without an author friendly way of identifying case 1 from case 2 the underlying concept of the graphic can be lost. <br><br>The SVG accessibility task force decided that using a role of none or presentation was the golden hammer that developers and authoring tools need to exclude elements from the accessibility tree. Amelia is add the changes in. If we need to change the ARIA spec lets change it.<br><br><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="473" colspan="2" valign="middle"><div align="center"><font size="4" face="Verdana">Regards, <br><br>Fred Esch <br>Watson, IBM, W3C Accessibility</font></div></td></tr>
<tr valign="top"><td width="130" valign="middle"><img src="cid:1__=0ABBF5FFDFCE3EC08f9e8a93df938690918c0AB@" width="163" height="23" alt="IBM Watson" align="bottom"></td><td width="342" valign="middle"><font size="4" face="Verdana">Watson Release Management and Quality </font></td></tr></table><br><br><img width="16" height="16" src="cid:2__=0ABBF5FFDFCE3EC08f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Joseph Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote: >"><font color="#424282">Joseph Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote: ></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Joseph Scheuhammer <clown@alum.mit.edu></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Richard Schwerdtfeger <richschwer@gmail.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">ARIA Working Group <public-aria@w3.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/03/2016 10:57 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote:<br>><br>> /... That said/, I would like it to be more clear. I think the easiest <br>> change would be to modify the bullet point (in section 5.1.2 of the <br>> Core-AAM) that currently says:<br>><br>> * Elements that have a global WAI-ARIA attribute but do not have<br>> aria-hidden="true". (See Excluding Elements in the<br>> Accessibility Tree for additional guidance on aria-hidden.)<br>><br>> To instead say<br>><br>> * Elements that have a global WAI-ARIA attribute but do not have<br>> aria-hidden="true" or a mapped role of presentation or none.<br>> (See Excluding Elements in the Accessibility Tree for<br>> additional guidance on aria-hidden and presentational roles.)<br>><br><br>I don't believe that is consistent with the specification of the <br>presentation role. Either that, or the specification needs to change.<br><br>I filed ISSUE-708 about this in Mar 2015 [1]. There have been <br>discussions at the AAPI teleconferences, and we have been approaching <br>agreement on changes to the core-aam inclusion rules. Here's a summary:<br><br>1. Using role="presentation" on an element that is interactive is an <br>author error, and the role will be ignored. Here, "interactive" means <br>any of (1) the element is focusable, or (2) can cause an AAPI event <br>[2]. The reason that presentation is ignored in these cases is that the <br>presentation role will stop neither a DOM event nor the corresponding <br>AAPI event from occurring, and the event will have an associated <br>source/target. That is, there will be an accessible object in the a11y <br>tree as the target of the event.<br><br>The ARIA specification for role="presentation" at least documents the <br>focusable case:<br>"If an element with a role of presentation is focusable, user agents <br>MUST ignore the normal effect of the role and expose the element with <br>implicit native semantics, in order to ensure that the element is both <br>understandable and operable" [3].<br><br>2. Using role="presentation" in conjunction with a global aria property <br>is also an author error. The role says that the element has no meaning, <br>whereas the aria-* says that it does. In this case, the ARIA <br>specification states:<br>" ...the user agent MUST always expose global WAI-ARIAstates and <br>properties to accessibility APIs, even if an element has an explicit or <br>inherited role of presentation" [3].||||||<br><br>In summary, the core-aam inclusion rules need changes, but those changes <br>must be in accordance with the ARIA spec. If it's necessary that there <br>are cases where role="presentation" *always* excludes an element from <br>the accessibility tree, then the ARIA specification *itself* must be <br>modified.<br><br><br>[1] </tt><tt><a href="https://www.w3.org/WAI/ARIA/track/issues/708">https://www.w3.org/WAI/ARIA/track/issues/708</a></tt><tt><br>[2] <br></tt><tt><a href="http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change">http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change</a></tt><tt><br>[3] </tt><tt><a href="http://w3c.github.io/aria/aria/aria.html#presentation">http://w3c.github.io/aria/aria/aria.html#presentation</a></tt><tt><br><br>On 2016-03-02 10:31 PM, Amelia Bellamy-Royds wrote:<br>> If there's time, I'd appreciate the group taking a look at GitHub <br>> Issue #136, on the interaction of role=none/presentation and other <br>> global ARIA attributes. Joanmarie filed the issue when trying to <br>> implement SVG-AAM, but it really stems from the Core mapping spec.<br>><br>> </tt><tt><a href="https://github.com/w3c/aria/issues/136">https://github.com/w3c/aria/issues/136</a></tt><tt><br>><br>> I'd like to confirm that the interpretation we're taking for SVG-AAM <br>> matches how others think Core-AAM should be interpreted. And it would <br>> be nice to get clarified language into both specs in time for <br>> publication of the new drafts next week.<br>><br>> ~Amelia<br>><br><br>-- <br>;;;;joseph.<br><br>'Die Wahrheit ist Irgendwo da Draußen. Wieder.'<br> - C. Carter -<br><br><br></tt><br><br><BR>
</body></html>
--1__
BBF5FFDFCE3EC08f9e8a93df938690918c0ABBF5FFDFCE3EC0--
--0__
BBF5FFDFCE3EC08f9e8a93df938690918c0ABBF5FFDFCE3EC0
Content-type: image/gif;
name="0F610875.gif"
Content-Disposition: inline; filename="0F610875.gif"
Content-ID: <1__
BBF5FFDFCE3EC08f9e8a93df938690918c0AB@>
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAAKMAAAAXCAMAAABQ6Q/RAAADAFBMVEXIx8cxLS5MSUrW1dXx8fE/
Ozzj4+N2c3SRj49oZWaEgYKsq6uenZ26ubmbm5v29vZ7e3tTU1M7OzsfHx/FxcX39/eamppmZmaR
j5AgICCqqqrR0dFaV1gAAAAjHyD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAADe7fL7AAADE0lEQVR4nM2WiW7kIAyGTbhz9O6eCL//U6bYGJJOst2dlaqppUm4
+fhtnAH8+gb7sroZxodWGZfA5UxP52+Ic2qVEbLDxujTLXnOTHydSDxNdC7DR+NvYQK02PLQYBDn
z5dRw04GAPibKIBec2GKuZjyrtbosVZr72J397Xyc+suPshsiOUBvRb4xavlzYoA2tI+XEQTFDfT
rkCFiFLIec8Y82jQ0dIhjOU5lmWGa254owKe/J5xPDBqdYHLphZBm08Zi5/nOnEsEUmHwiG6cx3X
Z6k8ID5c6kgHHC4YlblkJHcNlotO7Xp0RVP6lLFIPtTmsuDQDn+FGT4YTy3OXcTFEy85VUYonQMQ
WHWopSIdR83aTYRs5bBD9cz+VjBjyI3RbVEkSu7ed/XF8r18ExXF25ZJiWnk/RhD1S1JlFT5mLGc
B0KYNJG5rtEkLhjPGUVz32Lh2iw+k68WnhqJjeZTldqBr27dFkCz2mlyooxcac0zJUyWM8YKFnn8
KLofdFy7brvwXLctZs+6KScOTrSr6uft2y4SmJqa+tUcxPeKY/iEcc4+W8qNfYUrdSTtYvnRrfE1
rgk1QOqBs207ideoc2gLJGFMtEQ6YQy53OvwA1DifmM86PhQKxSZ66+uI/o6zdVcMmwtRHrBiGbm
XWysp2FTjbERHHUEPXAgtDRxrY5Vfsvph6PebGnFvmcswSnp2PcDcECPdYzkz2M8ziBH9rtl8c/3
Gh/X9TtuOhphWyToedNUzEp0boyZ8zQNnHLrXIhLy5jplBHVINnHmKj+415Lamt+QAdWDkphmcC5
mh8lodvqNsOqDyHw5GjamHjKGLKEj66LuK7i5XfmsVbwdX1+leL9vTiLIiTy8qFFjHwygjQA7j46
sUc/oxpoY4w9YzRW+RbsZeJ135mnJ9ErCuv8T4yqCGH6zYoGOyOXDowSqJ5yRtq6jzq2/z2IL7+l
H58eaWxMiULLlRjUOCU2+kfKNkkDuam8KJP6eqPB0+eIU7PexswpjQdG5AAJEOL1X+vPt/7/cuLg
UP7L/QtHfANvSEKvsxvttAAAAABJRU5ErkJggg=
--0__
BBF5FFDFCE3EC08f9e8a93df938690918c0ABBF5FFDFCE3EC0
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <2__
BBF5FFDFCE3EC08f9e8a93df938690918c0AB@>
Content-Transfer-Encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__
BBF5FFDFCE3EC08f9e8a93df938690918c0ABBF5FFDFCE3EC0--
Received on Friday, 4 March 2016 17:50:58 UTC