New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update accessibility #6133

Closed
dylanb opened this Issue Apr 2, 2015 · 63 comments

Comments

Projects
None yet
@dylanb

dylanb commented Apr 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@karlgroves

karlgroves Apr 2, 2015

@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 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

This comment has been minimized.

Show comment
Hide comment
@karlgroves

This comment has been minimized.

Show comment
Hide comment
@karlgroves

karlgroves Apr 2, 2015

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

  1. 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.

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

  1. 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

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 2, 2015

+1 what @karlgroves said :-)

dylanb commented Apr 2, 2015

+1 what @karlgroves said :-)

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 2, 2015

Member

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

It seems that accessibility needs more docs.

Member

tagliala commented Apr 2, 2015

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

It seems that accessibility needs more docs.

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 2, 2015

Member

@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

Member

tagliala commented Apr 2, 2015

@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

@MichielBijl

This comment has been minimized.

Show comment
Hide comment
@MichielBijl

MichielBijl Apr 2, 2015

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@Heydon

Heydon Apr 2, 2015

+1, @MichielBijl for aria-label

Heydon commented Apr 2, 2015

+1, @MichielBijl for aria-label

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Apr 2, 2015

"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/

LJWatson commented Apr 2, 2015

"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

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Apr 2, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Apr 2, 2015

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

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

@hanshillen

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Apr 2, 2015

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

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

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 2, 2015

Member

@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

Member

tagliala commented Apr 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Apr 2, 2015

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

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

@MichielBijl

This comment has been minimized.

Show comment
Hide comment
@MichielBijl

MichielBijl Apr 2, 2015

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@Jonathan-Eyler-Werve

Jonathan-Eyler-Werve Aug 25, 2015

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

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

@IdanCo

This comment has been minimized.

Show comment
Hide comment
@IdanCo

IdanCo Sep 23, 2015

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

IdanCo commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Sep 24, 2015

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>

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

This comment has been minimized.

Show comment
Hide comment
@IdanCo

IdanCo Sep 24, 2015

@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.

IdanCo commented Sep 24, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Sep 24, 2015

I'll do some more testing as well

I'll do some more testing as well

@hanshillen

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Sep 24, 2015

@StommePoes is right. I tested with most common browser / screen reader combos, and adding aria-hidden="true" directly to the element that has the class name will successfully hide the icon's character inserted through the ::before pseudo selector. I've updated my initial comment accordingly, taking out the step about wrapping the icon in a separate element.

@StommePoes is right. I tested with most common browser / screen reader combos, and adding aria-hidden="true" directly to the element that has the class name will successfully hide the icon's character inserted through the ::before pseudo selector. I've updated my initial comment accordingly, taking out the step about wrapping the icon in a separate element.

@IdanCo

This comment has been minimized.

Show comment
Hide comment
@IdanCo

IdanCo Sep 24, 2015

Great! I came up with similiar results.
I'll update the directive in angular-fontawesome accordingly

IdanCo commented Sep 24, 2015

Great! I came up with similiar results.
I'll update the directive in angular-fontawesome accordingly

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Sep 24, 2015

Member

@hanshillen do you confirm that using <span class="fa fa-icon" aria-hidden="true"></span> does not work? Or, at least, it doesn't work with some browser and some screen readers?

Member

tagliala commented Sep 24, 2015

@hanshillen do you confirm that using <span class="fa fa-icon" aria-hidden="true"></span> does not work? Or, at least, it doesn't work with some browser and some screen readers?

@hanshillen

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Sep 24, 2015

No, my tests from today show that that snippet does work, so my earlier comment about having to wrap the icon in a separate element is no longer applicable.

Regards,

Hans Hillen

On Sep 24, 2015, at 18:01, Geremia Taglialatela notifications@github.com wrote:

@hanshillen do you confirm that using does not work? Or, at least, it doesn't work with some browser and some screen readers?


Reply to this email directly or view it on GitHub.

No, my tests from today show that that snippet does work, so my earlier comment about having to wrap the icon in a separate element is no longer applicable.

Regards,

Hans Hillen

