Re: How do assistive technologies handle icon fonts?

Though it is important to remember the non-screen reader use case when it comes to the way people actually use icon fonts in the wild. These suggestions are all valuable and important. But none of them will address the non-screen reader problems with the in-practice way people use the icon fonts:

1. No obvious corresponding text label, causing problems for speech users.
2. Very frequently used as nonstandard visual iconography, causing cognitive disability problems as well as general usability problems for everyone.
3. Usually low contrast, causing visual problems.
4. Usually not made focusable if they need to be.

Both this work that Michiel is discussing and the SVG alternatives are still both hugely valuable, and should happen! But as long as current design trends embrace the above four inaccessibility problems  -- which are generic to all kinds of websites, but happen right now to have a huge overlap with the websites that are designed with icon fonts -- there will still be big accessibility problems with these sites. And sadly, those four problems don't have an easy technological fix; they are a design principles problem.[1]


Which doesn't mean the screen reader + icon font or SVG accessibility work shouldn't happen, it just means that we need to be very careful about the language we use, clarifying "screen reader accessibility" not "accessibility", and putting all of the caveats into our discussions of icon fonts.


Deborah Kaplan

[1] If I want to be precise about it, number four, the focus problem, could have a technical fix but it would rely on the W3C and browser manufacturers.

1. The HTML spec could treat WAI-ARIA as the transitional point it was once arguably intended as and absorb most of aria's semantics, therefore gaining the benefit of native focus management instead of what often happens now, where developers remember to add aria for screen readers but forget to add tab index and onkeydown actions. Why shouldn't role=button make something into a button?


2. Lay to rest the obsession with hiding WAI-ARIA from everything except ATs. If role=button makes a button usable by screenreader users, why shouldn't it also turn it into a button for non-screenreader users?

Cf. "Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities." http://www.w3.org/TR/wai-aria/introduction



>
> That is what the tests in the repository are trying to figure out. If we can get different use cases with different solutions, we effectively write the documentation Font Awesome needs. Not to say that it is our duty to do so, but I like to work on it regardless—because it also affects icon fonts in general.
>
> So yes, I hope that there will be some documentation and maybe a smart solution to do the Right Thing™ automagically.
>
> I’ll add your suggestion to the repository.
>
> —Michiel
>
>
>

--