WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?

for

From: Gunderson, Jon R
Date: Dec 27, 2012 10:11AM

Here are the links to relevant ARIA specifications in terms of how authors
should use aria-hidden:

W3C ARIA 1.0 Candidate Recommendation:
http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden

This section of a Working Draft version of the ARIA authoring guide talks
about hidden content in general:
http://www.w3.org/WAI/PF/aria-practices/#accessiblewidget

It would be good to send your comments related to aria-hidden to the WAI
Protocols and Formats working group for consideration of clarification on
the uses of aria-hidden in these documents.

http://www.w3.org/WAI/PF/comments/

Jon


On 12/27/12 10:46 AM, "Steve Faulkner" < <EMAIL REMOVED> > wrote:

>Responding briefly as I am doing so via mobile.
>
>Unclear where the confusion about how aria-hidden comes from.
>
>My understanding is:
>
>Aria-hidden does not and is not defined to affect the visual display of
>content.
>
>What is designed to do and what it does in browsers that implement it is
>to remove content in the subtree of an element (with aria-hidden) from
>the accessible tree representation of the HTML DOM. It does not remove
>anything from the DOM itself or change the display properties of content
>in the DOM.
>
>The result is that any Assistive technology that uses the accessible tree
>to convey a representation of what is in the DOM will not report content
>flagged with aria-hidden as its not in the accessible tree.
>
>Regards
>
>SteveF
>
>On 27 Dec 2012, at 15:37, "Birkir R. Gunnarsson"
>< <EMAIL REMOVED> > wrote:
>
>> I agree. There are reasons for hiding content from screen readers that
>> still appears visually (basically the equivalent of an empty alt tag
>> on an image). I hope that aria-hidden will be defined that way for
>> future updates or documentation, after all, doesn't HTML5 have a
>> hidden property that will work exactly like aria-hidden, except it
>> works for all users, not just screen readers or assistive technology?
>> I can see the programming advantage of using a simple property like
>> hidden over CSS classes, that's definite. But it does not meet the
>> needs discussed here of hiding content from users when it not only
>> does not add to the information presented by the page, but actually
>> disrupts the users so that they are unable to view the content of the
>> page.
>> Cheers
>> -B
>>
>> On 12/27/12, Jason Megginson < <EMAIL REMOVED> > wrote:
>>> It is unfortunate that there is no clear consensus or documentation on
>>> this property because in my opinion it is a powerful property that
>>>should
>>> be used to hide information from screen readers while retaining
>>> information visually. There is no need for aria-hidden to hide content
>>> that is visually hidden from sighted users; leave that to CSS
>>>visibility
>>> and/or display properites.
>>>
>>> I too will add another use case in favor of implementing aria-hidden to
>>> "hide" content from screen readers even though the content is active in
>>> the DOM:
>>>
>>> Aria-hidden is useful for providing gracefully degrading solutions to
>>> ensure content can work with and without ARIA supported user agents.
>>>
>>> Consider the following simplified example:
>>> <a href="#someURL" aria-haspopup="true" onblur="hidePopUp()"
>>> onfocus="showPopUp()">Information
>>> <span style="position:absolute; left:-400px" aria-hidden="true">
>>> Contains Pop-up </span>
>>> </div>
>>>
>>> The concept is that when ARIA and aria-hidden is supported, it will
>>>ignore
>>> the off-screen positioned text to avoid double speaking by screen
>>>readers.
>>> However, if user (a combination of) agents do not support ARIA, it will
>>> read the off-screen text.
>>>
>>> Finally, HTML5 has a global attribute hidden="hidden" which is not
>>> supported by IE (at this time) and it hides content from everyone. So
>>> arIa-hidden should be used (and in my opinion formally proposed) to
>>>hide
>>> on-screen content from screen readers. Aria-hidden is the closest thing
>>> web developers have to the .silent and .forceSimple (accessibility)
>>> properties of Flash and Flex and as Bryan noted earlier, it can
>>> tremendously add enhanced usability when modal dialog windows are used.
>>>
>>> Jason Megginson
>>> SSB BART Group
>>> 703-637-8964 (o)
>>> 703-244-7755 (c)
>>>
>>> -----Original Message-----
>>> From: <EMAIL REMOVED>
>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Maraikayar
>>>Prem
>>> Nawaz
>>> Sent: Wednesday, December 26, 2012 11:06 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Is aria-hidden supposed to only hide content for
>>> screen readers/assistive technology, or is it supposed to hide content
>>> altogether?
>>>
>>> Hi,
>>> Another use case:
>>> aria-hidden is also useful when we want to animate the show/hide by
>>> reducing the height property to produce a slow fading effect. The
>>>content
>>> inside the div is hidden to visual users but available to screen
>>> reader
>>> users. Aria-hidden, helps in hiding it from screen readers too.
>>>
>>> Regards
>>> -Nawaz
>>>
>>>
>>> On Fri, Dec 21, 2012 at 11:40 AM, Bryan Garaventa <
>>> <EMAIL REMOVED> > wrote:
>>>
>>>> There is benefit though, in keeping them separate, where content is
>>>> hidden from screen reader users, but not visually.
>>>>
>>>> I use this on my bootstrap Modal module, where the background content
>>>> is hidden from screen reader users via aria-hidden, so even though the
>>>> modal content is standard HTML, where all of the background content is
>>>> still visible, but shaded out, for sighted users, the only content
>>>> that screen reader users see is the modal content, and not the
>>>> background. This works equally well in JAWS, NVDA, and Voiceover, in
>>>>IE,
>>> FF, Chrome, and Safari.
>>>>
>>>> Also, I've used aria-hidden on toggle controls where special Unicode
>>>> characters are used to indicate selection, to prevent the screen
>>>> reader from announcing things like "black upward pointing triangle",
>>>> when this feedback provides no value.
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Jared Smith" < <EMAIL REMOVED> >
>>>> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>>>> Sent: Thursday, December 20, 2012 7:25 PM
>>>> Subject: Re: [WebAIM] Is aria-hidden supposed to only hide content for
>>>> screen readers/assistive technology, or is it supposed to hide content
>>>> altogether?
>>>>
>>>>
>>>>> Think of aria-hidden as simply *indicating* that content is hidden
>>>>> from all users. Aria-hidden should not be used for displaying
>>>>> content visually, but hiding it from screen reader users. However,
>>>>> in practice, it can function this way, though this wouldn't be a
>>>>> correct usage of it.
>>>>>
>>>>> ARIA does not affect standard browser functionality or presentation.
>>>>> In other words, ARIA *couldn't* hide content visually. You'd use CSS
>>>>> display:none to do that. But a powerful benefit of ARIA is that you
>>>>> can use the semantics of ARIA and the power of CSS to get the best
>>>>> of both worlds.
>>>>>
>>>>> For example, you could (and probably always would) have
>>>>> [aria-hidden=true] display:none; in your CSS. In your application,
>>>>> you would simply set the aria-hidden attribute value to true or
>>>>> false. When set to true, the CSS applies which also visually hides
>>>>> the content visually. In practice, aria-hidden and CSS display:none
>>>>> have the same affect on screen readers, the difference is that
>>>>> aria-hidden has semantic meaning and is much easier to toggle in
>>>>> scripting than changing styles, toggling class names, etc.
>>>>>
>>>>> Jared
>>>>> >>>>> >>>>> list messages to <EMAIL REMOVED>
>>>>
>>>> >>>> >>>> list messages to <EMAIL REMOVED>
>>>>
>>> >>> >>> messages to <EMAIL REMOVED>
>>> >>> >>> >>>
>> >> >> >>>