E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 30 (In chronological order)

From: Chris Pearce
Date: Tue, May 19 2015 5:26AM
Subject: Accessible Modal
No previous message | Next message →

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

From: Karl Groves
Date: Tue, May 19 2015 5:52AM
Subject: Re: Accessible Modal
← Previous message | Next message →

"So is applying `aria-hidden="true"` to all the non-modal elements a good
thing?"

Yes. Otherwise the controls in the "parent" will be reachable by
screen reader users. For instance, without aria-hidden="true" a JAWS
user could pull up a list of form fields, buttons, links, etc. that
include those outside the modal.

On Tue, May 19, 2015 at 7:26 AM, Chris Pearce < = EMAIL ADDRESS 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
> > > > --

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Birkir R. Gunnarsson
Date: Tue, May 19 2015 6:04AM
Subject: Re: Accessible Modal
← Previous message | Next message →

Absolutely. A screen reader user can also navigate to the "hidden"
content simply using the arrow keys, or the touch-screen in Voiceover.
It is near impossible to make a modal window experience for a screen
reader user unless you use aria-hidden as described.
For keyboard only user, yes, you can trap the keyboard focus within the modal.
For the mouse user you can either ignore any clicks outside the modal,
or cause the modal to close when user clicks outside it.
But you got to trick the good ol screen reader.



On 5/19/15, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
> "So is applying `aria-hidden="true"` to all the non-modal elements a good
> thing?"
>
> Yes. Otherwise the controls in the "parent" will be reachable by
> screen reader users. For instance, without aria-hidden="true" a JAWS
> user could pull up a list of form fields, buttons, links, etc. that
> include those outside the modal.
>
> On Tue, May 19, 2015 at 7:26 AM, Chris Pearce < = EMAIL ADDRESS 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
>> >> >> >> >
>
>
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
>
> Modern Web Toolsets and Accessibility
> https://www.youtube.com/watch?v=_uq6Db47-Ks
>
> www.tenon.io
> > > > >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Tue, May 19 2015 6:15AM
Subject: Re: Accessible Modal
← Previous message | Next message →

> So is applying `aria-hidden="true"` to all the non-modal elements a good thing? Any feedback would be greatly appreciated.

It is, but unfortunately you have to apply it to many of the other page elements. For example, say you want to insert the modal dialog inline within the page and have aria-hidden true on the dialog but have the aria-hidden false on the body of another ancestor element within the page. Currently this would not work -- that is nesting an aria-hidden false within an aria-hidden true does not expose the content within the aria-hidden false with current screen readers and browsers. In correctly placed or updated aria-hidden attributes can be very problematic to detect without user testing.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Greg Kraus
Date: Tue, May 19 2015 6:24AM
Subject: Re: Accessible Modal
← Previous message | Next message →

When I implemented the example you mentioned, I did choose the structure of

<div id="mainPage" aria-hidden="true"></div>
<div id="modal" role="dialog"></div>
<div id="modalOverlay" aria-hidden="false"></div>

intentionally so it would be much easier to manage the aria-hidden on
large portions of the page. Making the overlay a child of the main
section made it much more difficult to manage what all had aria-hidden
applied to it and what didn't.

Just a note, there is a bug in that version I have not addressed yet
regarding keyboard accessibility. In that version if you move the
keyboard focus to something like the address bar of the browser while
the modal is open, once you start tabbing through the page the
keyboard focus will jump to the div behind the modal. It's an easy
fix, so I should be able to update it soon. I'll try to get it all
updated by GAAD and send out a note about it.

Greg
--
Greg Kraus
University IT Accessibility Coordinator
NC State University
919.513.4087
= EMAIL ADDRESS REMOVED =
http://go.ncsu.edu/itaccess


On Tue, May 19, 2015 at 8:15 AM, Jonathan Avila
< = EMAIL ADDRESS REMOVED = > wrote:
>> So is applying `aria-hidden="true"` to all the non-modal elements a good thing? Any feedback would be greatly appreciated.
>
> It is, but unfortunately you have to apply it to many of the other page elements. For example, say you want to insert the modal dialog inline within the page and have aria-hidden true on the dialog but have the aria-hidden false on the body of another ancestor element within the page. Currently this would not work -- that is nesting an aria-hidden false within an aria-hidden true does not expose the content within the aria-hidden false with current screen readers and browsers. In correctly placed or updated aria-hidden attributes can be very problematic to detect without user testing.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Paul J. Adam
Date: Tue, May 19 2015 6:56AM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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
> > > >

