- From: Fred Esch <fesch@us.ibm.com>
- Date: Tue, 15 Mar 2016 08:14:52 -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: <201603151324.u2FDObuQ012113@d03av03.boulder.ibm.com>
One undesirable aspect for authors of the steps Amelia has - is the last
part of step 4 (OR is focusable but not in the current tab order (e.g., a
tabindex="-1")is not in step 2. I can see making the presence of a tabindex
a factor in inclusion in the accessibility tree, but not the value of the
tabindex. As it is, it sounds like some elements will be always be included
in the accessibility tree regardless of tabindex value and others will be
included/excluded based on the value of a tabindex. If this is true, is
there a table that explains which category an element falls in? Having rule
3 between 2 and 4 makes things even less predictable for authors.
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
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>, Fred
Esch/Arlington/IBM@IBMUS
Cc: ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger
<richschwer@gmail.com>
Date: 03/14/2016 04:19 PM
Subject: Re: Conflicting inclusion/exclusion criteria for elements in
the accessibility tree (Was: Re: [ARIA] Agenda: March 3, 2016
WAI-ARIA Working Group)
Thanks Amelia, you raise a number of good points. My comments are inline.
On 2016-03-05 12:48 AM, Amelia Bellamy-Royds wrote:
> 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.
What user agents generally do in this case is ignore the role="none",
and fall back on the role implied by the element itself. An example:
If the markup is '<a role="none" href="somewhere.com">', then the AAPI
role is "link". Still, there may be cases where it's difficult to find
a meaningful implicit role. I will investigate. However, I don't
believe that user agents treat it as an unknown role, or, if they do,
it's only in rare cases. The main reason is that even where AAPIs
provide for an "unknown role", that's not very useful to an AT.
>
> 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
>
I *think* this is right, although I want to mull it over some just in
case I can think of a counter example. If it is right, then it says the
same thing as the Core-AAM does, although in a different way -- the
core-aam has separate sections for exclusion and inclusion, and it's not
immediately clear how the two sections work together.
> 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.
First, whether an element might fire an accessibility event can be
captured, in part, by its role, as you allude to. There is a basic
abstract "widget" role in the ARIA taxonomy, which is defined as "an
interactive component...". There are numerous roles that ultimately
subclass the widget role, including gridcell, slider, checkbox, menu,
and others. Any of the roles in this branch of the taxonomy potentially
fire accessibility events. Hence, any element that has a widget role,
either explicitly or implicitly, can cause an accessibility event, and
therefore has an associated accessible object.
Secondly, as you noted, there is a section on AAPI events [1a]. That
section includes a table documenting the relationship between various
aria-* states and properties and AAPI events. See [2], starting with
aria-activedescendant. The left most column of the table is a list of
aria-* attributes. The implication is that if an element has one of
those aria-* attributes, then it can cause an accessibility event.
Using aria-busy as an example: If an element has aria-busy specified
for it, it can change between its two values (true and false), and
thereby cause an "aria-busy-changed' event in the accessibility API.
The same logic applies to the other aria-* attributes listed in the
table. The bottom line is that the presence of any of these aria-*
attributes entails that the element can cause an accessibility event.
Hence, the element has an accessible object in the accessibility tree.
Thirdly, live regions are potential event sources. Any element with an
aria-live attribute can cause an event.
Fourth, the proposed aria-keyshortcuts attribute documents what the
author has provided by way of keyboard activation of the element. That
entails that the element handles key events, which will have associated
key events in the AAPI.
I'm not sure if that covers all the cases, but perhaps it's the lion's
share. In any case, there are a number of ways to determine if an
element can cause an accessibility event, and, therefore, needs an
accessible object in the accessibility tree, if not already present.
>
>
> 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
[1a] https://www.w3.org/TR/core-aam-1.1/#mapping_events
[2] https://www.w3.org/TR/core-aam-1.1/#event-aria-activedescendant
>
>
>
>
>
> On 4 March 2016 at 10:43, Fred Esch <fesch@us.ibm.com
> <mailto: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 <mailto: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__
BBF5E4DFD55EE58f9e8a93df938690918c0ABBF5E4DFD55EE5
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
<html><body><p>One undesirable aspect for authors of the steps Amelia has - is the last part of step 4 <i>(</i><tt><i>OR is focusable but not in the current tab order (e.g., a tabindex="-1")</i></tt>is not in step 2. I can see making the<b> presence</b> of a tabindex a factor in inclusion in the accessibility tree, but not the <b><i>value</i></b> of the tabindex. As it is, it sounds like some elements will be always be included in the accessibility tree regardless of tabindex <b><i>value</i></b> and others will be included/excluded based on the <b><i>value</i></b> of a tabindex. If this is true, is there a table that explains which category an element falls in? Having rule 3 between 2 and 4 makes things even less predictable for authors. <br><br><br><br><tt> 2. Else, if element is in the current active tab order,<br>> OR is identified as the aria-activedescendent of another element<br>> that is in the current tab order, INCLUDE<br>> 3. Else, if element has aria-hidden="true" (on self or ancestor),<br>> OR is hidden according to the host language semantics and does not<br>> have aria-hidden="false" to override, EXCLUDE<br>> 4. Else, if element has other global ARIA attributes,<br>> OR a computed role (by default or as set by the author) other than<br>> none/presentation,<br>> OR is referenced by an ARIA relationship of another (rendered and<br>> not hidden) element,<br>> OR is focusable but not in the current tab order (e.g., a<br>> tabindex="-1"), INCLUDE</tt><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__=0ABBF5E4DFD55EE58f9e8a93df938690918c0AB@" 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__=0ABBF5E4DFD55EE58f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Joseph Scheuhammer ---03/14/2016 04:19:05 PM---Thanks Amelia, you raise a number of good points. My "><font color="#424282">Joseph Scheuhammer ---03/14/2016 04:19:05 PM---Thanks Amelia, you raise a number of good points. My comments are inline. On 2016-03-05 12:48 AM, A</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>, Fred Esch/Arlington/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">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/14/2016 04:19 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: 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><tt>Thanks Amelia, you raise a number of good points. My comments are inline.<br><br>On 2016-03-05 12:48 AM, Amelia Bellamy-Royds wrote:<br>> I have to agree with Joseph's concerns.<br>><br>> This isn't a matter of whether author's should be able to mark <br>> presentational elements as presentation. It's a question of how user <br>> agents and ATs should behave when the information provided by the <br>> author is inconsistent. In that case, I would always argue for the <br>> user agent to serve the user, presenting as much information as possible.<br>><br>> Interactive elements need to be in the accessibility tree. If not, <br>> assistive technologies cannot effectively work as enhancements to the <br>> underlying browser interface, with input and output working <br>> independently from the DOM. If an author places <br>> role="none"/"presentation" on an interactive element, that would be an <br>> author error and a robust approach would be to treat it as role unknown.<br><br>What user agents generally do in this case is ignore the role="none", <br>and fall back on the role implied by the element itself. An example: <br>If the markup is '<a role="none" href="somewhere.com">', then the AAPI <br>role is "link". Still, there may be cases where it's difficult to find <br>a meaningful implicit role. I will investigate. However, I don't <br>believe that user agents treat it as an unknown role, or, if they do, <br>it's only in rare cases. The main reason is that even where AAPIs <br>provide for an "unknown role", that's not very useful to an AT.<br><br>><br>> The behavior should be the same when an element is given ARIA <br>> attributes but either explicitly or by default has a role of none. <br>> Treat it as a generic object, unknown role or no specific role, but <br>> ensure that the information that /was/ provided is available to the <br>> user. It can still be reported as an authoring error in a validation <br>> tool, but we need a useful behavior for user agents.<br>><br>> The examples Fred provided, of wanting to have grouping elements that <br>> are transparent to assistive tech, are never something you would want <br>> to toggle on or off by changing a role. (And roles should never be <br>> used to toggle state, anyway.) I can see no good reason why someone <br>> would provide aria-label or other ARIA attributes on an element that <br>> should be ignored. The logical assumption is that the author did not <br>> understand the normal impact of role="none".<br>><br>> aria-hidden, in contrast, /can/ be toggled. It therefore makes sense <br>> that aria-hidden should take precedence over aria-label: an author <br>> should not have to remove all the ARIA attributes in order to <br>> temporarily hide some content. However, if the author does not also <br>> take care to ensure that the element cannot receive keyboard focus, we <br>> still have an inconsistent state that the user agent needs to respond <br>> to: If the allegedly hidden content receives focus, the user needs to <br>> know where they are.<br>><br>> So I would suggest the following series of priorities for the Core-AAM <br>> guidelines on whether to include an element in the accessibility tree:<br>><br>> 1. If element is not rendered (and therefore cannot receive focus)<br>> EXCLUDE<br>> 2. Else, if element is in the current active tab order,<br>> OR is identified as the aria-activedescendent of another element<br>> that is in the current tab order, INCLUDE<br>> 3. Else, if element has aria-hidden="true" (on self or ancestor),<br>> OR is hidden according to the host language semantics and does not<br>> have aria-hidden="false" to override, EXCLUDE<br>> 4. Else, if element has other global ARIA attributes,<br>> OR a computed role (by default or as set by the author) other than<br>> none/presentation,<br>> OR is referenced by an ARIA relationship of another (rendered and<br>> not hidden) element,<br>> OR is focusable but not in the current tab order (e.g., a<br>> tabindex="-1"), INCLUDE<br>> 5. Else, if element has an author-supplied role of none/presentation,<br>> EXCLUDE<br>> 6. Otherwise, INCLUDE or EXCLUDE according to host language semantics<br>><br><br>I *think* this is right, although I want to mull it over some just in <br>case I can think of a counter example. If it is right, then it says the <br>same thing as the Core-AAM does, although in a different way -- the <br>core-aam has separate sections for exclusion and inclusion, and it's not <br>immediately clear how the two sections work together.<br><br>> Host languages and/or their mapping specs would therefore need to <br>> clearly define:<br>><br>> * Which elements are not rendered at all (and are therefore also<br>> neither perceivable nor interactive, and cannot be "revealed" with<br>> aria-hidden="false")<br>> * Which elements are in the current active tab order (factoring in<br>> features such as "inert" subtrees in HTML 5.1), and which other<br>> elements are focusable<br>> * Which elements are hidden (not perceivable/interactive and should<br>> be treated as aria-hidden unless specifically over-ridden)<br>> * Default roles for each element type<br>> * Any language-specific rules for including or excluding elements<br>> (for many SVG elements, this would be whether or not they have an<br>> associated <title> or <desc>; for HTML, it would include things<br>> like <img alt="" />)<br>><br>><br>> A final sticky issue, however, is what to do about other events. <br>> Unlike keyboard focus, there isn't always a clear association between <br>> an event and the semantically relevant element. Event listeners can <br>> be added once to a parent element to collect events from many child <br>> elements; without examining the script, you don't know whether the <br>> action distinguishes between the individual element targets. The ARIA <br>> event mapping guide requires accessibility API events to be fired for <br>> changes to text content, but that doesn't mean every span needs to <br>> watch for text mutations: these can be reported by the nearest <br>> ancestor element that is included in the accessibility tree.<br>><br>> The inclusion criteria "Elements that may fire an accessibility API <br>> event" is therefore problematic. Whether or not an element may fire <br>> an accessibility API event depends on whether or not it is included in <br>> the accessibility tree. Looking through the accessibility API event <br>> list [1], I think most of the events would either be covered by the <br>> test for a valid role, or could be safely bubbled up to the nearest <br>> ancestor in the accessibility tree. I would therefore remove that <br>> inclusion criteria altogether.<br><br>First, whether an element might fire an accessibility event can be <br>captured, in part, by its role, as you allude to. There is a basic <br>abstract "widget" role in the ARIA taxonomy, which is defined as "an <br>interactive component...". There are numerous roles that ultimately <br>subclass the widget role, including gridcell, slider, checkbox, menu, <br>and others. Any of the roles in this branch of the taxonomy potentially <br>fire accessibility events. Hence, any element that has a widget role, <br>either explicitly or implicitly, can cause an accessibility event, and <br>therefore has an associated accessible object.<br><br>Secondly, as you noted, there is a section on AAPI events [1a]. That <br>section includes a table documenting the relationship between various <br>aria-* states and properties and AAPI events. See [2], starting with <br>aria-activedescendant. The left most column of the table is a list of <br>aria-* attributes. The implication is that if an element has one of <br>those aria-* attributes, then it can cause an accessibility event. <br>Using aria-busy as an example: If an element has aria-busy specified <br>for it, it can change between its two values (true and false), and <br>thereby cause an "aria-busy-changed' event in the accessibility API. <br>The same logic applies to the other aria-* attributes listed in the <br>table. The bottom line is that the presence of any of these aria-* <br>attributes entails that the element can cause an accessibility event. <br>Hence, the element has an accessible object in the accessibility tree.<br><br>Thirdly, live regions are potential event sources. Any element with an <br>aria-live attribute can cause an event.<br><br>Fourth, the proposed aria-keyshortcuts attribute documents what the <br>author has provided by way of keyboard activation of the element. That <br>entails that the element handles key events, which will have associated <br>key events in the AAPI.<br><br>I'm not sure if that covers all the cases, but perhaps it's the lion's <br>share. In any case, there are a number of ways to determine if an <br>element can cause an accessibility event, and, therefore, needs an <br>accessible object in the accessibility tree, if not already present.<br><br>><br>><br>> I'm going to be cleaning up other parts of the SVG-AAM this weekend, <br>> but I'll have to hold off making too many changes on these sections <br>> until there is a group resolution on how to proceed for the Core-AAM.<br>><br>> ~Amelia<br>><br>> [1]: </tt><tt><a href="https://www.w3.org/TR/wai-aria-implementation/#mapping_events">https://www.w3.org/TR/wai-aria-implementation/#mapping_events</a></tt><tt><br><br>[1a] </tt><tt><a href="https://www.w3.org/TR/core-aam-1.1/#mapping_events">https://www.w3.org/TR/core-aam-1.1/#mapping_events</a></tt><tt><br>[2] </tt><tt><a href="https://www.w3.org/TR/core-aam-1.1/#event-aria-activedescendant">https://www.w3.org/TR/core-aam-1.1/#event-aria-activedescendant</a></tt><tt><br><br>><br>><br>><br>><br>><br>> On 4 March 2016 at 10:43, Fred Esch <fesch@us.ibm.com <br>> <</tt><tt><a href="mailto:fesch@us.ibm.com">mailto:fesch@us.ibm.com</a></tt><tt>>> wrote:<br>><br>> Joseph,<br>><br>> For SVG it is imperative that an author be able to mark an element<br>> with the role none or presentation and know that the element will<br>> not appear in the accessibility tree. SVG is too messy to force<br>> authors and authoring tools to work through anything but the<br>> simplest rule.<br>><br>> Case 1: A group element is only present in the SVG to pass along<br>> common attributes to their children. For instance you may group<br>> text elements for labeling items around a circle, by their anchor<br>> location. This group element has no semantic meaning. This is a<br>> common use for group elements as it makes the SVG smaller and<br>> makes it easier to edit reused styles. This group element should<br>> not be included in the accessibility tree.<br>><br>> Case 2: A group element has semantic meaning and the parent/child<br>> relationship is significant. An example, would be a group element<br>> representing a /stack/ in a /stacked/ bar chart. The children of<br>> the /stack/ group element are the individual bars that make up the<br>> stack and the /stack/ group element may contain /stack/ level<br>> information, for example the total value (height) of the /stack/.<br>> A good chart navigation tool would let a user visit the /stack/<br>> and the user could either visit the individual bars in the /stack/<br>> or move to another /stack/. Without using /stack/ level objects in<br>> the accessibility tree the concept of a /stacked/ chart would be<br>> lost. This group element should appear in the accessibility tree.<br>><br>> Programmatically, both Case 1 and Case 2 group elements may look<br>> similar. Authoring tools (few developer hand edit SVG) need to<br>> provide a straight forward way to disallow elements from being in<br>> the accessibility tree. Authors need a straight forward way of to<br>> disallow elements from being in the accessibility tree. Without an<br>> author friendly way of identifying case 1 from case 2 the<br>> underlying concept of the graphic can be lost.<br>><br>> The SVG accessibility task force decided that using a role of none<br>> or presentation was the golden hammer that developers and<br>> authoring tools need to exclude elements from the accessibility<br>> tree. Amelia is add the changes in. If we need to change the ARIA<br>> spec lets change it.<br>><br>><br>> Regards,<br>><br>> Fred Esch<br>> Watson, IBM, W3C Accessibility<br>> IBM Watson Watson Release Management and Quality<br>><br>><br>><br>> Inactive hide details for Joseph Scheuhammer ---03/03/2016<br>> 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote:<br>> >Joseph Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02<br>> 10:07 PM, Amelia Bellamy-Royds wrote: ><br>><br>> From: Joseph Scheuhammer <clown@alum.mit.edu><br>> To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Richard<br>> Schwerdtfeger <richschwer@gmail.com <</tt><tt><a href="mailto:richschwer@gmail.com">mailto:richschwer@gmail.com</a></tt><tt>>><br>> Cc: ARIA Working Group <public-aria@w3.org><br>> Date: 03/03/2016 10:57 AM<br>> Subject: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group<br>> ------------------------------------------------------------------------<br>><br>><br>><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<br>> 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<br>> 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<br>> 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<br>> 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<br>> 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"<br>> 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<br>> 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<br>> 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<br>> both<br>> understandable and operable" [3].<br>><br>> 2. Using role="presentation" in conjunction with a global aria<br>> property<br>> is also an author error. The role says that the element has no<br>> 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<br>> explicit or<br>> inherited role of presentation" [3].||||||<br>><br>> In summary, the core-aam inclusion rules need changes, but those<br>> changes<br>> must be in accordance with the ARIA spec. If it's necessary that<br>> 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<br>> SVG-AAM<br>> > matches how others think Core-AAM should be interpreted. And it<br>> 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><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__
BBF5E4DFD55EE58f9e8a93df938690918c0ABBF5E4DFD55EE5--
--0__
BBF5E4DFD55EE58f9e8a93df938690918c0ABBF5E4DFD55EE5
Content-type: image/gif;
name="0E062391.gif"
Content-Disposition: inline; filename="0E062391.gif"
Content-ID: <1__
BBF5E4DFD55EE58f9e8a93df938690918c0AB@>
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__
BBF5E4DFD55EE58f9e8a93df938690918c0ABBF5E4DFD55EE5
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <2__
BBF5E4DFD55EE58f9e8a93df938690918c0AB@>
Content-Transfer-Encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__
BBF5E4DFD55EE58f9e8a93df938690918c0ABBF5E4DFD55EE5--
Received on Tuesday, 15 March 2016 13:25:15 UTC