E-mail List Archives
Thread: ARIA-HIDDEN
Number of posts in this thread: 4 (In chronological order)
From: Weissenberger, Todd M
Date: Mon, Nov 05 2012 12:46PM
Subject: ARIA-HIDDEN
No previous message | Next message →
Sorry if this has been brought up recently...
A couple of developers in our group are experimenting with web fonts to deliver navigation icons (Directory, A-Z, Search, etc) on our site's main toolbar. The elements have solid text alternatives and tooltips-there is a concern with stutter, but anyway, the web font icons are essentially single characters mapped to a wingding, and these display in the default view of our new design. The screen reader user hears something like:
"V, Search"
...where "V" is the character mapped to the "Search" icon.
The developers want to use "aria-hidden" to hide the stray character (e.g., "e722"), exposing only the text equiv to the screen reader. While it seems counter-intuitive to me to use text only to hide it from the screen reader, the approach tested all right, and the project team seems pretty committed to the web font concept.
If this makes sense to anyone, feel free to drop a line.
Best,
Todd
T.M. Weissenberger
Web Accessibility Coordinator
University of Iowa
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
319-384-3323
From: Lucy Greco
Date: Mon, Nov 05 2012 1:12PM
Subject: Re: ARIA-HIDDEN
← Previous message | Next message →
so is the screen reader only seeing sertch
On 11/5/12, Weissenberger, Todd M < = EMAIL ADDRESS REMOVED = > wrote:
> Sorry if this has been brought up recently...
>
> A couple of developers in our group are experimenting with web fonts to
> deliver navigation icons (Directory, A-Z, Search, etc) on our site's main
> toolbar. The elements have solid text alternatives and tooltips-there is a
> concern with stutter, but anyway, the web font icons are essentially single
> characters mapped to a wingding, and these display in the default view of
> our new design. The screen reader user hears something like:
>
> "V, Search"
>
> ...where "V" is the character mapped to the "Search" icon.
>
> The developers want to use "aria-hidden" to hide the stray character (e.g.,
> "e722"), exposing only the text equiv to the screen reader. While it seems
> counter-intuitive to me to use text only to hide it from the screen reader,
> the approach tested all right, and the project team seems pretty committed
> to the web font concept.
>
> If this makes sense to anyone, feel free to drop a line.
>
> Best,
> Todd
>
> T.M. Weissenberger
> Web Accessibility Coordinator
> University of Iowa
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> 319-384-3323
>
> > > >
--
Lucia Greco
Web Access Analyst
IST-Campus Technology Services
University of California, Berkeley
(510) 289-6008
http://webaccess.berkeley.edu
From: John Foliot
Date: Mon, Nov 05 2012 2:59PM
Subject: Re: ARIA-HIDDEN
← Previous message | Next message →
Weissenberger, Todd M wrote:
>
> A couple of developers in our group are experimenting with web fonts to
> deliver navigation icons (Directory, A-Z, Search, etc) on our site's
> main toolbar.
Funny enough, I was having the exact same conversation with some devs at
work as well. I suspect we will be seeing more and more of this in the next
short while, as it has some significant benefits to the mobile side of
things - text being significantly smaller and easier to transport to
hand-helds, etc. This type of techniques is (I suspect) even better than
sprites/CSS BG images because there are no images being sent down the wire.
(I even have the beginning of a blog-post on this, which may become
redundant if I don't get cracking and finish it soon)
>
> The developers want to use "aria-hidden" to hide the stray character
> (e.g., "e722"), exposing only the text equiv to the screen reader.
> While it seems counter-intuitive to me to use text only to hide it from
> the screen reader, the approach tested all right, and the project team
> seems pretty committed to the web font concept.
No, actually, this is a very good use-case for aria-hidden in my opinion,
when you want to hide redundant content from screen readers (in this case,
less redundant and more meaningless). As well, since the last time I tested
aria-hidden (http://john.foliot.ca/aria-hidden) it now appears that we can
expect support from NVDA (http://www.nvda-project.org/ticket/2117) as well
as JAWs going back to IE8 (as well as support in VoiceOver and ChromeVox -
if anyone has test results from other screen readers please speak up), so it
would seem that this is a fairly robust solution.
>
> If this makes sense to anyone, feel free to drop a line.
Makes total sense, and in fact I think it is something that, if/when you get
it implemented, we should be sharing back to the community (impetus on me to
finish the blog post too). My vote? Go for it!
JF
From: Ken Petri
Date: Mon, Nov 05 2012 3:44PM
Subject: Re: ARIA-HIDDEN
← Previous message | No next message
Interestingly, here's a piece by Chris Coyier that has techniques for this:
http://css-tricks.com/html-for-icon-font-usage/. Bonus, it recommends using
the awesome IcoMoon icon font tool.
ken
--
Ken Petri
Program Director, OSU Web Accessibility Center
102D Pomerene Hall, 1760 Neil Avenue, Columbus, Ohio 43210
Office: 614.292.1760 | Mobile: 614.218.1499 | Fax: 614.292.4190
http://wac.osu.edu | = EMAIL ADDRESS REMOVED =
On Mon, Nov 5, 2012 at 4:59 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> Weissenberger, Todd M wrote:
> >
> > A couple of developers in our group are experimenting with web fonts to
> > deliver navigation icons (Directory, A-Z, Search, etc) on our site's
> > main toolbar.
>
> Funny enough, I was having the exact same conversation with some devs at
> work as well. I suspect we will be seeing more and more of this in the next
> short while, as it has some significant benefits to the mobile side of
> things - text being significantly smaller and easier to transport to
> hand-helds, etc. This type of techniques is (I suspect) even better than
> sprites/CSS BG images because there are no images being sent down the wire.
> (I even have the beginning of a blog-post on this, which may become
> redundant if I don't get cracking and finish it soon)
>
> >
> > The developers want to use "aria-hidden" to hide the stray character
> > (e.g., "e722"), exposing only the text equiv to the screen reader.
> > While it seems counter-intuitive to me to use text only to hide it from
> > the screen reader, the approach tested all right, and the project team
> > seems pretty committed to the web font concept.
>
> No, actually, this is a very good use-case for aria-hidden in my opinion,
> when you want to hide redundant content from screen readers (in this case,
> less redundant and more meaningless). As well, since the last time I tested
> aria-hidden (http://john.foliot.ca/aria-hidden) it now appears that we can
> expect support from NVDA (http://www.nvda-project.org/ticket/2117) as well
> as JAWs going back to IE8 (as well as support in VoiceOver and ChromeVox -
> if anyone has test results from other screen readers please speak up), so
> it
> would seem that this is a fairly robust solution.
>
> >
> > If this makes sense to anyone, feel free to drop a line.
>
> Makes total sense, and in fact I think it is something that, if/when you
> get
> it implemented, we should be sharing back to the community (impetus on me
> to
> finish the blog post too). My vote? Go for it!
>
> JF
>
>
>
> > > >
>
>