From: Don Mauck
Date: Tue, May 19 2015 8:00AM
Subject: Re: Accessible Modal
← Previous message | Next message →

Are these traps "keyboard" traps? If so, you need to do what you can to keep that from happening.

From: Birkir R. Gunnarsson
Date: Tue, May 19 2015 8:07AM
Subject: Re: Accessible Modal
← Previous message | Next message →

Yes.
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.



On 5/19/15, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:
> Are these traps "keyboard" traps? If so, you need to do what you can to
> keep that from happening.
>

From: Moore,Michael (DARS)
Date: Tue, May 19 2015 8:18AM
Subject: Re: Accessible Modal
← Previous message | Next message →

Is the problem with failing to recognize the correct state of aria-hidden in the browser (failing to pass the info to the accessibility api), the screen reader (failing to report the state from the api) or in the specification (parent state controls)? It would help to know where to direct the bug report. Unless of course this behavior is desired for some reason.

Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)

From: Jonathan Avila
Date: Tue, May 19 2015 8:23AM
Subject: Re: Accessible Modal
← Previous message | Next message →

> 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 ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Don Mauck
Date: Tue, May 19 2015 8:34AM
Subject: Re: Accessible Modal
← Previous message | Next message →

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?

From: Jonathan Avila
Date: Tue, May 19 2015 8:36AM
Subject: Re: Accessible Modal
← Previous message | Next message →

> 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 ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Don Mauck
Date: Tue, May 19 2015 8:45AM
Subject: Re: Accessible Modal
← Previous message | Next message →

Well, all you really need is an easily defined close button.

From: Birkir R. Gunnarsson
Date: Tue, May 19 2015 12:29PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS REMOVED = > wrote:
> Well, all you really need is an easily defined close button.
>

From: Sailesh Panchang
Date: Tue, May 19 2015 1:47PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = > wrote:
>> Well, all you really need is an easily defined close button.
>>

From: Jonathan Avila
Date: Tue, May 19 2015 1:54PM
Subject: Re: Accessible Modal
← Previous message | Next message →

> 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 ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Sailesh Panchang
Date: Tue, May 19 2015 2:46PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Greg Gamble
Date: Tue, May 19 2015 2:51PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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

From: Jonathan Avila
Date: Tue, May 19 2015 2:55PM
Subject: Re: Accessible Modal
← Previous message | Next message →

> 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 ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Birkir R. Gunnarsson
Date: Tue, May 19 2015 2:56PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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
>
>
>

From: Sean Curtis
Date: Tue, May 19 2015 3:05PM
Subject: Re: Accessible Modal
← Previous message | Next message →

But not how display: none works, which is a much closer fit for how aria-hidden works.

Cheers,

Sean

On 20 May 2015, at 6:55 am, Jonathan Avila < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Sailesh Panchang
Date: Tue, May 19 2015 3:17PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Steve Faulkner
Date: Tue, May 19 2015 3:40PM
Subject: Re: Accessible Modal
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> > Phone 703.637.8957
> > Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> >
> >
> >

From: _mallory
Date: Wed, May 20 2015 1:27AM
Subject: Re: Accessible Modaly
← Previous message | Next message →

On Tue, May 19, 2015 at 08:51:19PM +0000, Greg Gamble 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?

Only if they were tabbing and focusing. The point is, SR users aren't
limited to that.

_mallory

From: Jonathan Avila
Date: Wed, May 20 2015 7:05AM
Subject: Re: Accessible Modal
← Previous message | Next message →

> 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 ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Steve Faulkner
Date: Wed, May 20 2015 7:16AM
Subject: Re: Accessible Modal
← Previous message | Next message →

On 20 May 2015 at 14:05, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:

> this is just not practical.


Unfortunately unless we can get implementers to agree to implement this
behaviour, then that's what we have to work with.
As a side note: the native HTML mechanism for blocking interaction with
content outside of a modal <dialog> does not provide subtree state to be
changed from inert.
http://www.w3.org/TR/html51/editing.html#inert-subtrees

