- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Mon, 14 Mar 2016 16:17:57 -0400
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Fred Esch <fesch@us.ibm.com>
- Cc: ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>
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 -
Received on Monday, 14 March 2016 20:18:36 UTC