Update accessibility

[dylanb]

Please do two things:

1. Remove the mis-representation from your web site until you have properly fixed the problem, so that you do not continue to make the web a worse place for people with disabilities,
2. Fix the accessibility problems properly

[karlgroves]

@dylanb It might be good to cite the specific location(s) where the claim is made, this way an interested developer can find & fix the issue and issue a PR

[dylanb]

@karlgroves http://fontawesome.io/

[karlgroves]

Deleted my prior comment.

@dylanb - as an issue description, I think you know it should have better information in it so that action could be taken

@davegandy - The claim made in the footer of the http://fontawesome.io/ website which says " Screen Reader Compatible" is demonstrably false.

Given the icon fa-bed (http://fontawesome.io/icon/bed/)

Using the following markup: <i class="fa fa-bed"></i>

It creates CSS generated content: "\f236";

There are three accessibility problems that may result:

1. (and this is @dylanb's point) Screen readers may read that CSS generated content.
   The workaround for this scenario is to use aria-hidden like so: <i class="fa fa-bed" aria-hidden="true"></i> which would allow a screen reader to ignore it. BUT this raises another concern

2. Because it creates generated content, there's no text alternative.
   Imagine I did this <a href="http://www.github.com"><i class="fa fa-github"></i></a>
   That has no content in the text node of the DOM. It is, in almost all cases, a blank link. Going back to the above, users may get access to the generated content which, in all likelihood, actually sucks to hear on a screen reader. So here's the fix

   <a href="http://www.github.com"><i class="fa fa-github" aria-hidden="true"></i><span class="sr-only">Github</span></a>
   

   That uses the 'sr-only' class naming convention from Bootstrap, BTW. That's not necessary, but what is necessary is basically that (if you don't want the word "Github" to appear) the span be positioned off screen to hide it. This is effectively the same as having an alt attribute on an image

   But wait! There's more

3. There's a final problem: Windows High Contrast Mode. With Windows High Contrast mode turned on, the font icon is essentially rendered invisible. The problem is that it even with the offscreen span approach, the text in the span won't be visible. In short, to be fully accessible something else has to happen - namely detecting HCM and doing something to show the previously-hidden span: http://jsfiddle.net/karlgroves/XR8Su/6/

TL;DR: @dylanb is right. Your claim of being "Screen Reader Compatible" is inaccurate. I recommend removing this claim and improving documentation so people understand the accessibility implications of icon fonts.

[dylanb]

+1 what @karlgroves said :-)

[tagliala]

As far as I can tell from the above points, the statement compatible is still valid.

It seems that accessibility needs more docs.

[tagliala]

@dylanb Sorry for this bug but honestly I didn't like your opening post, I found it a little bit aggressive.

@karlgroves thanks for the very detailed explanation.

That claim is probably there because in the past icon fonts didn't use :before pseudoelement and didn't use PUA, so screen readers were "tripped up"

Please take a look #389, including my comments there

[ZoeBijl]

@karlgroves wouldn't a simple aria-label="bed" suffice? You could generate a ::before/::after with its text if HCM is enabled, right?

So something like this: <i class="fa fa-bed" aria-label="bed"></i>

I've made a testcase on GitHub which I've tested successfully in VoiceOver on OS X 10.10 with Safari 8.

[Heydon]

+1, @MichielBijl for aria-label

[LJWatson]

"1. (and this is @dylanb's point) Screen readers may read that CSS generated content."

With the exception of IE, most browsers (used in conjunction with screen readers) expose CSS generated content through the accessibility layer.
http://tink.uk/accessibility-support-for-css-generated-content/

[hanshillen]

Just to confirm and / or clarify a few things:

1. Yes, the generated character needs to be hidden from screen readers. In a lot of cases the character will have no effect, but it's possible that the screen reader will announce something incorrectly. For example, VoiceOver on IOS can announce the characters as (completely unrelated) emoji symbols.

   And yes, aria-hidden should be used for this. Unfortunately, placing the attribute on the element (that has the icon related class name) itself is not going to work. Since font icons use the :before pseudo selector, the inserted character will end up adjacent to the element with the aria-hidden attribute rather than inside of it. In other words, the character will still be exposed to assistive technology, and aria-hidden will unnecessarily hide an empty element.

   So for this to work, you would have to wrap another element around the , ensuring that the character will still be inserted inside of it. For example:

     <span aria-hidden="true">
         <i class="fa fa-bed"></i>
     </span>
   

   Unfortunately this makes the code a bit more bulky, but it will solve this particular accessibility issue.

