WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Modal

for

From: Birkir R. Gunnarsson
Date: May 19, 2015 2:56PM


No, it wouldn't.
The problem with the screen readers is that they render the document
content into its off-screen model, where the user can interact with it
just like a Word document on steroids.
You can restrict keyboard / focus behavior but you have to be able to
remove the background content from the off-screen modal in the screen
reader.
When you use display: none or visibility: hidden this is not a problem.
But when you use modals (create an overlay on-screen) it is hard to
replicate that behavior for a screen reader.

The only way to do this is to put the modal content into a seperate
container, put aria-hidden="true" on the entire background content,
and expose the modal content until user dismisses it.
Sailesh, I see what you are saying .. I just wish that this were
possible because sometimes it would be so much easier to implement
screen reader modal behavior if you could override aria-hidden="true"
by a child element.
I would also like to lose 40 pounds and win a million dollars.
Life is what it is.


On 5/19/15, Greg Gamble < <EMAIL REMOVED> > wrote:
> As to tabbing out of a modals focus. What about capturing the last tab
> position on the modal then refocusing it back, on a blur event, to the
> first tab position?
> Would this technique work on restricting a screen reader to the modal?
>
> Greg
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Paul J. Adam
> Sent: Tuesday, May 19, 2015 5:57 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Accessible Modal
>
> Yes aria hidden is required on the main disabled content.
>
> Also one thing I recently added to a newer modal dialog demo was making the
> main content's buttons disabled and links non-focusable (tabindex=-1). The
> problem is that if you only apply aria-hidden=true to the main content you
> are only disabling readability by a screen reader. A keyboard or SR user can
> still TAB around the buttons and links unless you explicitly disable that
> with JS also.
>
> http://pauljadam.com/demos/dialog-DOM.html
> <http://pauljadam.com/demos/dialog-DOM.html>;
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
> Join us at our Mobile Accessibility "Bootcamp!"
> August 6-7 in Austin Texas
> https://dequeuniversity.com/events/2015/mobile
> Topics include responsive web design, native apps, & more
>
>> On May 19, 2015, at 6:26 AM, Chris Pearce < <EMAIL REMOVED> > wrote:
>>
>> Hi,
>>
>> 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.
>>
>> Cheers,
>> Chris
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.