E-mail List Archives
Re: Accessible Modal
From: Greg Kraus
Date: May 19, 2015 6:24AM
- Next message: Paul J. Adam: "Re: Accessible Modal"
- Previous message: Jonathan Avila: "Re: Accessible Modal"
- Next message in Thread: Paul J. Adam: "Re: Accessible Modal"
- Previous message in Thread: Jonathan Avila: "Re: Accessible Modal"
- View all messages in this Thread
When I implemented the example you mentioned, I did choose the structure of
<div id="mainPage" aria-hidden="true"></div>
<div id="modal" role="dialog"></div>
<div id="modalOverlay" aria-hidden="false"></div>
intentionally so it would be much easier to manage the aria-hidden on
large portions of the page. Making the overlay a child of the main
section made it much more difficult to manage what all had aria-hidden
applied to it and what didn't.
Just a note, there is a bug in that version I have not addressed yet
regarding keyboard accessibility. In that version if you move the
keyboard focus to something like the address bar of the browser while
the modal is open, once you start tabbing through the page the
keyboard focus will jump to the div behind the modal. It's an easy
fix, so I should be able to update it soon. I'll try to get it all
updated by GAAD and send out a note about it.
University IT Accessibility Coordinator
NC State University
On Tue, May 19, 2015 at 8:15 AM, Jonathan Avila
< <EMAIL REMOVED> > wrote:
>> So is applying `aria-hidden="true"` to all the non-modal elements a good thing? Any feedback would be greatly appreciated.
> It is, but unfortunately you have to apply it to many of the other page elements. For example, say you want to insert the modal dialog inline within the page and have aria-hidden true on the dialog but have the aria-hidden false on the body of another ancestor element within the page. Currently this would not work -- that is nesting an aria-hidden false within an aria-hidden true does not expose the content within the aria-hidden false with current screen readers and browsers. In correctly placed or updated aria-hidden attributes can be very problematic to detect without user testing.
> 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 Chris Pearce
> Sent: Tuesday, May 19, 2015 7:26 AM
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Accessible Modal
> I've used this implementation:
> http://accessibility.oit.ncsu.edu/training/aria/modal-window/version-3/ for implementing an accessible modal in the past and has worked well (tested in VoiceOver, NVDA, and JAWS).
> I was advised by a colleague that it isn't necessary to apply `aria-hidden="true"` to the `div` element that contains all the non-modal elements, which in the example would be the 'mainPage' div. The reason for this is because if focus is trapped within the modal you can't access anything outside of it. I was also advised by someone else that you should have it as you can access headings outside of the modal via shortcut keys and possibly other things so applying `aria-hidden="true"` to all the non-modal elements just makes it pretty bullet-proof. My take is that it seems to work really well so why change it?
> So is applying `aria-hidden="true"` to all the non-modal elements a good thing? Any feedback would be greatly appreciated.
> > > > > > >