WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-hidden for content outside modal dialog?

for

From: Robert Fentress
Date: Oct 16, 2015 12:57PM

Good to know; thanks Jonathan!

This serves as a reminder of why we definitely need to trap focus in that
dialog. Still, that is pretty annoying, because that only takes care of
navigating to the focusable elements by tabbing and there are other means
of reaching those focusable elements.

I think in VoiceOver, though, they must not follow the spec, because
according to a video I just saw, applying aria-hidden to a focusable
element does remove it from the web rotor, at least. Do you know if the
other screen readers follow the spec?

If not, is there any way to really hide these elements? I could see this
really resulting in some confusing behavior for a screen reader user.

Best,
Rob

On Fri, Oct 16, 2015 at 1:40 PM, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > Therefore it is best to use aria-hidden="true" on all page content
> outside of a modal dialog.
> > There have been discussions on whether it is sufficient to lock the
> keyboard navigation within the dialog, and to clearly mark it as such for
> assistive technologies (use the dialog role and an accessible name provided
> through aria-label or aria-labelledby).
>
> As a side note -- according to the ARIA spec aria-hidden of true should be
> ignored by user agents and assistive technology when applied to focusable
> content. So even though aria-hidden should be applied to everything behind
> the modal, in theory it won't really be hiding the focusable content of the
> page from AT.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Friday, October 16, 2015 9:15 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] aria-hidden for content outside modal dialog?
>
> Rob
>
> Correct on all points.
> aria-hidden="true" hides content from assistive technology, regardless of
> navigation mode.
> Screen readers in browse mode can explore non-focusable content unless it
> is explicitly hidden this way, or using display: none.
>
> Therefore it is best to use aria-hidden="true" on all page content outside
> of a modal dialog.
> And, yes, this is an easy task if the dialog container is tagged on at the
> end of the DOM, but a bit of a nightmare when it is displayed inline to the
> triggering element because you cannot override aria-hidden="true" for a
> descendant element.
> There have been discussions on whether it is sufficient to lock the
> keyboard navigation within the dialog, and to clearly mark it as such for
> assistive technologies (use the dialog role and an accessible name provided
> through aria-label or aria-labelledby). It definitely provides a less
> desirable experience for the a.t. user, (after all, visually, you do not
> allow users to wonder into background content in any way without
> interacting with the dialog).
>
>
>
> You must be careful to always flip the aria-hidden value on page content
> when user exits a modal dialog, else you might end up with a situation
> where user does not see any content at all (if aria-hidden is true for a
> closed dialog and also true for the page content).
> You can view the modal, alert and tooltipdialog example widgets on Deque
> University http://dequeuniversity.com (under "examples and resources).
> There you can also copy and paste the example code into a text editor,
> save it, run it, and play with it.
> Cheers
>
>
> On 10/16/15, Robert Fentress < <EMAIL REMOVED> > wrote:
> > Hi, all.
> >
> > I just wanted to make sure I was conceptualizing something properly.
> > In a modal dialog, one should apply aria-hidden to all content not in
> > the dialog itself, right? Applying aria-hidden only to focusable
> > elements outside the dialog would not be sufficient, since one could
> > still read the full contents of the page using the Virtual PC Cursor
> > in JAWS or Browse mode in NVDA, etc. Or is that not a big deal, or
> > expected behavior? Any sense of things here?
> >
> > On a side note, if this is the case, then that means that usually
> > dialogs will not be able to be inserted in situ on the page at a point
> > right after their triggering control, since, I think, you cannot have
> > an element with aria-hidden="false" within an element with
> aria-hidden="true".
> >
> > Thanks,
> > Rob
> >
> > --
> > Robert Fentress
> > Senior Accessibility Solutions Designer
> > 540.231.1255
> >
> > Technology-enhanced Learning & Online Strategies Assistive
> > Technologies
> > 1180 Torgersen Hall
> > 620 Drillfield Drive (0434)
> > Blacksburg, Virginia 24061
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at http://webaim.org/discussion/archives
> > > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061