WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Sailesh Panchang
Date: Aug 10, 2013 7:36PM

Dave,
If one uses <input type=hidden .../>, the form is not available to
anyone including AT users.
Bryan's reference is to use of aria-hidden on a form element or a link.
This only emphasizes the need to recognize when to use WAI-ARIA:
Use ARIA when something is not possible using native HTML simply
because the feature is not there / is not supported by browsers and
AT.
It should not be used as a hack or a quick fix for an accessibility
problem by the developer.
Accessibility issues that are the result of deficient design / coding
should be fixed by fixing the design / code.
One should not regard ARIA as a way to circumvent such changes.

A column with empty cells really has no place in a data table. It is
an example of poor design.
If developers are using it for housekeeping / other chores, it is
quite wrong: they are introducing structural markup in a page without
realizing how different users / technologies are interpreting that
content even though it may make no difference visually.
If number of columns / rows depend on data to be displayed, they
should introduce rows / columns as needed programmatically and not use
a fixed table design.
It is alright for some cells in a row / column to be empty: it
correctly represents semantics and data relationships.

Some may argue that some AT do not render empty columns. Even a column
whose cells contain images with null alt or no alt go unreported.
That's a problem too.
Should the AT take on the role of guessing what the content author
intends? It does that sometimes after all AT is meant to mitigate
problems in the environment for the end user.
But developers should not burden the AT by poor design / coding practices.
Regards,
Sailesh Panchang
Deque Systems

On 8/10/13, Dave Merrill < <EMAIL REMOVED> > wrote:
> @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
> > > >