--

Regards

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

From: Sailesh Panchang
Date: Thu, May 21 2015 12:37PM
Subject: Re: Accessible Modal
← Previous message | Next message →

Jonathan,
From the link for bug #945194 sent by Steve F, I see others also agree
that the parent's aria-hidden=true will apply to a child with
aria-hiddenúlse. I reproduce some text and code below:
<start>
<div aria-hidden="true"><div aria-hidden="false">the text is not
visible for AT</div></div>
That is correct. A descendant node set to aria-hidden="false" will not
override a ancestor node's visibility. This shoulld be clarified in
ARIA 1.1.
but the same time HTML5 spec now requires
<div hidden><div aria-hidden="false">HTML5 spec thinks this text
should be visible for AT</div></div>
That's an error in the spec then. Could probably be solved with some
explanatory text.

</end>

But aria-hiddenúlse on the same element will expose content to AT:
<div hidden (or display:none) aria-hiddenúlse">This content is
exposed to AT</div>

Thanks,

Sailesh


On 5/20/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> On 20 May 2015 at 14:05, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
>> this is just not practical.
>
>
> Unfortunately unless we can get implementers to agree to implement this
> behaviour, then that's what we have to work with.
> As a side note: the native HTML mechanism for blocking interaction with
> content outside of a modal <dialog> does not provide subtree state to be
> changed from inert.
> http://www.w3.org/TR/html51/editing.html#inert-subtrees
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > > > >

From: Jonathan Avila
Date: Thu, May 21 2015 12:46PM
Subject: Re: Accessible Modal
← Previous message | Next message →

> But aria-hiddenúlse on the same element will expose content to AT:
<div hidden (or display:none) aria-hiddenúlse">This content is exposed to AT</div>

This seems incorrect to me. From my read of the HTML spec user agents are only supposed to expose hidden content to an accessibility API if it is referenced by an id such as in the case of aria-labelledby and aria-describedby.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Chris Pearce
Date: Thu, May 21 2015 3:08PM
Subject: Re: Accessible Modal
← Previous message | Next message →

Thanks everyone for your input, it has been really valuable and good to
know that the solution I've been using is the solution I should be using.

Chris

On 22 May 2015 at 04:46, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:

> > But aria-hiddenúlse on the same element will expose content to AT:
> <div hidden (or display:none) aria-hiddenúlse">This content is exposed
> to AT</div>
>
> This seems incorrect to me. From my read of the HTML spec user agents are
> only supposed to expose hidden content to an accessibility API if it is
> referenced by an id such as in the case of aria-labelledby and
> aria-describedby.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Sailesh Panchang
Date: Fri, May 22 2015 6:15AM
Subject: Re: Accessible Modal
← Previous message | No next message

Jonathan,
Yes, an image can refer to hidden text like
<div id="help" hidden>Some helpful text for an SR</div>
I was not referring to that.
I believe the above referred bug when resolved is meant to allow
aria-hiddenúlse override HTML5 hidden or CSS display:none on the
same element.
<div hidden aria-hiddenúlse">Help text for SR</div> can contain
helpful text for an SR user.

The HTML5 hidden attribute is "typically implemented via CSS" and can
be overridden by CSS display property like:
<div hidden style="display: block">But This is exposed to AT</div>
Sure it does not make great sense for an author to do so.
But today this does not work if aria-hiddenúlse is used in place of
CSS display property.
Chris ...alright, this is my last message.
Thanks,
Sailesh


On 5/21/15, Chris Pearce < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks everyone for your input, it has been really valuable and good to
> know that the solution I've been using is the solution I should be using.
>
> Chris
>
> On 22 May 2015 at 04:46, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
>> > But aria-hiddenúlse on the same element will expose content to AT:
>> <div hidden (or display:none) aria-hiddenúlse">This content is exposed
>> to AT</div>
>>
>> This seems incorrect to me. From my read of the HTML spec user agents are
>> only supposed to expose hidden content to an accessibility API if it is
>> referenced by an id such as in the case of aria-labelledby and
>> aria-describedby.
>>
>> Jonathan
>>
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> = EMAIL ADDRESS REMOVED =
>> Phone 703.637.8957
>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>>