- From: Fred Esch <fesch@us.ibm.com>
- Date: Mon, 7 Mar 2016 10:46:06 -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: <201603071549.u27FntrS016171@d01av02.pok.ibm.com>
Joseph,
There are elements that will never appear in the accessibility tree. For
example, an feBlend element is part of a filter which affects appearance of
objects but is not directly rendered as an object. An feBlend element will
never appear in an accessibility tree. Obviously, if you add a tabindex,
aria-label and/or an event listener to it, it still won't appear in the
accessibility tree.
Group elements are not automatically included in the accessibility tree.
You have to add something like a tabindex to include them. I am fine with
considering it an authoring error if you have a tabindex and role of none -
and when you have both it fails validation. Is aria-hidden the 'golden
hammer' that always works? And refresh my memory, aria-hidden does not
affect the elements children, right?
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Joseph Scheuhammer <clown@alum.mit.edu>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, ARIA
Working Group <public-aria@w3.org>, Richard Schwerdtfeger
<richschwer@gmail.com>
Date: 03/06/2016 07:22 PM
Subject: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group
Hi Fred,
On 2016-03-04 12:43 PM, Fred Esch wrote:
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.
Given the current specification of how the presentation/none role works,
the way the author ensures that the element will not be exposed is by
making sure that the element is not focusable, will not incur an
accessibility event, and/or does not have any global aria-* attributes. If
the developer configures the element as such, and adds role="none" to it,
then the element will not appear in the accessibility tree. In short, it's
the author's responsibility to use the correct kind of element, not add
@tabindex to it, nor any other aria-* attribute if they want it excluded.
Regarding your two use cases, by "group element" do you mean the <g>
element? Based on the svg-aam, that element is generally not mapped,
meaning it doesn't even need role="presentation" to exclude it from the
tree [1] (my emphasis):
" group role mapping if the element meets the criteria for Including
Elements in the Accessibility Tree; otherwise, *no accessible object
created*"
For Case 1, is the group element focusable, TAB navigable, clickable, or
otherwise interactive? Does it have any aria-* attributes? Is the <g>
element given a role other than presentation/none? If the answer is "no"
to all these questions, then the group element won't be exposed (there
won't be an accessible object in the a11y tree).
For Case 2, you imply there is interactivity with the <g> element in the
form of navigation. It may also have some aria-* attribute(s) or a role
other than none/presentation, although I can't tell without more
information. Assuming some or all of these holds, then it will be included
in the accessibility tree.
I don't see any issue or inconsistency between the current specification of
presentation/none and your two use cases. It looks to me like you have
everything you want -- where is the problem?
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.
To use your terminology, there is no golden hammer. One of the principles
of ARIA is that it does not change the browser's user interface. For
example, if an element is focusable, TAB-navigable, or clickable, then
putting role="presentation" on it will not change its interactive nature.
Users can still TAB to it, or activate it by mouse or keyboard regardless
of an additional presentation role. As such, it must have some
representation in the accessibility tree. If the author truly intends for
that element to have no semantic impact, then it's their responsibility to
construct the element such that it is, in fact meaningless. That entails
that they do not add any aria-* attributes to it, since, by doing so, they
would be adding semantic information. If authors properly configure a
semantic-free element, then adding role="none" will do what you want, if it
is needed at all.
[1]
http://w3c.github.io/aria/svg-aam/svg-aam.html#mapping_role_table#role-map-g
--
;;;;joseph.
'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
- C. Carter -
--1__
BBF5FCDFC75A678f9e8a93df938690918c0ABBF5FCDFC75A67
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
<html><body bgcolor="#FFFFFF"><p>Joseph,<br><br>There are elements that will never appear in the accessibility tree. For example, an feBlend element is part of a filter which affects appearance of objects but is not directly rendered as an object. An feBlend element will never appear in an accessibility tree. Obviously, if you add a tabindex, aria-label and/or an event listener to it, it still won't appear in the accessibility tree.<br><br>Group elements are not automatically included in the accessibility tree. You have to add something like a tabindex to include them. I am fine with considering it an authoring error if you have a tabindex and role of none - and when you have both it fails validation. Is aria-hidden the 'golden hammer' that always works? And refresh my memory, aria-hidden does not affect the elements children, right? <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__=0ABBF5FCDFC75A678f9e8a93df938690918c0AB@" 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__=0ABBF5FCDFC75A678f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Joseph Scheuhammer ---03/06/2016 07:22:06 PM---Hi Fred, On 2016-03-04 12:43 PM, Fred Esch wrote:"><font color="#424282">Joseph Scheuhammer ---03/06/2016 07:22:06 PM---Hi Fred, On 2016-03-04 12:43 PM, Fred Esch 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">Fred Esch/Arlington/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/06/2016 07:22 PM</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><font size="4">Hi Fred,<br><br>On 2016-03-04 12:43 PM, Fred Esch wrote:</font><ul><ul><font size="4">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.</font></ul></ul><font size="4"><br>Given the current specification of how the presentation/none role works, the way the author ensures that the element will not be exposed is by making sure that the element is not focusable, will not incur an accessibility event, and/or does not have any global aria-* attributes. If the developer configures the element as such, and adds role="none" to it, then the element will not appear in the accessibility tree. In short, it's the author's responsibility to use the correct kind of element, not add @tabindex to it, nor any other aria-* attribute if they want it excluded.<br><br>Regarding your two use cases, by "group element" do you mean the <g> element? Based on the svg-aam, that element is generally not mapped, meaning it doesn't even need role="presentation" to exclude it from the tree [1] (my emphasis):<br><br>" group role mapping if the element meets the criteria for Including Elements in the Accessibility Tree; otherwise, *no accessible object created*"<br><br>For Case 1, is the group element focusable, TAB navigable, clickable, or otherwise interactive? Does it have any aria-* attributes? Is the <g> element given a role other than presentation/none? If the answer is "no" to all these questions, then the group element won't be exposed (there won't be an accessible object in the a11y tree).<br><br>For Case 2, you imply there is interactivity with the <g> element in the form of navigation. It may also have some aria-* attribute(s) or a role other than none/presentation, although I can't tell without more information. Assuming some or all of these holds, then it will be included in the accessibility tree.<br><br>I don't see any issue or inconsistency between the current specification of presentation/none and your two use cases. It looks to me like you have everything you want -- where is the problem?<br></font><ul><ul><font size="4">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.</font></ul></ul><font size="4"><br>To use your terminology, there is no golden hammer. One of the principles of ARIA is that it does not change the browser's user interface. For example, if an element is focusable, TAB-navigable, or clickable, then putting role="presentation" on it will not change its interactive nature. Users can still TAB to it, or activate it by mouse or keyboard regardless of an additional presentation role. As such, it must have some representation in the accessibility tree. If the author truly intends for that element to have no semantic impact, then it's their responsibility to construct the element such that it is, in fact meaningless. That entails that they do not add any aria-* attributes to it, since, by doing so, they would be adding semantic information. If authors properly configure a semantic-free element, then adding role="none" will do what you want, if it is needed at all.<br><br>[1] </font><a href="http://w3c.github.io/aria/svg-aam/svg-aam.html#mapping_role_table"><u><font size="4" color="#0000FF">http://w3c.github.io/aria/svg-aam/svg-aam.html#mapping_role_table#role-map-g</font></u></a><font size="4"><br><br></font><br><tt><font size="4">-- <br>;;;;joseph.<br><br>'Die Wahrheit ist Irgendwo da Draußen. Wieder.'<br> - C. Carter -</font></tt><br><br><BR>
</body></html>
--1__
BBF5FCDFC75A678f9e8a93df938690918c0ABBF5FCDFC75A67--
--0__
BBF5FCDFC75A678f9e8a93df938690918c0ABBF5FCDFC75A67
Content-type: image/gif;
name="0A464764.gif"
Content-Disposition: inline; filename="0A464764.gif"
Content-ID: <1__
BBF5FCDFC75A678f9e8a93df938690918c0AB@>
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__
BBF5FCDFC75A678f9e8a93df938690918c0ABBF5FCDFC75A67
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <2__
BBF5FCDFC75A678f9e8a93df938690918c0AB@>
Content-Transfer-Encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__
BBF5FCDFC75A678f9e8a93df938690918c0ABBF5FCDFC75A67--
Received on Monday, 7 March 2016 15:50:36 UTC