WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-hidden for content outside modal dialog?

for

From: Steve Faulkner
Date: Oct 20, 2015 10:20AM

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