On Sep 24, 2015, at 18:01, Geremia Taglialatela notifications@github.com wrote:

@hanshillen do you confirm that using does not work? Or, at least, it doesn't work with some browser and some screen readers?


Reply to this email directly or view it on GitHub.

@tnguyen14

This comment has been minimized.

Show comment
Hide comment
@tnguyen14

tnguyen14 Sep 24, 2015

@hanshillen your original comment still has this code snippet

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

Is that still the recommended way, or does @tagliala suggestion works, i.e.

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

@hanshillen your original comment still has this code snippet

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

Is that still the recommended way, or does @tagliala suggestion works, i.e.

<span class="fa fa-icon" aria-hidden="true"></span>
@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Sep 24, 2015

Member

Please let me know if something like

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

where fa-sr-only is implemented like bootstrap's sr-only is ok

Member

tagliala commented Sep 24, 2015

Please let me know if something like

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

where fa-sr-only is implemented like bootstrap's sr-only is ok

@IdanCo

This comment has been minimized.

Show comment
Hide comment
@IdanCo

IdanCo Sep 24, 2015

@tagliala I expect it to work great. My tests confirm it as well, also articles here and here.

A similiar fix is now implemented in angular-fontawesome.

IdanCo commented Sep 24, 2015

@tagliala I expect it to work great. My tests confirm it as well, also articles here and here.

A similiar fix is now implemented in angular-fontawesome.

@hanshillen

This comment has been minimized.

Show comment
Hide comment
@hanshillen

hanshillen Sep 24, 2015

@tnguyen14 yes @tagliala's snippet is the correct one. For some reason I'm not able to strikethrough a code snippet in Markdown, so my original one is still there in between strikethrough text. I could remove it altogether but I rather leave it there for transparency and to make sure people will understand other comments. @tagliala yes that last snippet is the way to go.

@tnguyen14 yes @tagliala's snippet is the correct one. For some reason I'm not able to strikethrough a code snippet in Markdown, so my original one is still there in between strikethrough text. I could remove it altogether but I rather leave it there for transparency and to make sure people will understand other comments. @tagliala yes that last snippet is the way to go.

@StommePoes

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Sep 25, 2015

@hanshillen after the strikethrough section, end of section one you can just add in non-strike text pointing to one of the comments with the correct code, that'll make the whole comment clearer I think.

@hanshillen after the strikethrough section, end of section one you can just add in non-strike text pointing to one of the comments with the correct code, that'll make the whole comment clearer I think.

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 3, 2016

Member

Could you please take a look at this PR: #8879?

Member

tagliala commented Apr 3, 2016

Could you please take a look at this PR: #8879?

@dylanb

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 3, 2016

I added multiple comments

dylanb commented Apr 3, 2016

I added multiple comments

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 3, 2016

Member

@dylanb thanks for the feedback. Just a curiosity of mine: why the role="presentation" stuff didn't come out here? I was stick to #6133 (comment)

Member

tagliala commented Apr 3, 2016

@dylanb thanks for the feedback. Just a curiosity of mine: why the role="presentation" stuff didn't come out here? I was stick to #6133 (comment)

@dylanb

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 4, 2016

@tagliala your markup was

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

This is different from the markup in the commits which had an enclosing element and the aria-hidden was placed on the enclosing element (which hides all children). This may seem like an insignificant difference, but it is not.

<i class="fa fa-cog" aria-hidden="true">
    <span class="sr-only">Settings</span>
</i>

Also, I probably wasn't paying close enough attention to recommend the better solution - apologies.

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

dylanb commented Apr 4, 2016

@tagliala your markup was

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

This is different from the markup in the commits which had an enclosing element and the aria-hidden was placed on the enclosing element (which hides all children). This may seem like an insignificant difference, but it is not.

<i class="fa fa-cog" aria-hidden="true">
    <span class="sr-only">Settings</span>
</i>

Also, I probably wasn't paying close enough attention to recommend the better solution - apologies.

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 4, 2016

Member

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

Sure, is there any code in the commits that does this? I'm not able to find it

Just found this one http://john.foliot.ca/aria-hidden/ are those information up to date? What about both role="presentation" and aria-hidden="true"?

Btw bootstrap only uses aria-hidden for its glyphicons

Member

tagliala commented Apr 4, 2016

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

Sure, is there any code in the commits that does this? I'm not able to find it

Just found this one http://john.foliot.ca/aria-hidden/ are those information up to date? What about both role="presentation" and aria-hidden="true"?

Btw bootstrap only uses aria-hidden for its glyphicons

@StommePoes

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Apr 4, 2016

I think what needs to be made clear here is what those two things do.
Role=presentation can take something which has a default, native role in HTML (an <img/> has a default, native role of "img", a <button> has a default, native role of "button" etc) and remove that role, making that thing seem like a <div> or <span>. Putting role="presentation" on something that has no default, native roles (like <i>... or <div>) does nothing useful.
It can also, of course, override a role assigned earlier by an author (someone made a <div role="button"> for some reason and now wants to remove that role).
It does not silence anything inside the tag or remove the content from the accessibility tree in the browser. It just removes any name for that content, if there was any.

aria-hidden removes the thing, and its content, from the accessibility tree. If you were to put aria-hidden="true" on a something that happens to have a default, native (or author-assigned) role, I don't believe there's anything to be gained by also adding role="presentation" to that-- hidden is hidden.

I had seen on github some of the new SVG icons which had both aria-hidden=true and an added role=img. I had asked someone why that was, and the answer was "sometimes the SVG with the role=img isn't aria-hidden" so roles or role=presentation might make sense somewhere if you're concerned about announced roles when removing aria-hidden, I suppose.
However in the context of icons in <i> tags, I don't see roles either way being useful.

I think what needs to be made clear here is what those two things do.
Role=presentation can take something which has a default, native role in HTML (an <img/> has a default, native role of "img", a <button> has a default, native role of "button" etc) and remove that role, making that thing seem like a <div> or <span>. Putting role="presentation" on something that has no default, native roles (like <i>... or <div>) does nothing useful.
It can also, of course, override a role assigned earlier by an author (someone made a <div role="button"> for some reason and now wants to remove that role).
It does not silence anything inside the tag or remove the content from the accessibility tree in the browser. It just removes any name for that content, if there was any.

aria-hidden removes the thing, and its content, from the accessibility tree. If you were to put aria-hidden="true" on a something that happens to have a default, native (or author-assigned) role, I don't believe there's anything to be gained by also adding role="presentation" to that-- hidden is hidden.

I had seen on github some of the new SVG icons which had both aria-hidden=true and an added role=img. I had asked someone why that was, and the answer was "sometimes the SVG with the role=img isn't aria-hidden" so roles or role=presentation might make sense somewhere if you're concerned about announced roles when removing aria-hidden, I suppose.
However in the context of icons in <i> tags, I don't see roles either way being useful.

@talbs

This comment has been minimized.

Show comment
Hide comment
@talbs

talbs Apr 4, 2016

Member

This is different from the markup in the commits which had an enclosing element and the aria-hidden was placed on the enclosing element (which hides all children). This may seem like an insignificant difference, but it is not.

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

@dylanb, thanks for the review and these catches. My bad for the incorrect copy and paste location - avoiding placing the text alternatives inside of the aria-hidden="true" element makes perfect basic sense. :)

Member

talbs commented Apr 4, 2016

This is different from the markup in the commits which had an enclosing element and the aria-hidden was placed on the enclosing element (which hides all children). This may seem like an insignificant difference, but it is not.

Actually, come to think of it, you may still want aria-hidden to suppress the announcement of the unicode if that is causing trouble but you will certainly want to not put your screen reader text inside the aria-hidden element.

@dylanb, thanks for the review and these catches. My bad for the incorrect copy and paste location - avoiding placing the text alternatives inside of the aria-hidden="true" element makes perfect basic sense. :)

@dylanb

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 4, 2016

@talbs my pleasure, you might also want to take heed of the title attribute suggestion for users with cognitive disabilities

dylanb commented Apr 4, 2016

@talbs my pleasure, you might also want to take heed of the title attribute suggestion for users with cognitive disabilities

@talbs