2. Yes, as with any meaningful graphic, alternative text will have to be provided (by the developer, not the icon library). The easiest way to do this, as Karl mentioned, is with Bootstrap's sr-only class (or a similar class used for visually hiding content in an accessible way).

   Combined with the previous item, code would look like this:
   
   Bed

   Note that the "appropriate" text to insert will depend on how the icon is used. It could be "bed", "available beds", "bookings" etc. depending on the context. Or the text could be left out altogether if the icon is used redundantly (adjacent to visible text), or decoratively.

   The aria-label approach seemingly makes sense, but is not guaranteed work consistently across browsers and screen readers. The reason is that generally, aria-label would be applied to provide an accessible name to an element with a valid role (e.g. "button", "tab", etc). Adding it to a role-less element such as may cause the aria-label text to be ignored depending on the browser / screen reader combination used.

   For this reason, using hidden text as described above (.sr-only) is more reliable, and it has an additional benefit: If CSS were to be disabled for whatever reason (e.g. by the user's choice) the hidden text would become visible and provide a fallback for the now invisible icon. You would't get this benefit with attributes like title or aria-label.

3. Font icons are actually Windows High Contrast Mode safe, because HC Mode does not override the icon's font-family (just the color and size). However, the issue Karl describes does occur for user defined stylesheets, which are likely to do exactly that: override font-family for all elements, causing the font based icons to break. It's one of the major accessibility issues related to font icons that is (unlike to the other two issues) hard to resolve by the dev. It requires some workaround, like a script that detects overridden font family or an "invisible font" for the fallback text. Both these approaches are described at http://files.paciellogroup.com/training/CSUN2014/lessonslearned/ (use case 3, see slide deck for background info).

These issues are not specific to FontAwesome, but apply to font based icon sets in general. The first two are solvable through some (perfectly reasonable) effort on the developer's end. Since the average dev is not going to automatically understand all this, it would be good if these issues and approaches were documented. Not just for FontAwesome, but for the other icon sets as well (icomoon.io would be a good place). So yes you can easily use FontAwesome without tripping up a screen reader, but it would help if the documentation didn't make it seem like this is the case out of the box and explain what the dev needs to do to get there.

The third issue is not related to screen readers but still a big problem (which should also be documented).

[StommePoes]

@hanshillen @karlgroves re Hans' item 2: how does the sr span inside the aria-hidden get seen? I thought that covered all descendants?

[hanshillen]

@StommePoes you're absolutely right, I wasn't paying attention. have updated the snippet accordingly!

[tagliala]

@hanshillen thanks for your post

We should definitely document this.

Do you know if the speak: none css property could be used to avoid the extra markup?

edit: it seem it doesn't http://modernwebaccessibility.com/en/blog/demystify-speak-none

[StommePoes]

@tagliala I've never heard of any of the CSS audio stuff working for anything other than nasty IE5.5 hacks :P

[ZoeBijl]

@hanshillen thank you for the clarification. Seems that VO indeed shows the character, it just didn't say it. Might just be the characters in my example, though.

[Jonathan-Eyler-Werve]

Thanks to everyone working on this from a developer deploying Font Awesome who cares about accessibility.

[IdanCo]

I've been working on a very big project with allot of emphasis on accessibility. While looking for a screen-reader friendly solution for font icons, I came across @hanshillen solution and really liked it. So I've implemented it in an angular directive - https://github.com/picardy/angular-fontawesome
Hope you'll find it useful

[StommePoes]

I'm re-reading this part by @hanshillen: "Since font icons use the :before pseudo selector, the inserted character will end up adjacent to the element with the aria-hidden attribute rather than inside of it."

Maybe I'm misunderstanding pseudo-elements, but someone with a :before has a new first-child, not a new previous sibling. Someone with an :after has a new last-child, not a new next sibling.

So logically thinking, aria-hidden on someone should cover all of someone's children, and :before and :after are children, not new siblings. Correct?

<i aria-hidden="true">[ :before-child, existing-or-empty-default-children, :after-child ]</i>

[IdanCo]

@StommePoes you just blew my mind. I might be looking at it all wrong. the problem is that i don't have a screen reader at hand, so QAing this is bit of a strech. I'll do some expirements and get back to you.

[hanshillen]

I'll do some more testing as well

[davegandy]

First, let's clear the air. None of these issues are intentional misrepresentations. The world changed since that statement was originally made. And we're fixing those problems right now.

Stepping back from this particular issue, I don't believe we've been given the benefit of the doubt here. Some particular folks appear to belive this was malicious on our part. It was not. Just like you would have for your own self, I'll challenge you to assume good motivations on the part of others.

And know that your reputation follows you online. Especially here on GitHub. Folks in the community learn who the bad actors are and don't like dealing with them, no matter how smart they are and what they know. Seriously, think about it. If you think this might be written to you, it probably is. Your involvement is honestly appreciated. But please be polite, respectful, and assume good intentions of others.

For context, when Font Awesome came out 4 years ago, making icons as fonts work with screen readers was a major priority. And it worked well. Since then, the world changed. Screen readers changed, but Font Awesome didn't keep up.

Going forward, vetted accessibility issues will be given priority for any subsequent release. It's not been enough of a priority lately, and we're changing that.

We really do appreciate you experience, knowledge, and expertise. Thank you for helping out the project, and for helping the literally millions of folks that use this.

[StommePoes]

I think the responsiveness of the folks replying showed right away that someone at FA cares. Otherwise this issue would have languished as one of many moldering github issues. Instead, it's got good debate, exchange of code techniques, and open discussion. Seems to reflect well on the FA folks.

[ZoeBijl]

Amen to that.

[tagliala]

Could someone please provide feedback on:

1. Using title attribute vs "sr-only"

<span class="fa fa-icon" aria-hidden="true"></span>
<span class="fa-sr-only">Icon</span>

vs

<span class="fa fa-icon" aria-hidden="true" title="Icon"></span>

2. Using <i> instead of <span> in the docs

Is there any difference for screen readers?

[IdanCo]

@tagliala -
(1) the problem with the second option is that aria-hidden means the entire element is hidden in screen readers, therefore the alt text will disappear as well.
(2) not that i know of.

[davegandy]

So there are lots of use cases here, covered extensively in #8879. Check there to review all use cases.

For the simplest case where there is semantic meaning you would like read to the user, here's what we're proposing.

<span class="fa fa-icon" aria-hidden="true"></span>
<span class="sr-only">Icon</span>

We're planning in using the the same class as Bootstrap (sr-only and sr-only-focusable), since they're using standard techniques that should be adopted as broadly as possible. If there's a change, we'll update the classes.

[davegandy]

This has been added into the 4.6.0-wip branch. Closing.

[tagliala]

Hi again,

could you please review https://github.com/FortAwesome/Font-Awesome/pull/8950/files ?

Thanks!

[techsethi]

+1, Its not clear why the issue got closed.

[tagliala]

@techsethi because a documentation page about accessibility is there: http://fontawesome.io/accessibility/

[jakemoves]

Thanks to all who are participating in this discussion, I really appreciate the focus on making sure FA works for all users!

[Janther]

How much work would need to build the fonts in a contextual way like https://design.google.com/icons/ where the glyphs change according to the context?

For example when you write the word accessibility, where ac is empty space, the ces is the left arm, the sib is the body, ili the right arm ty are rendered as trailing empty space.

I just know the theory behind it and the idea, but sadly not the implementation.

If this could be scripted, I imagine an utility where you provide imaged and matching words and you get a set of fonts where each letter gets translated into a slice of the image only when the word is completely written.

this way instead of

.fa-universal-access:before {
  content: "\f29a";
}

We could have

.fa-universal-access:before {
  content: "universal-access";
}

Just imagine the benefits, if this utility where simple to use one could generate localized fonts or refine the wording for a specific use case and we would have a much more accessible web.

Googles Material Icons provide .eot, .ttf, .woff, and .woff2 fonts so most browsers should support this system.

[Janther]

Upon digging a little into Google's Material Icons I noticed that they use ligatures.
This means that encoded in the font is the actual Glyph within the PUA of the font. And on the Glyph's metadata is a ligature that tells the font that if there is an exact match for that word, to use that Glyph.
As seen in this screenshot of font forge when inspecting a Glyph.

To elaborate a little here is a test I did with the Material Design Icon Font.

CSS

.material-icons {
  font-size: 100px;

  &.accessibility:before {
    content: 'accessibility';
  }

  &.accessibility-unicode:before {
    content: '\e84e';
  }
}

HTML

<div class="material-icons">
  <span>accessibility</span>
</div>
<i class="material-icons accessibility"></i>
<i class="material-icons accessibility-unicode"></i>

Result
http://codepen.io/janther/pen/gMYpQx

My point is that given that the only thing needed is to add the ligatures to the existing unicode glyph, the benefits are incredible compared to the amount of work devoted to adding the ligatures (which I suspect could be automated).

Edit

I just saw this #8510. You guys are great!!

[tylergale]

This is an excellent thread! Very useful information in this post.

[tagliala]

Hi, could you please provide feedback here: #9566 ?

Thanks!