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?


From: Birkir R. Gunnarsson
Date: Dec 27, 2012 8:37AM

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

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