WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Modal

for

From: Jonathan Avila
Date: May 20, 2015 7:05AM

> Not sure why that should apply in this case. What's the basis for expecting the CSS paradigm to be applied to WAI-ARIA?
Anything in the ARIA specs to this effect?

We're just trying to find a quick way to hide other content except for the modal dialog. Based on how some pages are designed it could require adding tens or hundreds of aria-hidden=true on all sorts of other elements -- this is just not practical.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
<EMAIL REMOVED>

703-637-8957 (o)
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 5:17 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible Modal

Not sure why that should apply in this case. What's the basis for expecting the CSS paradigm to be applied to WAI-ARIA?
Anything in the ARIA specs to this effect?
Moreover, the ARIA specs for aria-hidden specifically indicates that aria-false is as good as not setting the attribute at all.
Sailesh


On 5/19/15, Jonathan Avila < <EMAIL REMOVED> > wrote:
>> 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?
>
> Because this is how CSS visibility:hidden and visibility:visible work.
>
>
> If this method worked for aria-hidden it would make hiding background
> content when modals appear much more straight forward.
>
> 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 4:47 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Accessible Modal
>
> 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/versio
>>>> n
>>>> -
>>>> 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
>>> >>>
>> >> >> 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
> >