1123248 - incorrect accessible name calculation - includes hidden content

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[steve faulkner]

The accessible name for table cells in a grid includes content hidden using aria-hidden=true

go to http://s.codepen.io/stevef/debug/WbjxyY
Interact with content using JAWS
The down arrow symbol is announced even though it is marked as hidden:
<span aria-hidden="true">▼</span>

Looking at the accessibility tree with an object inspection tool it can be seen that the symbol is included as part of the accessible name in Firefox.

In Chrome it is not, this is the correct behaviour as per the ARIA accessible name calculation.
http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#mapping_additional_nd

Comment 1

[steve faulkner]

related thread on PF public list https://lists.w3.org/Archives/Public/public-pfwg/2015Jan/thread.html#first

Comment 2

[Joseph Scheuhammer (:clown)]

(In reply to steve faulkner from comment #0)
> ...the correct behaviour as per the ARIA
> accessible name calculation.
> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.
> html#mapping_additional_nd

Closer link:
http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#step2A

Comment 3

[James Teh [:Jamie]]

Pretty sure this applies to any case where name is calculated from descendants. It certainly applies to role="button". I keep meaning to file this bug and keep forgetting. :)

Should this be in Core -> Disability access APIs?

Comment 4

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #3)
> Pretty sure this applies to any case where name is calculated from
> descendants. It certainly applies to role="button". I keep meaning to file
> this bug and keep forgetting. :)

ok, what do you think about bug 1123360? it may be blocking of this one?

Comment 5

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #4)
> ok, what do you think about bug 1123360?
We've had that debate many times. :) As far as NVDA is concerned, that will work. Beyond that, I'm at the point where I don't see the point in debating it any further.

> it may be blocking of this one?
It should solve this problem, yes.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #5)
> (In reply to alexander :surkov from comment #4)
> > ok, what do you think about bug 1123360?
> We've had that debate many times. :)

Right, that's all about aria-hidden :) I just got impression that everybody says it should work but nobody was really up for it. That's why I didn't proceed with it.

> As far as NVDA is concerned, that will
> work. Beyond that, I'm at the point where I don't see the point in debating
> it any further.

May I ask you to comment your opinion (summary) into the bug for the record? Especially if it differs from proposal.

Comment 7

[Carolyn MacLeod]

Tripped over this problem when testing a drop-down menu containing radio menu items.
Here's the rendered html for the checked menu item:

    <span tabindex="-1" class="dropdownMenuItem" role="menuitemradio" aria-checked="true">
      <span class="check" aria-hidden="true">\25CF</span>
      <span>Project</span>
    </span>

Note that we are using the unicode symbol for "black filled-in circle or bullet" to visually indicate that the radio item is checked, and we are using aria-checked="true" for AT.

Testing on Chrome, where the aria-hidden="true" span is pruned as per the spec, NVDA and JAWS say the following:
NVDA: Project radio menu item checked 1 of 1
JAWS: Project checked 1 of 1
(PS: ignore the "1 of 1". It should be "1 of 2". I've opened a Chrome bug for that).

On Firefox, however, the aria-hidden="true" span is not pruned, and this is what you hear:
NVDA: circle Project radio menu item checked 1 of 2
JAWS: circle bullet Project checked 1 of 2

This is unexpected.
Saying "circle" or "circle bullet" is redundant with saying "checked".
Not only is it redundant, but it is potentially confusing, because "circle" could mean something in the context of the application. For example, there could be a "circle project".
Or for a very contrived example, imagine a radio group of shapes: circle, square, and triangle.
If you hear "circle square checked", which one is checked: circle, or square?

I feel very strongly that in this particular case (which is basically the same as the case in comment 0), the aria-hidden span should be pruned.

I read through several Firefox bugs about aria-hidden, including the "won't fix" ones, and the one about propagating aria-hidden to descendants so that AT don't have the expense of walking up the tree.
It seems to me that support for pruning aria-hidden elements keeps stalling because of attempts to solve the big picture all at once.

Would it be possible instead to just prune non-interactive aria-hidden elements for now?
Something like: if a span or div or img has aria-hidden="true", no events, no tabindex, and is not in a contenteditable, then prune it.
I think that would fix the majority of appropriate uses of aria-hidden="true".

As for the big picture:
- it's not clear that aria-hidden="false" will ever be real (it's in the ARIA spec, but there's a cautionary note about it being inconsistently supported)
- the "inert" attribute (if it ever becomes real), will likely have some interplay with aria-hidden="true" (it may even help reduce author error around aria-hidden)
- my understanding of what Chrome does if author error causes an interactive element with aria-hidden="true" to receive focus, is to move focus up to the parent of the aria-hidden element (all the way up to document body if necessary)
- if the dialog element becomes real, and if the aria-hidden element is a descendant of a visible dialog, then focus would move to the parent dialog

Comment 8

[Carolyn MacLeod]

Another example where the current Firefox behavior of not pruning a span with aria-hidden="true" is unexpected: https://developer.paciellogroup.com/blog/2018/02/short-note-on-hiding-stuff-in-interactive-elements-from-screen-readers/

Comment 9

[Carolyn MacLeod]

Actually, I just read the section on excluding elements from the accessibility tree in the Core AAM spec: https://www.w3.org/TR/core-aam-1.1/#exclude_elements2

> ... user agents SHOULD NOT include the following elements in the accessibility tree:
> - Elements, including their descendants, that have a WAI-ARIA global attribute of aria-hidden="true". In other words, aria-hidden="true" on a parent overrides aria-hidden="false" on descendants.

That final sentence is good news - it means that aria-hidden="false" is not a problem. You do not have to bend over backwards to support it. It is basically a no-op that can safely be ignored by browsers and AT.

So the only aria-hidden value that matters is "true", and it means "prune this element and all of its descendants from the accessibility tree".

I opened https://github.com/w3c/aria/issues/705 to clarify the wording for aria-hidden="false" in the aria-hidden spec, and hopefully to also clearly warn authors not to put aria-hidden="true" on rendered interactive elements.

Comment 10

[alexander :surkov (:asurkov)]

so, we probably should bump a priority of bug 1349223, got get in sync with other browsers on this topic.

Comment 11

[james]

I think this is also causing the following accName test to fail
https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_file-label-inline-hidden-elements

Comment 12

[James Teh [:Jamie]]

Fixed by bug 1349223.