WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-hidden for content outside modal dialog?

for

From: Sailesh Panchang
Date: Oct 20, 2015 9:48AM

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