Re: The aria-hidden attribute not being honored within naming calculation for parent controls?

Hi Bryan,

the API Mapping spec is clear here: nothing should be mapped.

>From the original idea of hidden also derives the behaviour that AT in their DOM modes such as Jaws VPC mode will ignore elements with aria-hidden when arrowing through the document.

It is likely that Jaws has potential bugs here since I get similar reports from our developers using aria-hidden on text nodes. For instance, if parts of a text node are hidden with aria-hidden and the entire element is referenced with aria-describedby and the element holding the describedby relationship is focused, Jaws will read the ENTIRE text content, also the parts that were hidden.

Regards
Stefan



Sent from my iPad

On 17.01.2015, at 01:32, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

Hi,
I wrote the attached grid sample to identify a bug in JAWS+IE where supporting attributes like aria-sort, aria-readonly, and aria-haspopup, are not being conveyed when Forms Mode is active, and discovered another issue in the accessibility tree in both IE and FF.

The grid consists of column nodes, which include a span tag that contains a Unicode down arrow symbol, marked with aria-hidden=”true” to remove it from the accessibility tree, which doesn’t remove it actually but flags it as hidden.

So, regardless, the naming calculation still sets the accessible name for each columnheader node as the text + the hidden symbol text, even though it should not be included since I am explicitly telling it not to using aria-hidden=”true”. This results in JAWS announcing the hidden symbol text as part of the label despite my attempts to keep this out of the accessible name for that node.

So I guess my question is, shouldn’t nodes marked up with aria-hidden=”true” be omitted from the accessible name calculation within the accessibility tree?

Thanks,
Bryan
<test.html>