E-mail List Archives

Search E-mail List Archives for

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

From: Robert Fentress
Date: Fri, Oct 16 2015 6:39AM
Subject: aria-hidden for content outside modal dialog?
No previous message | Next message →

Hi, all.

I just wanted to make sure I was conceptualizing something properly. In a
modal dialog, one should apply aria-hidden to all content not in the dialog
itself, right? Applying aria-hidden only to focusable elements outside the
dialog would not be sufficient, since one could still read the full
contents of the page using the Virtual PC Cursor in JAWS or Browse mode in
NVDA, etc. Or is that not a big deal, or expected behavior? Any sense of
things here?

On a side note, if this is the case, then that means that usually dialogs
will not be able to be inserted in situ on the page at a point right after
their triggering control, since, I think, you cannot have an element with
aria-hidden="false" within an element with aria-hidden="true".

Thanks,
Rob

--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Patrick H. Lauke
Date: Fri, Oct 16 2015 6:49AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

On 16/10/2015 13:39, Robert Fentress wrote:
> Hi, all.
>
> I just wanted to make sure I was conceptualizing something properly. In a
> modal dialog, one should apply aria-hidden to all content not in the dialog
> itself, right? Applying aria-hidden only to focusable elements outside the
> dialog would not be sufficient, since one could still read the full
> contents of the page using the Virtual PC Cursor in JAWS or Browse mode in
> NVDA, etc.

Yes.

> Or is that not a big deal, or expected behavior? Any sense of
> things here?

Basically, you want to prevent a user from getting out of the modal. If
you don't hide everything else, they may still end up there by accident
and be confused/annoyed.

> On a side note, if this is the case, then that means that usually dialogs
> will not be able to be inserted in situ on the page at a point right after
> their triggering control, since, I think, you cannot have an element with
> aria-hidden="false" within an element with aria-hidden="true".

Sadly, correct.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Fri, Oct 16 2015 7:14AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Rob

Correct on all points.
aria-hidden="true" hides content from assistive technology, regardless
of navigation mode.
Screen readers in browse mode can explore non-focusable content unless
it is explicitly hidden this way, or using display: none.

Therefore it is best to use aria-hidden="true" on all page content
outside of a modal dialog.
And, yes, this is an easy task if the dialog container is tagged on at
the end of the DOM, but a bit of a nightmare when it is displayed
inline to the triggering element because you cannot override
aria-hidden="true" for a descendant element.
There have been discussions on whether it is sufficient to lock the
keyboard navigation within the dialog, and to clearly mark it as such
for assistive technologies (use the dialog role and an accessible name
provided through aria-label or aria-labelledby). It definitely
provides a less desirable experience for the a.t. user, (after all,
visually, you do not allow users to wonder into background content in
any way without interacting with the dialog).



You must be careful to always flip the aria-hidden value on page
content when user exits a modal dialog, else you might end up with a
situation where user does not see any content at all (if aria-hidden
is true for a closed dialog and also true for the page content).
You can view the modal, alert and tooltipdialog example widgets on
Deque University
http://dequeuniversity.com (under "examples and resources).
There you can also copy and paste the example code into a text editor,
save it, run it, and play with it.
Cheers


On 10/16/15, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> Hi, all.
>
> I just wanted to make sure I was conceptualizing something properly. In a
> modal dialog, one should apply aria-hidden to all content not in the dialog
> itself, right? Applying aria-hidden only to focusable elements outside the
> dialog would not be sufficient, since one could still read the full
> contents of the page using the Virtual PC Cursor in JAWS or Browse mode in
> NVDA, etc. Or is that not a big deal, or expected behavior? Any sense of
> things here?
>
> On a side note, if this is the case, then that means that usually dialogs
> will not be able to be inserted in situ on the page at a point right after
> their triggering control, since, I think, you cannot have an element with
> aria-hidden="false" within an element with aria-hidden="true".
>
> Thanks,
> Rob
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies
> Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > > >


--
Work hard. Have fun. Make history.

From: Robert Fentress
Date: Fri, Oct 16 2015 9:58AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Thanks, Patrick and Birkir.

On Fri, Oct 16, 2015 at 9:14 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Rob
>
> Correct on all points.
> aria-hidden="true" hides content from assistive technology, regardless
> of navigation mode.
> Screen readers in browse mode can explore non-focusable content unless
> it is explicitly hidden this way, or using display: none.
>
> Therefore it is best to use aria-hidden="true" on all page content
> outside of a modal dialog.
> And, yes, this is an easy task if the dialog container is tagged on at
> the end of the DOM, but a bit of a nightmare when it is displayed
> inline to the triggering element because you cannot override
> aria-hidden="true" for a descendant element.
> There have been discussions on whether it is sufficient to lock the
> keyboard navigation within the dialog, and to clearly mark it as such
> for assistive technologies (use the dialog role and an accessible name
> provided through aria-label or aria-labelledby). It definitely
> provides a less desirable experience for the a.t. user, (after all,
> visually, you do not allow users to wonder into background content in
> any way without interacting with the dialog).
>
>
>
> You must be careful to always flip the aria-hidden value on page
> content when user exits a modal dialog, else you might end up with a
> situation where user does not see any content at all (if aria-hidden
> is true for a closed dialog and also true for the page content).
> You can view the modal, alert and tooltipdialog example widgets on
> Deque University
> http://dequeuniversity.com (under "examples and resources).
> There you can also copy and paste the example code into a text editor,
> save it, run it, and play with it.
> Cheers
>
>
> On 10/16/15, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi, all.
> >
> > I just wanted to make sure I was conceptualizing something properly. In
> a
> > modal dialog, one should apply aria-hidden to all content not in the
> dialog
> > itself, right? Applying aria-hidden only to focusable elements outside
> the
> > dialog would not be sufficient, since one could still read the full
> > contents of the page using the Virtual PC Cursor in JAWS or Browse mode
> in
> > NVDA, etc. Or is that not a big deal, or expected behavior? Any sense
> of
> > things here?
> >
> > On a side note, if this is the case, then that means that usually dialogs
> > will not be able to be inserted in situ on the page at a point right
> after
> > their triggering control, since, I think, you cannot have an element with
> > aria-hidden="false" within an element with aria-hidden="true".
> >
> > Thanks,
> > Rob
> >
> > --
> > Robert Fentress
> > Senior Accessibility Solutions Designer
> > 540.231.1255
> >
> > Technology-enhanced Learning & Online Strategies
> > Assistive Technologies
> > 1180 Torgersen Hall
> > 620 Drillfield Drive (0434)
> > Blacksburg, Virginia 24061
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061

From: Jonathan Avila
Date: Fri, Oct 16 2015 11:40AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

> Therefore it is best to use aria-hidden="true" on all page content outside of a modal dialog.
> There have been discussions on whether it is sufficient to lock the keyboard navigation within the dialog, and to clearly mark it as such for assistive technologies (use the dialog role and an accessible name provided through aria-label or aria-labelledby).

As a side note -- according to the ARIA spec aria-hidden of true should be ignored by user agents and assistive technology when applied to focusable content. So even though aria-hidden should be applied to everything behind the modal, in theory it won't really be hiding the focusable content of the page from AT.

Jonathan

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

From: Tim Harshbarger
Date: Fri, Oct 16 2015 11:49AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

If you are using aria-hidden, there is a "gotcha" you might want to be mindful of.

Using either aria-hidden="true" or aria-hidden="false" overrides the default behavior of the screen reader. Normally, the screen reader will read whatever is visible and ignore content hidden with techniques like "display: none". SO, you should only ever use the aria-hidden attribute if you want to override the default behavior.

What this means with regard to the dialog is that if you use aria-hidden="true" to hide the background content, you will then want to remove the aria-hidden attribute completely when the dialog disappears. Otherwise you are likely to find the screen reader reading content that you don't intend it to read.

From: Robert Fentress
Date: Fri, Oct 16 2015 12:57PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Good to know; thanks Jonathan!

This serves as a reminder of why we definitely need to trap focus in that
dialog. Still, that is pretty annoying, because that only takes care of
navigating to the focusable elements by tabbing and there are other means
of reaching those focusable elements.

I think in VoiceOver, though, they must not follow the spec, because
according to a video I just saw, applying aria-hidden to a focusable
element does remove it from the web rotor, at least. Do you know if the
other screen readers follow the spec?

If not, is there any way to really hide these elements? I could see this
really resulting in some confusing behavior for a screen reader user.

Best,
Rob

On Fri, Oct 16, 2015 at 1:40 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> > Therefore it is best to use aria-hidden="true" on all page content
> outside of a modal dialog.
> > There have been discussions on whether it is sufficient to lock the
> keyboard navigation within the dialog, and to clearly mark it as such for
> assistive technologies (use the dialog role and an accessible name provided
> through aria-label or aria-labelledby).
>
> As a side note -- according to the ARIA spec aria-hidden of true should be
> ignored by user agents and assistive technology when applied to focusable
> content. So even though aria-hidden should be applied to everything behind
> the modal, in theory it won't really be hiding the focusable content of the
> page from AT.
>
> 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, Oct 16 2015 3:05PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Jonathan,
You wrote: As a side note -- according to the ARIA spec aria-hidden
of true should be ignored by user agents and assistive technology when
applied to focusable content.
Please can you point me to the specs where it says so?
I do not see this in
http://www.w3.org/TR/wai-aria-1.1/#aria-hidden

Thanks,
Sailesh Panchang


On 10/16/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> Therefore it is best to use aria-hidden="true" on all page content outside
>> of a modal dialog.
>> There have been discussions on whether it is sufficient to lock the
>> keyboard navigation within the dialog, and to clearly mark it as such for
>> assistive technologies (use the dialog role and an accessible name
>> provided through aria-label or aria-labelledby).
>
> As a side note -- according to the ARIA spec aria-hidden of true should be
> ignored by user agents and assistive technology when applied to focusable
> content. So even though aria-hidden should be applied to everything behind
> the modal, in theory it won't really be hiding the focusable content of the
> page from AT.
>
> 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: Fri, Oct 16 2015 4:00PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

On 16 October 2015 at 22:05, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:

> You wrote: As a side note -- according to the ARIA spec aria-hidden
> of true should be ignored by user agents and assistive technology when
> applied to focusable content.
> Please can you point me to the specs where it says so?
>

It is not the case that it should be ignored when applied to a focusable
element, but that the:

Element should not be exposed, unless it is focused or fires an
> accessibility event.


Core Accessibility API Mappings 1.1
http://www.w3.org/TR/core-aam-1.1/#details-id-94



--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: James Nurthen
Date: Fri, Oct 16 2015 4:11PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

So this doesn't say that focusable elements should ignore
aria-hidden="true" but that elements should ignore aria-hidden="true" when
focused.

So, I can put aria-hidden="true" on (for example) a link so long as I
ensure that the link never gets focus (and obviously there has to be
another way for an AT user to access the same functionality in an
equivalent manner)

Regards,
James

On Fri, Oct 16, 2015 at 3:00 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
wrote:

> On 16 October 2015 at 22:05, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > You wrote: As a side note -- according to the ARIA spec aria-hidden
> > of true should be ignored by user agents and assistive technology when
> > applied to focusable content.
> > Please can you point me to the specs where it says so?
> >
>
> It is not the case that it should be ignored when applied to a focusable
> element, but that the:
>
> Element should not be exposed, unless it is focused or fires an
> > accessibility event.
>
>
> Core Accessibility API Mappings 1.1
> http://www.w3.org/TR/core-aam-1.1/#details-id-94
>
>
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > >

From: Patrick H. Lauke
Date: Fri, Oct 16 2015 4:48PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

On 16/10/2015 23:00, Steve Faulkner wrote:

> It is not the case that it should be ignored when applied to a focusable
> element, but that the:
>
> Element should not be exposed, unless it is focused or fires an
>> accessibility event.

Perhaps nitpicking, but: would it make sense to tweak that to "unless it
is currently focused or it is in the process of firing an accessibility
event." ?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Fri, Oct 16 2015 6:20PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

> Element should not be exposed, unless it is focused or fires an
> accessibility event.

Steve, thanks for the clarification. This particular issue could still cause problems for users of assistive technology if strict focus management techniques are not used as my initial tests show inconsistent results with screen readers announcing the proper link text when aria-hidden is set to true on a link and you tab to it.

Best Regards,

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

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

From: Detlev Fischer
Date: Sat, Oct 17 2015 1:39AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Just for those wanting to experiment, here is another implementation of a dialog with background hidden using aria-hidden:
http://www.3needs.org/en/testing/code/role-dialog.html
While the focus cannot be trapped inside the dialog when traversing it with iOS / VoiceOver, aria-hidden ensures that the focus is set back to the triggering element once the dialog is closed.
The example is a couple of years old now and I haven't retested it with more recent browsers/AT.
Detlev

Am 17.10.2015 um 02:20 schrieb Jonathan Avila < = EMAIL ADDRESS REMOVED = >:

>> Element should not be exposed, unless it is focused or fires an
>> accessibility event.
>
> Steve, thanks for the clarification. This particular issue could still cause problems for users of assistive technology if strict focus management techniques are not used as my initial tests show inconsistent results with screen readers announcing the proper link text when aria-hidden is set to true on a link and you tab to it.
>
> Best Regards,
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>

From: Detlev Fischer
Date: Sat, Oct 17 2015 1:48AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Sorry, this is the link to the revised page that I meant to send:
http://www.3needs.org/en/testing/code/role-dialog-3.html

Sent from phone


Sent from phone

From: Paul J. Adam
Date: Mon, Oct 19 2015 8:19AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

In this demo, http://pauljadam.com/demos/dialog-DOM.html, the main element is aria-hidden and all links and buttons are removed from the focus order. It works with VoiceOver on iOS also.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Oct 17, 2015, at 2:48 AM, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
>
> Sorry, this is the link to the revised page that I meant to send:
> http://www.3needs.org/en/testing/code/role-dialog-3.html
>
> Sent from phone
>
>
> Sent from phone
> > > >

From: Sailesh Panchang
Date: Mon, Oct 19 2015 3:12PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Steve,
I still am not clear where the specs convey that "Element should not
be exposed, unless it is focused or fires an accessibility event".
Jonathan stated only one of the conditions, "aria-hidden should be
ignored when applied to a focusable element".

I am reading the "5.1.2 Including Elements in the Accessibility Tree
section on
Core Accessibility API Mappings 1.1.

It says, " If not already excluded from the accessibility tree per the
rules above in Excluding Elements in the Accessibility Tree, user
agents must provide an accessible object in the accessibility tree
for DOM elements that meet any of the following criteria:..."

The 6 distinct items listed includes text elements as well as
focusable elements and elements that may fire an accessibility event.
This is understandable including the note at the end of the list.
I see this section does not begin with "If already excluded from the
accessibility tree ..." but "If not already excluded".

Thanks and regards,
Sailesh Panchang


On 10/19/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> In this demo, http://pauljadam.com/demos/dialog-DOM.html, the main element
> is aria-hidden and all links and buttons are removed from the focus order.
> It works with VoiceOver on iOS also.
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>> On Oct 17, 2015, at 2:48 AM, Detlev Fischer < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> Sorry, this is the link to the revised page that I meant to send:
>> http://www.3needs.org/en/testing/code/role-dialog-3.html
>>
>> Sent from phone
>>
>>
>> Sent from phone
>> >> >> >> >
> > > > >

From: Steve Faulkner
Date: Mon, Oct 19 2015 3:19PM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Hi Salesh,

it is stated in mapping details for aria-hidden=true
http://www.w3.org/TR/core-aam-1.1/#details-id-94


--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 19 October 2015 at 22:12, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:

> Steve,
> I still am not clear where the specs convey that "Element should not
> be exposed, unless it is focused or fires an accessibility event".
> Jonathan stated only one of the conditions, "aria-hidden should be
> ignored when applied to a focusable element".
>
> I am reading the "5.1.2 Including Elements in the Accessibility Tree
> section on
> Core Accessibility API Mappings 1.1.
>
> It says, " If not already excluded from the accessibility tree per the
> rules above in Excluding Elements in the Accessibility Tree, user
> agents must provide an accessible object in the accessibility tree
> for DOM elements that meet any of the following criteria:..."
>
> The 6 distinct items listed includes text elements as well as
> focusable elements and elements that may fire an accessibility event.
> This is understandable including the note at the end of the list.
> I see this section does not begin with "If already excluded from the
> accessibility tree ..." but "If not already excluded".
>
> Thanks and regards,
> Sailesh Panchang
>
>
> On 10/19/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> > In this demo, http://pauljadam.com/demos/dialog-DOM.html, the main
> element
> > is aria-hidden and all links and buttons are removed from the focus
> order.
> > It works with VoiceOver on iOS also.
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com
> >
> >> On Oct 17, 2015, at 2:48 AM, Detlev Fischer <
> = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >> Sorry, this is the link to the revised page that I meant to send:
> >> http://www.3needs.org/en/testing/code/role-dialog-3.html
> >>
> >> Sent from phone
> >>
> >>
> >> Sent from phone
> >> > >> > >> > >> > >
> > > > > > > > > >
> > > > >

