WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Modal

for

From: Jonathan Avila
Date: May 19, 2015 1:54PM

> I am not sure I understand the behavior you are expecting:

We are expecting that a element's explicit aria hidden state would be honored over its ancestors -- in this case it doesn't appear to be.

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 Sailesh Panchang
Sent: Tuesday, May 19, 2015 3:48 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible Modal

Reference: "The fact that a.t. does not honor aria-hidden="false" on a child of element with aria-hidden="true" baffles me, and makes implementing modal dialogs for screen readers a much more complex enterprise than it should be".

I am not sure I understand the behavior you are expecting:
The aria-hidden=true on the parent is declaring "hide me from AT".
Now to place aria-hiddenúlse on a child element is the same as not placing the attribute at all. The aria-hidden=true on the parent will still be in effect.
Thanks,
Sailesh Panchang


On 5/19/15, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> You should always have a close button .. if you want touch-screen
> device users to interact with your content. They certainly do not have
> access to the escape key (or the any key for that metter :) ).
>
>
> On 5/19/15, Don Mauck < <EMAIL REMOVED> > wrote:
>> Well, all you really need is an easily defined close button.
>> -----Original Message-----
>> From: Jonathan Avila [mailto: <EMAIL REMOVED> ]
>> Sent: Tuesday, May 19, 2015 8:36 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Accessible Modal
>>
>>> Ok, I just wanted to be clear on what you were saying. I assume
>>> that you can either hit a close button or press escape, correct?
>>
>> Yes, although there can be challenges just relying on escape as it
>> may not be apparent to some users and it's behavior may depend on the
>> AT being used.
>>
>> 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 Don Mauck
>> Sent: Tuesday, May 19, 2015 10:34 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Accessible Modal
>>
>> Ok, I just wanted to be clear on what you were saying. I assume that
>> you can either hit a close button or press escape, correct?
>> -----Original Message-----
>> From: Jonathan Avila [mailto: <EMAIL REMOVED> ]
>> Sent: Tuesday, May 19, 2015 8:24 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Accessible Modal
>>
>>> Are these traps "keyboard" traps? If so, you need to do what you
>>> can to keep that from happening.
>>
>> Don, in this case the keyboard restriction is desirable. The user
>> would still need to be able to close the dialog with the keyboard and
>> return to normal keyboard navigation when the modal dialog is
>> dismissed -- hence there is not a trap. This is equivalent to the
>> same experience for a mouse user that is prohibited from accessing
>> content outside the modal dialog.
>>
>> 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 Don Mauck
>> Sent: Tuesday, May 19, 2015 10:01 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Accessible Modal
>>
>> Are these traps "keyboard" traps? If so, you need to do what you can
>> to keep that from happening.
>> -----Original Message-----
>> From: Chris Pearce [mailto: <EMAIL REMOVED> ]
>> Sent: Tuesday, May 19, 2015 5:26 AM
>> To: <EMAIL REMOVED>
>> Subject: [WebAIM] Accessible Modal
>>
>> 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
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >