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