- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 9 Mar 2016 10:58:03 -0500
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: Joseph Scheuhammer <clown@alum.mit.edu>, ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>
- Message-Id: <201603091605.u29G5j8x020954@d03av01.boulder.ibm.com>
Jumping to Amelia's thread.
I would appreciate as simple as possible methods to determine whether
something should be included in the accessibility tree or not. Bryan and
Stefan bring up complications with aria-hidden and CSS display:none, Joseph
points brings up events as forcing inclusion in the accessibility tree. The
Note in ARIA 1.1 is disturbing "At the time of this writing, aria-hidden
="false" is known to work inconsistently in browsers. As future
implementations improve, use caution and test thoroughly before relying on
this approach."
We have too complicated a system. How can we give authors guidance if even
browsers can't agree on what the behavior is.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, ARIA Working Group
<public-aria@w3.org>, Richard Schwerdtfeger
<richschwer@gmail.com>
Date: 03/05/2016 12:48 AM
Subject: Conflicting inclusion/exclusion criteria for elements in the
accessibility tree (Was: Re: [ARIA] Agenda: March 3, 2016
WAI-ARIA Working Group)
I have to agree with Joseph's concerns.
This isn't a matter of whether author's should be able to mark
presentational elements as presentation. It's a question of how user
agents and ATs should behave when the information provided by the author is
inconsistent. In that case, I would always argue for the user agent to
serve the user, presenting as much information as possible.
Interactive elements need to be in the accessibility tree. If not,
assistive technologies cannot effectively work as enhancements to the
underlying browser interface, with input and output working independently
from the DOM. If an author places role="none"/"presentation" on an
interactive element, that would be an author error and a robust approach
would be to treat it as role unknown.
The behavior should be the same when an element is given ARIA attributes
but either explicitly or by default has a role of none. Treat it as a
generic object, unknown role or no specific role, but ensure that the
information that was provided is available to the user. It can still be
reported as an authoring error in a validation tool, but we need a useful
behavior for user agents.
The examples Fred provided, of wanting to have grouping elements that
are transparent to assistive tech, are never something you would want to
toggle on or off by changing a role. (And roles should never be used to
toggle state, anyway.) I can see no good reason why someone would provide
aria-label or other ARIA attributes on an element that should be ignored.
The logical assumption is that the author did not understand the normal
impact of role="none".
aria-hidden, in contrast, can be toggled. It therefore makes sense that
aria-hidden should take precedence over aria-label: an author should not
have to remove all the ARIA attributes in order to temporarily hide some
content. However, if the author does not also take care to ensure that the
element cannot receive keyboard focus, we still have an inconsistent state
that the user agent needs to respond to: If the allegedly hidden content
receives focus, the user needs to know where they are.
So I would suggest the following series of priorities for the Core-AAM
guidelines on whether to include an element in the accessibility tree:
1. If element is not rendered (and therefore cannot receive focus)
EXCLUDE
2. Else, if element is in the current active tab order,
OR is identified as the aria-activedescendent of another element that
is in the current tab order, INCLUDE
3. Else, if element has aria-hidden="true" (on self or ancestor),
OR is hidden according to the host language semantics and does not
have aria-hidden="false" to override, EXCLUDE
4. Else, if element has other global ARIA attributes,
OR a computed role (by default or as set by the author) other than
none/presentation,
OR is referenced by an ARIA relationship of another (rendered and not
hidden) element,
OR is focusable but not in the current tab order (e.g., a
tabindex="-1"), INCLUDE
5. Else, if element has an author-supplied role of none/presentation,
EXCLUDE
6. Otherwise, INCLUDE or EXCLUDE according to host language semantics
Host languages and/or their mapping specs would therefore need to clearly
define:
Which elements are not rendered at all (and are therefore also
neither perceivable nor interactive, and cannot be "revealed" with
aria-hidden="false")
Which elements are in the current active tab order (factoring in
features such as "inert" subtrees in HTML 5.1), and which other
elements are focusable
Which elements are hidden (not perceivable/interactive and should be
treated as aria-hidden unless specifically over-ridden)
Default roles for each element type
Any language-specific rules for including or excluding elements (for
many SVG elements, this would be whether or not they have an
associated <title> or <desc>; for HTML, it would include things like
<img alt="" />)
A final sticky issue, however, is what to do about other events. Unlike
keyboard focus, there isn't always a clear association between an event and
the semantically relevant element. Event listeners can be added once to a
parent element to collect events from many child elements; without
examining the script, you don't know whether the action distinguishes
between the individual element targets. The ARIA event mapping guide
requires accessibility API events to be fired for changes to text content,
but that doesn't mean every span needs to watch for text mutations: these
can be reported by the nearest ancestor element that is included in the
accessibility tree.
The inclusion criteria "Elements that may fire an accessibility API event"
is therefore problematic. Whether or not an element may fire an
accessibility API event depends on whether or not it is included in the
accessibility tree. Looking through the accessibility API event list [1],
I think most of the events would either be covered by the test for a valid
role, or could be safely bubbled up to the nearest ancestor in the
accessibility tree. I would therefore remove that inclusion criteria
altogether.
I'm going to be cleaning up other parts of the SVG-AAM this weekend, but
I'll have to hold off making too many changes on these sections until there
is a group resolution on how to proceed for the Core-AAM.
~Amelia
[1]: https://www.w3.org/TR/wai-aria-implementation/#mapping_events
On 4 March 2016 at 10:43, Fred Esch <fesch@us.ibm.com> wrote:
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
Inactive hide details for Joseph Scheuhammer ---03/03/2016 10:57:00
AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote: >Joseph
Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia
Bellamy-Royds wrote: >
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
>
--1__
BBF5E2DFC6CF318f9e8a93df938690918c0ABBF5E2DFC6CF31
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
<html><body><p>Jumping to Amelia's thread.<br><br>I would appreciate as simple as possible methods to determine whether something should be included in the accessibility tree or not. Bryan and Stefan bring up complications with aria-hidden and CSS display:none, Joseph points brings up events as forcing inclusion in the accessibility tree. The Note in ARIA 1.1 is disturbing "<font size="4">At the time of this writing, </font><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-hidden"><tt><u><font size="4" color="#0000FF">aria-hidden</font></u></tt></a><tt><font size="4">="false"</font></tt><font size="4"> is known to work inconsistently in browsers. As future implementations improve, use caution and test thoroughly before relying on this approach." </font><br><br>We have too complicated a system. How can we give authors guidance if even browsers can't agree on what the behavior is.<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__=0ABBF5E2DFC6CF318f9e8a93df938690918c0AB@" 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__=0ABBF5E2DFC6CF318f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Amelia Bellamy-Royds ---03/05/2016 12:48:26 AM---I have to agree with Joseph's concerns. This isn't a"><font color="#424282">Amelia Bellamy-Royds ---03/05/2016 12:48:26 AM---I have to agree with Joseph's concerns. This isn't a matter of whether author's should be able to ma</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com></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">Joseph Scheuhammer <clown@alum.mit.edu>, 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/05/2016 12:48 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Conflicting inclusion/exclusion criteria for elements in the accessibility tree (Was: 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">I have to agree with Joseph's concerns.</font><br><br><font size="4">This isn't a matter of whether author's should be able to mark presentational elements as presentation. It's a question of how user agents and ATs should behave when the information provided by the author is inconsistent. In that case, I would always argue for the user agent to serve the user, presenting as much information as possible.</font><br><br><font size="4">Interactive elements need to be in the accessibility tree. If not, assistive technologies cannot effectively work as enhancements to the underlying browser interface, with input and output working independently from the DOM. If an author places role="none"/"presentation" on an interactive element, that would be an author error and a robust approach would be to treat it as role unknown. </font><br><br><font size="4">The behavior should be the same when an element is given ARIA attributes but either explicitly or by default has a role of none. Treat it as a generic object, unknown role or no specific role, but ensure that the information that </font><i><font size="4">was</font></i><font size="4"> provided is available to the user. It can still be reported as an authoring error in a validation tool, but we need a useful behavior for user agents.</font><br><br><font size="4">The examples Fred provided, of wanting to have grouping elements that are transparent to assistive tech, are never something you would want to toggle on or off by changing a role. (And roles should never be used to toggle state, anyway.) I can see no good reason why someone would provide aria-label or other ARIA attributes on an element that should be ignored. The logical assumption is that the author did not understand the normal impact of role="none".</font><br><br><font size="4">aria-hidden, in contrast, </font><i><font size="4">can</font></i><font size="4"> be toggled. It therefore makes sense that aria-hidden should take precedence over aria-label: an author should not have to remove all the ARIA attributes in order to temporarily hide some content. However, if the author does not also take care to ensure that the element cannot receive keyboard focus, we still have an inconsistent state that the user agent needs to respond to: If the allegedly hidden content receives focus, the user needs to know where they are.</font><br><br><font size="4">So I would suggest the following series of priorities for the Core-AAM guidelines on whether to include an element in the accessibility tree:</font><ul>1. <font size="4">If element is not rendered (and therefore cannot receive focus) EXCLUDE</font><br>2. <font size="4">Else, if element is in the current active tab order, <br>OR is identified as the aria-activedescendent of another element that is in the current tab order, INCLUDE</font><br>3. <font size="4">Else, if element has aria-hidden="true" (on self or ancestor), <br>OR is hidden according to the host language semantics and does not have aria-hidden="false" to override, EXCLUDE</font><br>4. <font size="4">Else, if element has other global ARIA attributes, <br>OR a computed role (by default or as set by the author) other than none/presentation, <br>OR is referenced by an ARIA relationship of another (rendered and not hidden) element,<br>OR is focusable but not in the current tab order (e.g., a tabindex="-1"), INCLUDE</font><br>5. <font size="4">Else, if element has an author-supplied role of none/presentation, EXCLUDE</font><br>6. <font size="4">Otherwise, INCLUDE or EXCLUDE according to host language semantics</font></ul><font size="4">Host languages and/or their mapping specs would therefore need to clearly define:</font><ul><ul type="disc"><li><font size="4">Which elements are not rendered at all (and are therefore also neither perceivable nor interactive, and cannot be "revealed" with aria-hidden="false")</font><li><font size="4">Which elements are in the current active tab order (factoring in features such as "inert" subtrees in HTML 5.1), and which other elements are focusable</font><li><font size="4">Which elements are hidden (not perceivable/interactive and should be treated as aria-hidden unless specifically over-ridden)</font><li><font size="4">Default roles for each element type</font><li><font size="4">Any language-specific rules for including or excluding elements (for many SVG elements, this would be whether or not they have an associated <title> or <desc>; for HTML, it would include things like <img alt="" />)</font></ul></ul><br><font size="4">A final sticky issue, however, is what to do about other events. Unlike keyboard focus, there isn't always a clear association between an event and the semantically relevant element. Event listeners can be added once to a parent element to collect events from many child elements; without examining the script, you don't know whether the action distinguishes between the individual element targets. The ARIA event mapping guide requires accessibility API events to be fired for changes to text content, but that doesn't mean every span needs to watch for text mutations: these can be reported by the nearest ancestor element that is included in the accessibility tree.</font><br><br><font size="4">The inclusion criteria "Elements that may fire an accessibility API event" is therefore problematic. Whether or not an element may fire an accessibility API event depends on whether or not it is included in the accessibility tree. Looking through the accessibility API event list [1], I think most of the events would either be covered by the test for a valid role, or could be safely bubbled up to the nearest ancestor in the accessibility tree. I would therefore remove that inclusion criteria altogether.</font><br><br><br><font size="4">I'm going to be cleaning up other parts of the SVG-AAM this weekend, but I'll have to hold off making too many changes on these sections until there is a group resolution on how to proceed for the Core-AAM.</font><br><br><font size="4">~Amelia</font><br><br><font size="4">[1]: </font><a href="https://www.w3.org/TR/wai-aria-implementation/#mapping_events"><u><font size="4" color="#0000FF">https://www.w3.org/TR/wai-aria-implementation/#mapping_events</font></u></a><br><br><br><font size="4"> </font><br><br><br><br><font size="4">On 4 March 2016 at 10:43, Fred Esch <</font><a href="mailto:fesch@us.ibm.com" target="_blank"><u><font size="4" color="#0000FF">fesch@us.ibm.com</font></u></a><font size="4">> wrote:</font><ul><font size="4">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 </font><i><font size="4">stack</font></i><font size="4"> in a </font><i><font size="4">stacked</font></i><font size="4"> bar chart. The children of the </font><i><font size="4">stack</font></i><font size="4"> group element are the individual bars that make up the stack and the </font><i><font size="4">stack</font></i><font size="4"> group element may contain </font><i><font size="4">stack</font></i><font size="4"> level information, for example the total value (height) of the </font><i><font size="4">stack</font></i><font size="4">. A good chart navigation tool would let a user visit the </font><i><font size="4">stack</font></i><font size="4"> and the user could either visit the individual bars in the </font><i><font size="4">stack</font></i><font size="4"> or move to another </font><i><font size="4">stack</font></i><font size="4">. Without using </font><i><font size="4">stack</font></i><font size="4"> level objects in the accessibility tree the concept of a </font><i><font size="4">stacked</font></i><font size="4"> 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></font></ul><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="404" colspan="2" valign="middle"><div align="center"><font size="5" 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__=0ABBF5E2DFC6CF318f9e8a93df938690918c0AB@" width="163" height="23" alt="IBM Watson" align="bottom"></td><td width="274" valign="middle"><font size="5" face="Verdana">Watson Release Management and Quality </font></td></tr></table>
<ul><font size="4"><br><br></font><img src="cid:2__=0ABBF5E2DFC6CF318f9e8a93df938690918c0AB@" width="16" height="16" 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 size="4" color="#424282">Joseph Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote: ></font><font size="4"><br></font><font color="#5F5F5F"><br>From: </font>Joseph Scheuhammer <<a href="mailto:clown@alum.mit.edu" target="_blank"><u><font color="#0000FF">clown@alum.mit.edu</font></u></a>><font color="#5F5F5F"><br>To: </font>Amelia Bellamy-Royds <<a href="mailto:amelia.bellamy.royds@gmail.com" target="_blank"><u><font color="#0000FF">amelia.bellamy.royds@gmail.com</font></u></a>>, Richard Schwerdtfeger <<a href="mailto:richschwer@gmail.com" target="_blank"><u><font color="#0000FF">richschwer@gmail.com</font></u></a>><font color="#5F5F5F"><br>Cc: </font>ARIA Working Group <<a href="mailto:public-aria@w3.org" target="_blank"><u><font color="#0000FF">public-aria@w3.org</font></u></a>><font color="#5F5F5F"><br>Date: </font>03/03/2016 10:57 AM<font color="#5F5F5F"><br>Subject: </font>Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group<font size="4"><br></font><hr width="100%" size="2" align="left" noshade><br><font size="4"><br><br></font><tt><font size="4"><br>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] </font></tt><a href="https://www.w3.org/WAI/ARIA/track/issues/708" target="_blank"><tt><u><font size="4" color="#0000FF">https://www.w3.org/WAI/ARIA/track/issues/708</font></u></tt></a><tt><font size="4"><br>[2] </font></tt><tt><u><font size="4" color="#0000FF"><br></font></u></tt><a href="http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change" target="_blank"><tt><u><font size="4" color="#0000FF">http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change</font></u></tt></a><tt><font size="4"><br>[3] </font></tt><a href="http://w3c.github.io/aria/aria/aria.html#presentation" target="_blank"><tt><u><font size="4" color="#0000FF">http://w3c.github.io/aria/aria/aria.html#presentation</font></u></tt></a><tt><font size="4"><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>> </font></tt><a href="https://github.com/w3c/aria/issues/136" target="_blank"><tt><u><font size="4" color="#0000FF">https://github.com/w3c/aria/issues/136</font></u></tt></a><tt><font size="4"><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>></font></tt><br><br></ul><BR>
</body></html>
--1__
BBF5E2DFC6CF318f9e8a93df938690918c0ABBF5E2DFC6CF31--
--0__
BBF5E2DFC6CF318f9e8a93df938690918c0ABBF5E2DFC6CF31
Content-type: image/gif;
name="0A571731.gif"
Content-Disposition: inline; filename="0A571731.gif"
Content-ID: <1__
BBF5E2DFC6CF318f9e8a93df938690918c0AB@>
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__
BBF5E2DFC6CF318f9e8a93df938690918c0ABBF5E2DFC6CF31
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <2__
BBF5E2DFC6CF318f9e8a93df938690918c0AB@>
Content-Transfer-Encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__
BBF5E2DFC6CF318f9e8a93df938690918c0ABBF5E2DFC6CF31--
Received on Wednesday, 9 March 2016 16:07:08 UTC