WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Modal

for

From: Steve Faulkner
Date: May 19, 2015 3:40PM

related firefox implementation bug
https://bugzilla.mozilla.org/show_bug.cgi?id”5194
Bug 945194 - Add accessibles that have aria-hidden="false" to the tree even
if HTML5 hidden or CSS hidden or display: none


--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

On 19 May 2015 at 22:17, Sailesh Panchang < <EMAIL REMOVED> >
wrote:

> 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/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
> >>> > >>>
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >>
> > > > > archives at
> > http://webaim.org/discussion/archives
> > > > > > > > > > > >
> > > > >