WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-hidden for content outside modal dialog?

for

From: Jonathan Avila
Date: Oct 16, 2015 11:40AM

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