E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Birkir R. Gunnarsson
Date: Thu, Dec 20 2012 7:45PM
Subject: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
No previous message | Next message →

Hi everyone

I was testing out aria-hidden as a solution to a problem brought up in
my previous thread.
I found a great set of examples from Steve falkner on his/the Paciello site
http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/

Judging by that text, it seems that the purpose of aria-hidden is to
hide all content from all users (similar to display:none), except that
only some A.T. apps have implementedit, no one else has botherred.
If I understand this text correctly, there is no proposed solution
that will only hide content from assistive technology, whilst keeping
it present vissibly/on the page.
I am just wondering if this is correct, since I would think there are
use cases where hiding content from, say, screen readers, whilst
keeping it accessible and vissible to other users, is a reasonable
solution (dyslexic users might benefit from some animation on a page
for instance, whilst that animation disrupts screen readers reading
the page).
I am merely curious about this, of course I will go and Google the
actual definition of these things from the W3C, but I was just curious
if someone who has implemented and used aria-hidden has an opinion on
this, and, if I am right, isn't it a problem that there is no
widespread acceptable and relatively simple technique to hide content
from some assistive technologies, whilst keeping it accessible to
others, after all we use the opposite quite a bit by hiding text
off-screen with CSS?
Cheers
-B

From: Jared Smith
Date: Thu, Dec 20 2012 8:25PM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Thu, Dec 20 2012 11:10PM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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
> > >

From: Maraikayar Prem Nawaz
Date: Wed, Dec 26 2012 9:05PM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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
> > > > > > >
> > > >

From: Jason Megginson
Date: Thu, Dec 27 2012 8:00AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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)

From: Birkir R. Gunnarsson
Date: Thu, Dec 27 2012 8:37AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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

From: Steve Faulkner
Date: Thu, Dec 27 2012 9:46AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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

From: Gunderson, Jon R
Date: Thu, Dec 27 2012 10:11AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

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

From: Jared Smith
Date: Thu, Dec 27 2012 10:25AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | Next message →

On Thu, Dec 27, 2012 at 9:46 AM, Steve Faulkner wrote:

> Unclear where the confusion about how aria-hidden comes from.

The confusion lies in a disconnect between how the ARIA spec defines
aria-hidden and the many actual and beneficial uses of it that have
been described in this thread.

The spec defines aria-hidden as, "Indicates that the element and all
of its descendants are not visible or perceivable *to any user*..."
Yet we've outlined here many use cases for hiding content from screen
reader users that is visible or perceivable to sighted users. Of
course reality and current implementations matter more than what the
specification says. If the predominant usage of ARIA is contradictory
to the specification's description, then the spec should probably be
updated to match reality (e.g., get rid of "to any user").

Jared

From: Steve Faulkner
Date: Thu, Dec 27 2012 10:58AM
Subject: Re: Is aria-hidden supposed to only hide content for screen readers/assistive technology, or is it supposed to hide content altogether?
← Previous message | No next message

Hi Jared

Re-reading the spec [1]

It is clear to me that aria-hidden is designed to be used in conjunction with methods to hide content from all users such as display none. It itself does not hide content from all users. It is primarily a declarative method to flag the state of content as hidden for user agents that do not either interpret CSS display states or display states exposed via accessibility APIs.


Note the spec also indicates it is not recommended but NOT forbidden to use aria-hidden to hide visible content from AT users only.


"Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies."

"Note: Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control. Similar problems may also arise for screen reader users. For example, a sighted telephone support technician may attempt to have the blind screen reader user click the "Go to checkout" link, which they may be unable to find using a type-ahead item search ("Go to…")."


[1] http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden