RE: Question in the use of aria-hidden attribute

Using the dialog role on the dialog container, restricting the tab ring, and
.. Very importantly . setting focus inside the dialog when it opens. Do
those things and aria-hidden should not be considered a requirement for
compliance.

 

Of course, there is a bit more to an accessible dialog, but those are the
aspects relevant to this discussion.

 

When it works, aria-modal is another step in the right direction. However,
it really shouldn't be necessary for compliance either.

 

Matt King

 

From: Jonathan Avila <jon.avila@levelaccess.com> 
Sent: Wednesday, December 5, 2018 5:48 AM
To: Matt King <a11ythinker@gmail.com>; Bryan Garaventa
<bryan.garaventa@levelaccess.com>; 'Sean Murphy (seanmmur)'
<seanmmur@cisco.com>; w3c-wai-ig@w3.org
Subject: RE: Question in the use of aria-hidden attribute 

 

*	I agree with removing the attribute. Even better, avoid using it at
all unless there is literally no other way to achieve a good result.

 

So could we then say that not using aria-hidden true for background page
content in general when a modal dialog is open would be WCAG conformant?  I
have always been hesitant to require aria-hidden with modals because of the
points raised in this discussion.  I understand that if the DOM was arranged
correctly with the dialog as a sibling to the rest of the page content then
aria-hidden could be used safely.  I also understand that some screen
readers will hide the rest of the content from the user when aria-modal true
is used - although the support for this is limited and problematic on iOS
with VoiceOver.

 

But based on the discussion it would be helpful to get consensus that if a
modal dialog was created otherwise correctly and tab focus was restricted, a
missing aria-hidden true on the rest of the page would not trigger a WCAG
failure.

 

Jonathan

 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Wednesday, December 05, 2018 2:12 AM
To: Bryan Garaventa; 'Sean Murphy (seanmmur)'; w3c-wai-ig@w3.org
<mailto:w3c-wai-ig@w3.org> 
Subject: RE: Question in the use of aria-hidden attribute 

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

I agree with removing the attribute. Even better, avoid using it at all
unless there is literally no other way to achieve a good result.

 

Aria-hidden="true" is extremely dangerous. If you think you need to use it,
which you probably do not, test, test, and over test. Then, put in some kind
of redundant test plan.

 

Right now, there are several sites, including dropbox and 1password,  where
opening a modal completely breaks the site because they thought using
aria-hidden was a good idea. The risk of using aria-hidden to hide content
under a modal is not offset by the benefits most people assume. If the
dialog is a DOM descendant of the content at a lower z, then everything
breaks for screen reader users. You can do nothing; you are dead in the
water.

 

Matt King

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com
<mailto:bryan.garaventa@levelaccess.com> > 
Sent: Monday, December 3, 2018 9:17 AM
To: Sean Murphy (seanmmur) <seanmmur@cisco.com <mailto:seanmmur@cisco.com>
>; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: RE: Question in the use of aria-hidden attribute 

 

Historically aria-hidden="false", when set explicitly, was supposed to
expose a hidden container such as one that used the hidden attribute or CSS
display:none so that it would be exposed to screen reader users regardless.

 

This was like a total inversion of the visual state, where it would be
hidden visually but exposed to screen reader users like offscreen text.

 

In practice however this was never supported by Firefox, and was exposed by
JAWS in IE11, and as a result has never worked reliably and has caused major
problems when the exposed container included active elements like links and
buttons, that, even when exposed, are completely inaccessible in this state.
This has led to critical accessibility issues occurring in enterprise
applications as a result of these discrepancies.

 

Developers should always avoid setting aria-hidden="false" on anything just
to be safe. Removing the attribute altogether is best in most cases.

 

 

 

Bryan Garaventa

Principle Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com <mailto:Bryan.Garaventa@LevelAccess.com> 

415.624.2709 (o)

www.LevelAccess.com <http://www.LevelAccess.com> 

 

From: Sean Murphy (seanmmur) <seanmmur@cisco.com <mailto:seanmmur@cisco.com>
> 
Sent: Sunday, December 02, 2018 9:09 PM
To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: Question in the use of aria-hidden attribute 

 

All,

 

I have seen discussions on  the use of aria-hidden attribute. I am still not
100% sure on the correct usage after reading the relevant documentation.

 

Aria-hidden="true" - from the current block attribute (tag) and children are
removed from the accessibility tree. visually, is the information still
present if no CSS attributes used?

Aria-hidden="off" - does nothing to the accessibility tree.

Now for aria-hidden="false". Extracted code below (assume CSS attributes are
not hiding the content).

 

    <div id="main" role="document" aria-hidden="false">

</div>

 

What would occur with the children tags within the above div? would they
still be visible to the accessibility tree?

 

Sean