W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group

From: Joseph Scheuhammer <clown@alum.mit.edu>
Date: Thu, 3 Mar 2016 10:55:54 -0500
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Richard Schwerdtfeger <richschwer@gmail.com>
Cc: ARIA Working Group <public-aria@w3.org>
Message-ID: <56D85E8A.3070008@alum.mit.edu>
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 

[1] https://www.w3.org/WAI/ARIA/track/issues/708
[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


'Die Wahrheit ist Irgendwo da Drau├čen. Wieder.'
                  - C. Carter -
Received on Thursday, 3 March 2016 15:56:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:20 UTC