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

>>> Except when aria-hidden is explicitly set to "false" ... :)

So true.

- Stefan

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Mittwoch, 9. März 2016 07:59
To: Joseph Scheuhammer <clown@alum.mit.edu>; Fred Esch <fesch@us.ibm.com>
Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>; ARIA Working Group <public-aria@w3.org>; Richard Schwerdtfeger <richschwer@gmail.com>
Subject: RE: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group

" The only thing that comes close to a golden hammer is CSS display:none."

Except when aria-hidden is explicitly set to "false" ... :) 

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Tuesday, March 08, 2016 1:55 PM
To: Fred Esch <fesch@us.ibm.com>
Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>; ARIA Working Group <public-aria@w3.org>; Richard Schwerdtfeger <richschwer@gmail.com>
Subject: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group

On 2016-03-07 10:46 AM, Fred Esch wrote:
> Obviously, if you add a tabindex, aria-label and/or an event listener 
> to it, it still won't appear in the accessibility tree.

The question is, if one were to add tabindex to an <feBlend>, could the user TAB navigate to the element and put focus it?  Or could the user click on the element and either cause a click event, or cause focus to move there, or both?  If the answer is "no, never", then you are correct that no accessible object will appear in the tree for <feBlend.>.  But, that's due to the nature of the element itself.  In this case, the presentation role is not needed, as I noted in my previous email about your first case involving the group element.  Amelia has noted this as well in another thread -- that some elements, by their essential character, are not exposed [1].  The <script> element is an example from 
HTML.   Whether an element has this property is defined in the relevant 
-aam specification's element mapping table.

(Aside:  the criterion regarding whether an element can cause an AAPI event is just that.  Whether anything is listening is not relevant.  The issue is twofold -- that the element can cause an event, and that an AT
*could* be listening for it.  The browser has no way of knowing the latter.  To provide for the possibility that an AT is listening, the browser exposes an accessible object in the a11y tree as the source of the potential events.)

> Group elements are not automatically included in the accessibility 
> tree. You have to add something like a tabindex to include them. I am 
> fine with considering it an authoring error if you have a tabindex and 
> role of none - and when you have both it fails validation.

It seems we agree about SVG group elements.  Still, when it comes to loading and displaying a page, browsers do not do much validation. Given your example, the browser determines whether an element has a tabindex on it, and/or is focusable, and/or can emit a focus event. If so, that element will be represented in the accessibility tree, regardless of the author error.

> Is aria-hidden the 'golden hammer' that always works? And refresh my 
> memory, aria-hidden does not affect the elements children, right?

No, aria-hidden is also not a golden hammer.  If the element is actually displayed on screen, and can take focus --  the situation is similar to that of role="presentation" [2].  And to refresh your memory, aria-hidden does apply to the element's descendants:
"An element is considered hidden if it, or any of its ancestors are not rendered or have their aria-hidden attribute value set to true." [3]

The only thing that comes close to a golden hammer is CSS display:none. 
Adding tabindex to such an element has no effect since there is nothing on screen to focus, the element cannot be scrolled to, can't be selected, and, in general, cannot be interacted with. For all intents and purposes, it's not there.  Thus, it does not appear in the accessibility tree.  Similarly for HTML elements styled with visibility:hidden, but not necessarily for SVG elements, since they can emit events even if they are visibility:hidden, depending on the pointer-events attribute.

If an author is using an element purely for layout, decoration etc, in short, purely for presentation, and they are using an element that might be exposed, then it's their responsibility to ensure that the element is in fact used as so described, and then set role="none".

[1] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0043.html
[2] http://w3c.github.io/aria/core-aam/core-aam.html#ariaHiddenTrue
[3] https://www.w3.org/TR/wai-aria-1.1/#aria-hidden

--
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                  - C. Carter -

Received on Wednesday, 9 March 2016 08:13:12 UTC