WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-hidden and NVDA, isn't this a bug?

for

From: Bryan Garaventa
Date: Aug 10, 2013 6:46PM

I'm not really sure what you mean by "a section of a form is hidden
according to the business rules in effect at the time".

If you want to hide something visually as well as from screen readers, the
best way is to use CSS such as "display:none", which also prevents all
active elements within the container from appearing in the tab order as
expected.

The ARIA attribute aria-hidden however is entirely different, and only hides
the content from screen readers, but does nothing visually by itself, and
doesn't change the keyboard accessibility of any active elements.

E.G

<div aria-hidden="true">
<form>
<input title="Test" type="text" />
</form>
</div>

Even though screen readers can't detect anything within the Div when
arrowing in the Virtual Buffer, you can still tab to the form field
regardless, which is not announced because there is nothing in the
accessibility tree to identify what the active element is. This causes a
dead tab stop for screen reader users.

If you want to truly prevent something from receiving focus when combined
with aria-hidden, then you need to set tabindex="-1" on all active elements
within that container as well.

You could also bind the attribute with CSS, such as:

*[aria-hidden="true"] {
display: none;
}

Which will hide it visually as well.

But, if you need the content to remain visible, then tabindex is the only
way to prevent keyboard focus from going into these areas.

----- Original Message -----
From: "Dave Merrill" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Saturday, August 10, 2013 5:15 PM
Subject: Re: [WebAIM] aria-hidden and NVDA, isn't this a bug?


> @Birkir: Minor point, but I'm pretty sure it's invalid HTML to put a div
> inside a list with the intent of creating a container for some items that
> you can apply an attribute to (aria-hidden). The only item container
> allowed there is <optgroup>, but that will have a visual effect of its
> own.
> The div strategy may still "work", but it wouldn't surprise me if its
> behavior was browser dependent.
>
> @Bryan: I'm a developer, not by any means an accessibility expert, but
> your
> last paragraph surprises me. Are you saying that if a section of a form is
> hidden according to the business rules in effect at the time, that's not
> sufficient to remove the fields inside it from the tab order? If so, what
> are you supposed to do, disable those fields too? I've never done that,
> and
> I've never seen that behavior in standard browsers.
>
> Dave Merrill
>
>
> On Sat, Aug 10, 2013 at 3:48 PM, Bryan Garaventa <
> <EMAIL REMOVED> > wrote:
>
>> This is sort of tricky.
>>
>> JAWS' ability to reevaluate the elements removed from the accessibility
>> tree
>> using aria-hidden may be useful, but it's also misleading.
>>
>> The use of aria-hidden doesn't actually change the elements in the DOM at
>> all, meaning that they still exist within their native containers. Such
>> as
>> lists having the same number of LIs, and tables having the same number of
>> TDs, regardless what is announced by the screen reader.
>>
>> So, if you use aria-hidden to simulate a properly formed data table
>> structure by hiding extra cells, it is still an improperly formed data
>> table
>> in the browser, and will likely have accessibility issues for other ATs.
>>
>> The same is true for ULs, where lists are defined by the number of LIs
>> within, and surrounding the LI tags with different container elements
>> inside
>> of the UL or OL may present different accessibility issues, regardless
>> whether aria-hidden is applied.
>>
>> I suspect NVDA is evaluating the DOM directly for this information, which
>> is
>> why it is announcing these values. Perhaps one of the NVDA guys here can
>> elaborate further to clarify.
>>
>> The use of aria-hidden to hide an element including all child elements
>> should work on any element type, not just containers.
>>
>> Keep in mind that this doesn't effect the tab order of active elements at
>> all. So, if you have an active element within the boundary of a container
>> hidden via aria-hidden, it will still be in the tab order regardless, and
>> will sound like a dead tab stop for screen reader users.
>>
>>
>> ----- Original Message -----
>> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
>> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> Sent: Saturday, August 10, 2013 12:17 PM
>> Subject: [WebAIM] aria-hidden and NVDA, isn't this a bug?
>>
>>
>> > Greetings wise ones
>> >
>> > Opinions needed and welcome.
>> > I am experimenting with use of aria-hidden to hide lists/list items
>> > and table cells.
>> > This works nicely in Jaws, but not in NVDA.
>> >
>> > Starting with lists.
>> > Applying aria-hidden on a list item
>> > <code>
>> > <ul>
>> > <li>List item #1</li>
>> > <li aria-hidden="true">Hidden item 1</li>
>> > <li aria-hidden="true">Hidden item #2</li>
>> > </ul>
>> > </code>
>> > NVDA respects the aria-hidden use for the list items themselves, but
>> > announces, in the list summary: "list with 3 items", even if the list
>> > only contains one, and the quick key to jump to next list item does
>> > not work.
>> > This happens both in IE10 and FF22.
>> > Using role="presentation" along with the aria-hidden does not have any
>> > effect.
>> >
>> > Even if the latter two list items are wrapped up in a div with
>> > aria-hidden set to true, NVDA still announces the list as having two
>> > items.
>> >
>> > Jaws recognizes both versions of the list as having just one item.
>> > Similarly if a table cell is marked with aria-hidden Jaws ignores it,
>> > but NVDA does not.
>> > This can lead to serious navigation issues in tables with these cells,
>> > since when inserted it forces an entire column and shifts all the
>> > information to the right, creating a mismatch between column header
>> > and the info they contain.
>> > Just imagine a row with two columns.
>> > First Name and Last Name.
>> > If a td is inserted with aria-hidden="true", then the values, Jaws
>> > announces the table as having two columns and two rows, and announces
>> > values correctly.
>> > NVDA announces table as having 3 columns and two rows and the table
>> > navigation gets very messy actually.
>> >
>> > So, basically, is it my misinterpretation that aria-hidden should hide
>> > its element as well as all info inside that element.
>> > Does aria hidden always have to be used on a container element such as
>> > a
>> > div?
>> > A quick check on the ARIA specs did not really show me anything either
>> > way, may be I was not interpreting something correctly.
>> > Cheers
>> > -Birkir
>> > >> > >> > >>
>> >> >> >>
>
>
>
> --
> Dave Merrill
> > >