WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Dave Merrill
Date: Aug 11, 2013 5:41AM

Thanks for your reply Sailesh. As I said to Bryan, ARIA isn't my area of
expertise. Since it's not currently part of the major project I work on,
have no fear that we'll be abusing it.

Dave Merrill


On Sat, Aug 10, 2013 at 9:36 PM, Sailesh Panchang <
<EMAIL REMOVED> > wrote:

> 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
> > > > > > > >
> > > >



--
Dave Merrill