WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Modal

for

From: Sailesh Panchang
Date: May 19, 2015 2:46PM

Jonathan,
What is the rationale for expecting the child element to be exposed to
AT when the aria-hidden on the parent is true? Why should the
ancestor's aria-hidden value be disregarded?
Sailesh

Sailesh



On 5/19/15, Jonathan Avila < <EMAIL REMOVED> > wrote:
>> 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
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >