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:38AM

Thanks for the clarification Bryan. As you can tell, my accessibility
knowledge is limited. Among other things, the major project I work on
doesn't support ARIA other than landmark roles, which I had to fight to get
included, so I'm inexperienced with it.

And what you're actually saying makes much more sense than what I thought
you were saying :)

Dave


On Sat, Aug 10, 2013 at 8:46 PM, Bryan Garaventa <
<EMAIL REMOVED> > wrote:

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



--
Dave Merrill