E-mail List Archives

Search E-mail List Archives for

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

From: Joseph Sherman
Date: Mon, Apr 11 2016 10:27AM
Subject: Font Icons and Pseudo-elements
No previous message | Next message →

Our web folks are suddenly using Font Icons and Pseudo-elements. Both seem to have some accessibility issues in our implementation.


1) The Font Icons are being used instead of IMG, in links with Title attributes. Unfortunately, accessibility support is inconsistent. When tabbing with NVDA or JAWS, the Title is always read properly. But when using JAWS and the "H" key, or having NVDA or JAWS list the elements, or , when on a Mac using VoiceOver, the screen reader just says "link" and does not read the Title. Would adding 'aria-label' to Font Icon links solve these?


2) They are using Generated content (::after) to indicate DocTypes for links to file downloads. So the file would say "Instructions, PDF", where the PDF is added by generated content. Unfortunately, when using IE the user will only hear "Instructions, link" without the file type. Internet Explorer is the only browser regularly used with a screen reader that does not expose the generated content as the accessible name for the element. Is there a way to add an ALT to the CSS for generated content like .new::before { content: url(./img/star.png); alt: "New!";

Joseph

From: Bim Egan
Date: Mon, Apr 11 2016 10:50AM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

Hi Joseph,

There's a lot to do to make font icons accessible. The most obvious issues
are for people who need to use personal stylesheets, you'll probably find
that there's no content at all or the dreaded white squares displayed when
your own stylesheet isn't being used.

Here's a good resource:
https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html

In short, icon fonts need a text alternative, one that will replace it when
it isn't displayed on the page.

Sorry, can't help with the pseudo elements, I just know that using them for
information is one of WCAG's failure techniques: F87 Failure of Success
Criterion 1.3.1 due to inserting non-decorative content by using :before and
:after pseudo-elements -
http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/F87

HTH

Bim

From: James A.
Date: Tue, Apr 12 2016 11:02AM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

Regarding icon-fonts, I am also currently looking for accessibility techniques to make these both accessible and more usable for a project using the open source Font-Awesome library. So far I have identified the following possible approaches and would appreciate anybody's experience for this!

1. for a purely decorative icon then use aria-hidden=true
2. if a text description is required then use aria-hidden in combination with off-screen text (e.g. bootstrap's sr-only class) to provide a text equivalent

As per these use cases http://ryanfrederick.com/sandbox/d8/icon-test/

However that does aid those who may need assistance with understanding what an icon means. So I am also exploring using a keyboard accessible pop-up in combination with aria-described by tags to improve usability and accessibility - the approach currently used on many of the buttons on Facebook and Twitter. I have still to look for a solution for accessing these pop-s up or equivalent help information for touch devices.

Any thoughts or experiences on these approaches would be gratefully appreciated!

Best wishes

Abi James
Accessibility Team, WAIS, ECS
University of Southampton, UK
Web: https://access.ecs.soton.ac.uk/

From: Robert Fentress
Date: Tue, Apr 12 2016 12:21PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

As I understand it, the problem with icon-only font icons (as opposed to
icons with visible text beside them) is that providing alternative text as
hidden text does not deal with users who are not blind, but who replace
their fonts for improved readability. For instance, a dyslexic user may
replace the fonts on a page with OpenDyslexic. There are also other,
non-accessibility-related reasons why someone may not be downloading and
using the web fonts associated with those font icons. Another thing I
noticed is that if you provide the alternative text using aria-label, it is
not voiced on iOS (or wasn't last time I checked), so you should be aware
of that.

The Filament Group has guidance on how to do accessible font icons that
seems to work in my testing:
https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html

But, really, SVG icons are probably the best:
http://blog.cloudfour.com/seriously-dont-use-icon-fonts/

Is there a reason why you can't use those?

Hope that helps!

Best,
Rob

On Tue, Apr 12, 2016 at 1:02 PM, James A. < = EMAIL ADDRESS REMOVED = > wrote:

> Regarding icon-fonts, I am also currently looking for accessibility
> techniques to make these both accessible and more usable for a project
> using the open source Font-Awesome library. So far I have identified the
> following possible approaches and would appreciate anybody's experience for
> this!
>
> 1. for a purely decorative icon then use aria-hidden=true
> 2. if a text description is required then use aria-hidden in combination
> with off-screen text (e.g. bootstrap's sr-only class) to provide a text
> equivalent
>
> As per these use cases http://ryanfrederick.com/sandbox/d8/icon-test/
>
> However that does aid those who may need assistance with understanding
> what an icon means. So I am also exploring using a keyboard accessible
> pop-up in combination with aria-described by tags to improve usability and
> accessibility - the approach currently used on many of the buttons on
> Facebook and Twitter. I have still to look for a solution for accessing
> these pop-s up or equivalent help information for touch devices.
>
> Any thoughts or experiences on these approaches would be gratefully
> appreciated!
>
> Best wishes
>
> Abi James
> Accessibility Team, WAIS, ECS
> University of Southampton, UK
> Web: https://access.ecs.soton.ac.uk/
>
>
>

From: Lucy Greco
Date: Tue, Apr 12 2016 1:56PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

also what does the dragon user say if they need to click that icon

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Tue, Apr 12, 2016 at 11:21 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

> As I understand it, the problem with icon-only font icons (as opposed to
> icons with visible text beside them) is that providing alternative text as
> hidden text does not deal with users who are not blind, but who replace
> their fonts for improved readability. For instance, a dyslexic user may
> replace the fonts on a page with OpenDyslexic. There are also other,
> non-accessibility-related reasons why someone may not be downloading and
> using the web fonts associated with those font icons. Another thing I
> noticed is that if you provide the alternative text using aria-label, it is
> not voiced on iOS (or wasn't last time I checked), so you should be aware
> of that.
>
> The Filament Group has guidance on how to do accessible font icons that
> seems to work in my testing:
> https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html
>
> But, really, SVG icons are probably the best:
> http://blog.cloudfour.com/seriously-dont-use-icon-fonts/
>
> Is there a reason why you can't use those?
>
> Hope that helps!
>
> Best,
> Rob
>
> On Tue, Apr 12, 2016 at 1:02 PM, James A. < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Regarding icon-fonts, I am also currently looking for accessibility
> > techniques to make these both accessible and more usable for a project
> > using the open source Font-Awesome library. So far I have identified the
> > following possible approaches and would appreciate anybody's experience
> for
> > this!
> >
> > 1. for a purely decorative icon then use aria-hidden=true
> > 2. if a text description is required then use aria-hidden in combination
> > with off-screen text (e.g. bootstrap's sr-only class) to provide a text
> > equivalent
> >
> > As per these use cases http://ryanfrederick.com/sandbox/d8/icon-test/
> >
> > However that does aid those who may need assistance with understanding
> > what an icon means. So I am also exploring using a keyboard accessible
> > pop-up in combination with aria-described by tags to improve usability
> and
> > accessibility - the approach currently used on many of the buttons on
> > Facebook and Twitter. I have still to look for a solution for accessing
> > these pop-s up or equivalent help information for touch devices.
> >
> > Any thoughts or experiences on these approaches would be gratefully
> > appreciated!
> >
> > Best wishes
> >
> > Abi James
> > Accessibility Team, WAIS, ECS
> > University of Southampton, UK
> > Web: https://access.ecs.soton.ac.uk/
> >
> >
> >

From: Moore,Michael (Accessibility) (HHSC)
Date: Tue, Apr 12 2016 2:32PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

"Mouse grid, 7, 3, 5, 9, ... click that" </sarcasm>

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Lucy Greco
Date: Tue, Apr 12 2016 2:35PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

mike thats ausom

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Tue, Apr 12, 2016 at 1:32 PM, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> "Mouse grid, 7, 3, 5, 9, ... click that" </sarcasm>
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
>

From: Caitlin Geier
Date: Wed, Apr 13 2016 10:55AM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

FontAwesome (one of the most popular icon font libraries) just released a
guide for using icon fonts accessibly - http://fontawesome.io/accessibility/

I find icon fonts to be quite useful - they're easy to implement and
manage, and you don't have to have a designer slaving away to create custom
images / icons to represent something. That being said, it's often better
to just use text. In the application I'm working on, we mostly use them as
decoration (aria-hidden=true).

On Tue, Apr 12, 2016 at 4:35 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:

> mike thats ausom
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Tue, Apr 12, 2016 at 1:32 PM, Moore,Michael (Accessibility) (HHSC) <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > "Mouse grid, 7, 3, 5, 9, ... click that" </sarcasm>
> >
> > Mike Moore
> > Accessibility Coordinator
> > Texas Health and Human Services Commission
> > Civil Rights Office
> > (512) 438-3431 (Office)
> >
> >

From: Joseph Sherman
Date: Wed, Apr 13 2016 11:51AM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

I read that guide, but it's not correct. In the section on "If an icon represents an interactive element", it relies on the Title attribute to provide an accessible alternative name for the element. In my testing, the screen reader just says "link" and does not read the Title when: using JAWS and the "H" key; or having NVDA or JAWS list the elements; or when on a Mac using VoiceOver.



Joseph

From: Patrick H. Lauke
Date: Wed, Apr 13 2016 12:04PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

On 13/04/2016 18:51, Joseph Sherman wrote:
> I read that guide, but it's not correct. In the section on "If an
> icon represents an interactive element", it relies on the Title
> attribute to provide an accessible alternative name for the element.
> In my testing, the screen reader just says "link" and does not read
> the Title when: using JAWS and the "H" key; or having NVDA or JAWS
> list the elements; or when on a Mac using VoiceOver.

According to the Name Computation algorithm, title should be taken into
account (as a last resort) to provide an accessible name
https://www.w3.org/TR/wai-aria/roles#textalternativecomputation - it
could be argued that AT that do not use/expose title are not quite
following the recommended algorithm.

Of course, there are more elegant ways of providing the extra label,
such as using actual aria-label, or using the same approach as in the
previous section of that guide, namely the visually hidden content.

I may push for an expanded explanation/suggestion in that guide, to
cover some alternatives.

P

>
>
> Joseph
>
>
>
>

From: deborah.kaplan
Date: Wed, Apr 13 2016 2:19PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | Next message →

Icon fonts can be quite useful, but the problem is that some designers get too wrapped up in how cool it is to create unique, wordless page controls for everything. Testing with real users shows that there is a very small number of universal icons. I believe most people seem to figure out shopping carts; "search" from magnifying glasses (although not if there's no accompanying search box!); "help" from question marks; "settings" from a gear; and a couple of others. But in user tests, there are a very small number of icons that people pick up naturally. Interesting side note--as of the last usability test I saw from about six months ago, people STILL don't understand hamburger menus. And those are ubiquitous; if they are still not widely understood, that gives some sense of how difficult it is for users to pick up new symbology.


People learn the icons for applications they use all the time, and not even all of those. I'm in github every day, and have been for years. But I'll be damned if I can remember what this three different type of squiggly line icon fonts stand for when I I am on one of the page views where the icon labels are obscured. There's not many websites that people use so ubiquitously that you can know they have a reasonable chance of eventually learning unique symbols, and that pool will vary by user base: Facebook, Gmail, Twitter, Github. Unless we are writing the kind of social media tools which are going to dominate people's communication, or workplace productivity tools that will dominate a person's daily workflow, we can't expect to be able to train our users.

Confession: we've got some icon fonts at work on the product I helped write, and I have to expand out the menu to get at the words every single time, because for the life of me I can't figure out which of these adorable little symbols means "Materials organized by topic." Is that because our designers failed? No, of course not--it's because the wider world hasn't developed a symbology to mean "materials organized by topic." There's no standard convention in the language of 10 x 10 images.

Now, this obviously isn't a problem inherent in the technology of icon fonts. It's a problem of design--the tendency of minimal design to remove color contrast and borders from usable controls, and to take textual labels away or hide them behind expandable menus. It's just that the ease of making these design choices with icon fonts seems to have increased the tendency of designers to use them as a universal panacea.

By all means, use the technology. Just use it sensibly. Even the best ARIA will only help the screen reader users; the rest of your users still won't know what the icons mean without help.

Deborah Kaplan

On Wed, 13 Apr 2016, Caitlin Geier wrote:

> FontAwesome (one of the most popular icon font libraries) just released a
> guide for using icon fonts accessibly - http://fontawesome.io/accessibility/
>
> I find icon fonts to be quite useful - they're easy to implement and
> manage, and you don't have to have a designer slaving away to create custom
> images / icons to represent something. That being said, it's often better
> to just use text. In the application I'm working on, we mostly use them as
> decoration (aria-hidden=true).
>
> On Tue, Apr 12, 2016 at 4:35 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
>
>> mike thats ausom
>>
>> Lucia Greco
>> Web Accessibility Evangelist
>> IST - Architecture, Platforms, and Integration
>> University of California, Berkeley
>> (510) 289-6008 skype: lucia1-greco
>> http://webaccess.berkeley.edu
>> Follow me on twitter @accessaces
>>
>>
>> On Tue, Apr 12, 2016 at 1:32 PM, Moore,Michael (Accessibility) (HHSC) <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > "Mouse grid, 7, 3, 5, 9, ... click that" </sarcasm>
>> >
>> > Mike Moore
>> > Accessibility Coordinator
>> > Texas Health and Human Services Commission
>> > Civil Rights Office
>> > (512) 438-3431 (Office)
>> >
>> >

From: Cliff Tyllick
Date: Wed, Apr 13 2016 7:46PM
Subject: Re: Font Icons and Pseudo-elements
← Previous message | No next message

Well said!

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Apr 13, 2016, at 3:19 PM, = EMAIL ADDRESS REMOVED = wrote:
>
> Icon fonts can be quite useful, but the problem is that some designers get too wrapped up in how cool it is to create unique, wordless page controls for everything. Testing with real users shows that there is a very small number of universal icons. I believe most people seem to figure out shopping carts; "search" from magnifying glasses (although not if there's no accompanying search box!); "help" from question marks; "settings" from a gear; and a couple of others. But in user tests, there are a very small number of icons that people pick up naturally. Interesting side note--as of the last usability test I saw from about six months ago, people STILL don't understand hamburger menus. And those are ubiquitous; if they are still not widely understood, that gives some sense of how difficult it is for users to pick up new symbology.
>
>
> People learn the icons for applications they use all the time, and not even all of those. I'm in github every day, and have been for years. But I'll be damned if I can remember what this three different type of squiggly line icon fonts stand for when I I am on one of the page views where the icon labels are obscured. There's not many websites that people use so ubiquitously that you can know they have a reasonable chance of eventually learning unique symbols, and that pool will vary by user base: Facebook, Gmail, Twitter, Github. Unless we are writing the kind of social media tools which are going to dominate people's communication, or workplace productivity tools that will dominate a person's daily workflow, we can't expect to be able to train our users.
>
> Confession: we've got some icon fonts at work on the product I helped write, and I have to expand out the menu to get at the words every single time, because for the life of me I can't figure out which of these adorable little symbols means "Materials organized by topic." Is that because our designers failed? No, of course not--it's because the wider world hasn't developed a symbology to mean "materials organized by topic." There's no standard convention in the language of 10 x 10 images.
>
> Now, this obviously isn't a problem inherent in the technology of icon fonts. It's a problem of design--the tendency of minimal design to remove color contrast and borders from usable controls, and to take textual labels away or hide them behind expandable menus. It's just that the ease of making these design choices with icon fonts seems to have increased the tendency of designers to use them as a universal panacea.
>
> By all means, use the technology. Just use it sensibly. Even the best ARIA will only help the screen reader users; the rest of your users still won't know what the icons mean without help.
>
> Deborah Kaplan
>
>> On Wed, 13 Apr 2016, Caitlin Geier wrote:
>>
>> FontAwesome (one of the most popular icon font libraries) just released a
>> guide for using icon fonts accessibly - http://fontawesome.io/accessibility/
>>
>> I find icon fonts to be quite useful - they're easy to implement and
>> manage, and you don't have to have a designer slaving away to create custom
>> images / icons to represent something. That being said, it's often better
>> to just use text. In the application I'm working on, we mostly use them as
>> decoration (aria-hidden=true).
>>
>>> On Tue, Apr 12, 2016 at 4:35 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> mike thats ausom
>>>
>>> Lucia Greco
>>> Web Accessibility Evangelist
>>> IST - Architecture, Platforms, and Integration
>>> University of California, Berkeley
>>> (510) 289-6008 skype: lucia1-greco
>>> http://webaccess.berkeley.edu
>>> Follow me on twitter @accessaces
>>>
>>>
>>> On Tue, Apr 12, 2016 at 1:32 PM, Moore,Michael (Accessibility) (HHSC) <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > "Mouse grid, 7, 3, 5, 9, ... click that" </sarcasm>
>>> >
>>> > Mike Moore
>>> > Accessibility Coordinator
>>> > Texas Health and Human Services Commission
>>> > Civil Rights Office
>>> > (512) 438-3431 (Office)
>>> >
>>> >