From: Sailesh Panchang
Date: Tue, Oct 20 2015 9:48AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | Next message →

Steve,
Sorry, This is still unclear to me.
You wrote: "Element should not be exposed, unless it is focused or
fires an accessibility event" is stated in mapping details for
aria-hidden=true
http://www.w3.org/TR/core-aam-1.1/#details-id-94
My comment:
The cells in that table row begins with "See Including Elements in
the Accessibility Tree". ...which I believe is the normative referred
to in my email above: 5.1.2.
Cell in the table row for aria-hidden=true do say, "Element should not
be exposed, unless it is focused or fires an accessibility event" ..
This seems to be the opposite of what is stated in the full text of
5.1.2 referred to by the table cells. I also do not see any rationale
for this particular rule stated for aria-hidden=true in the General
Mapping Rules in 5.5.1.

In practical terms, why should focusable elements within a container
(like div or main with aria-hidden=true) be exposed to screen reader
users if that is the intention of the aria-hidden rule above?
They will be available to non screen reader users and if the intent is
to make them available to SR users (SRs being the main AT with ARIA
support), developers will need to programmatically ensure explicitly
the focusable elements are out of the scope of aria-hidden=true.
And if aria-hidden=true is to be ignored on a link that will be a
problem. Consider a hack situation when this is suggested:
When it is not possible to merge an image link and a text link with
the same href placed next to each other, setting aria-hidden=true and
tabindex=-1 on the image link puts it out of reach of keyboard and SR
users.
Thanks and regards,
Sailesh Panchang

On 10/19/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Salesh,
>
> it is stated in mapping details for aria-hidden=true
> http://www.w3.org/TR/core-aam-1.1/#details-id-94
>
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 19 October 2015 at 22:12, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Steve,
>> I still am not clear where the specs convey that "Element should not
>> be exposed, unless it is focused or fires an accessibility event".
>> Jonathan stated only one of the conditions, "aria-hidden should be
>> ignored when applied to a focusable element".
>>
>> I am reading the "5.1.2 Including Elements in the Accessibility Tree
>> section on
>> Core Accessibility API Mappings 1.1.
>>
>> It says, " If not already excluded from the accessibility tree per the
>> rules above in Excluding Elements in the Accessibility Tree, user
>> agents must provide an accessible object in the accessibility tree
>> for DOM elements that meet any of the following criteria:..."
>>
>> The 6 distinct items listed includes text elements as well as
>> focusable elements and elements that may fire an accessibility event.
>> This is understandable including the note at the end of the list.
>> I see this section does not begin with "If already excluded from the
>> accessibility tree ..." but "If not already excluded".
>>
>> Thanks and regards,
>> Sailesh Panchang
>>
>>
>> On 10/19/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> > In this demo, http://pauljadam.com/demos/dialog-DOM.html, the main
>> element
>> > is aria-hidden and all links and buttons are removed from the focus
>> order.
>> > It works with VoiceOver on iOS also.
>> >
>> > Paul J. Adam
>> > Accessibility Evangelist
>> > www.deque.com
>> >
>> >> On Oct 17, 2015, at 2:48 AM, Detlev Fischer <
>> = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >> Sorry, this is the link to the revised page that I meant to send:
>> >> http://www.3needs.org/en/testing/code/role-dialog-3.html
>> >>
>> >> Sent from phone
>> >>
>> >>
>> >> Sent from phone
>> >> >> >> >> >> >> >> >> >
>> > >> > >> > >> > >> >
>> >> >> >> >>
> > > > >

From: Steve Faulkner
Date: Tue, Oct 20 2015 10:20AM
Subject: Re: aria-hidden for content outside modal dialog?
← Previous message | No next message

Hi Sailesh,

The reasoning is that aria-hidden=true does not have any effect upon the
browser bevaviour of the focusable element for non AT users and for AT
users in modes where keystrokes/interaction events are passed through to
the browser, so if a user does interact with the element it needs to expose
its role/states/properties. i.e. be included in the accessibility tree, so
the user knows what they are interacting with.

I agree that it is not very clear in the core accessibility API spec, so
suggest filing a bug:
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=ARIA&component=Platform%20API%20Mappings&version=1.1

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 20 October 2015 at 16:48, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:

> Steve,
> Sorry, This is still unclear to me.
> You wrote: "Element should not be exposed, unless it is focused or
> fires an accessibility event" is stated in mapping details for
> aria-hidden=true
> http://www.w3.org/TR/core-aam-1.1/#details-id-94
> My comment:
> The cells in that table row begins with "See Including Elements in
> the Accessibility Tree". ...which I believe is the normative referred
> to in my email above: 5.1.2.
> Cell in the table row for aria-hidden=true do say, "Element should not
> be exposed, unless it is focused or fires an accessibility event" ..
> This seems to be the opposite of what is stated in the full text of
> 5.1.2 referred to by the table cells. I also do not see any rationale
> for this particular rule stated for aria-hidden=true in the General
> Mapping Rules in 5.5.1.
>
> In practical terms, why should focusable elements within a container
> (like div or main with aria-hidden=true) be exposed to screen reader
> users if that is the intention of the aria-hidden rule above?
> They will be available to non screen reader users and if the intent is
> to make them available to SR users (SRs being the main AT with ARIA
> support), developers will need to programmatically ensure explicitly
> the focusable elements are out of the scope of aria-hidden=true.
> And if aria-hidden=true is to be ignored on a link that will be a
> problem. Consider a hack situation when this is suggested:
> When it is not possible to merge an image link and a text link with
> the same href placed next to each other, setting aria-hidden=true and
> tabindex=-1 on the image link puts it out of reach of keyboard and SR
> users.
> Thanks and regards,
> Sailesh Panchang
>
> On 10/19/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Salesh,
> >
> > it is stated in mapping details for aria-hidden=true
> > http://www.w3.org/TR/core-aam-1.1/#details-id-94
> >
> >
> > --
> >
> > Regards
> >
> > SteveF
> > Current Standards Work @W3C
> > <
> http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> >
> > On 19 October 2015 at 22:12, Sailesh Panchang <
> = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> Steve,
> >> I still am not clear where the specs convey that "Element should not
> >> be exposed, unless it is focused or fires an accessibility event".
> >> Jonathan stated only one of the conditions, "aria-hidden should be
> >> ignored when applied to a focusable element".
> >>
> >> I am reading the "5.1.2 Including Elements in the Accessibility Tree
> >> section on
> >> Core Accessibility API Mappings 1.1.
> >>
> >> It says, " If not already excluded from the accessibility tree per the
> >> rules above in Excluding Elements in the Accessibility Tree, user
> >> agents must provide an accessible object in the accessibility tree
> >> for DOM elements that meet any of the following criteria:..."
> >>
> >> The 6 distinct items listed includes text elements as well as
> >> focusable elements and elements that may fire an accessibility event.
> >> This is understandable including the note at the end of the list.
> >> I see this section does not begin with "If already excluded from the
> >> accessibility tree ..." but "If not already excluded".
> >>
> >> Thanks and regards,
> >> Sailesh Panchang
> >>
> >>
> >> On 10/19/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> >> > In this demo, http://pauljadam.com/demos/dialog-DOM.html, the main
> >> element
> >> > is aria-hidden and all links and buttons are removed from the focus
> >> order.
> >> > It works with VoiceOver on iOS also.
> >> >
> >> > Paul J. Adam
> >> > Accessibility Evangelist
> >> > www.deque.com
> >> >
> >> >> On Oct 17, 2015, at 2:48 AM, Detlev Fischer <
> >> = EMAIL ADDRESS REMOVED = >
> >> >> wrote:
> >> >>
> >> >> Sorry, this is the link to the revised page that I meant to send:
> >> >> http://www.3needs.org/en/testing/code/role-dialog-3.html
> >> >>
> >> >> Sent from phone
> >> >>
> >> >>
> >> >> Sent from phone
> >> >> > >> >> > >> >> > >> >> > >> >
> >> > > >> > > >> > > >> > > >> >
> >> > >> > >> > >> > >>
> > > > > > > > > >
> > > > >