This comment has been minimized.

Show comment
Hide comment
@talbs

talbs Apr 4, 2016

Member

@talbs my pleasure, you might also want to take heed of the title attribute suggestion for compatibility with Dragon

Yeah, can you walk me through your thinking when you noted that (see #8879 (comment))? Why and exactly when would using a title attribute be better to recommend than the <span class="sr-only">alternative text equivalent</span>?

Thanks for the help.

Member

talbs commented Apr 4, 2016

@talbs my pleasure, you might also want to take heed of the title attribute suggestion for compatibility with Dragon

Yeah, can you walk me through your thinking when you noted that (see #8879 (comment))? Why and exactly when would using a title attribute be better to recommend than the <span class="sr-only">alternative text equivalent</span>?

Thanks for the help.

@dylanb

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 4, 2016

Sorry, I corrected my statement above

dylanb commented Apr 4, 2016

Sorry, I corrected my statement above

@davegandy davegandy modified the milestones: 4.5.1, 5.0.0 Apr 5, 2016

@davegandy davegandy changed the title from Your icon fonts are not accessible and stating that they do not "trip up" screen readers is mis-representation to Update accessibility Apr 5, 2016

@davegandy

This comment has been minimized.

Show comment
Hide comment
@davegandy

davegandy Apr 5, 2016

Member

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.

Member

davegandy commented Apr 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@StommePoes

StommePoes Apr 5, 2016

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.

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.

@MichielBijl

This comment has been minimized.

Show comment
Hide comment
@MichielBijl

MichielBijl Apr 5, 2016

Amen to that.

Amen to that.

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 5, 2016

Member

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?

Member

tagliala commented Apr 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@IdanCo

IdanCo Apr 5, 2016

@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.

IdanCo commented Apr 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davegandy

davegandy Apr 5, 2016

Member

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.

Member

davegandy commented Apr 5, 2016

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.

talbs added a commit that referenced this issue Apr 6, 2016

adding accessibility information and best practices
* adding accessibility informational page
* adding in accessibility-minded examples
* adding accessibility practices to icon markup example
* updating doc site icons with accessibility best practices
* updating homepage with accessibility information

Fix #6133

talbs added a commit that referenced this issue Apr 6, 2016

adding accessibility information and best practices
* adding accessibility informational page
* adding in accessibility-minded examples
* adding accessibility practices to icon markup example
* updating doc site icons with accessibility best practices
* updating homepage with accessibility information

Fix #6133

talbs added a commit that referenced this issue Apr 6, 2016

adding accessibility information and best practices
* adding accessibility informational page
* adding in accessibility-minded examples
* adding accessibility practices to icon markup example
* updating doc site icons with accessibility best practices
* updating homepage with accessibility information

Fix #6133
@davegandy

This comment has been minimized.

Show comment
Hide comment
@davegandy

davegandy Apr 6, 2016

Member

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

Member

davegandy commented Apr 6, 2016

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

@davegandy davegandy closed this Apr 6, 2016

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 12, 2016

Member

Hi again,

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

Thanks!

Member

tagliala commented Apr 12, 2016

Hi again,

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

Thanks!

@techsethi

This comment has been minimized.

Show comment
Hide comment
@techsethi

techsethi Apr 19, 2016

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

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

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Apr 19, 2016

Member

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

Member

tagliala commented Apr 19, 2016

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

@jakemoves

This comment has been minimized.

Show comment
Hide comment
@jakemoves

jakemoves Apr 25, 2016

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

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

@Janther

This comment has been minimized.

Show comment
Hide comment
@Janther

Janther May 25, 2016

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 commented May 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Janther

Janther May 25, 2016

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.
screenshot 2016-05-25 14 46 59

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!!

Janther commented May 25, 2016

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.
screenshot 2016-05-25 14 46 59

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 comment has been minimized.

Show comment
Hide comment
@tylergale

tylergale Jun 1, 2016

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

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

@tagliala

This comment has been minimized.

Show comment
Hide comment
@tagliala

tagliala Jul 13, 2016

Member

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

Thanks!

Member

tagliala commented Jul 13, 2016

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

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment