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 Tuesday, 8 March 2016 21:55:47 UTC