In the following presentation “Death to Icon Fonts” from the London Web Standards conference, Seren Davies makes the case for using SVGs instead of icon fonts (like Font Awesome). The presentation highlights several serious accessibility problems caused by icon fonts, like incompatibility with special fonts used by many people with dyslexia (a condition which affects 10% of the population).
Is Discourse doing a disservice to 10% of its potential users by using an icon font so widely throughout the site? This presentation suggests it is. What do you think?
That is interesting but I have to admit I have yet to see one bug report for someone using a dyslexic font like that. Maybe 10% of users are dyslexic but almost none of them are using that solution?
Having said that, while icons are an important part of Discourse, I am not attached to keeping them as fonts. One thing I’ve been doing over the last few releases is converting our font icon HTML to a helper {{fa-icon}}, because in the past changes to how our icons have rendered as HTML have really bitten us. I think @neil spent a whole day once refactoring old font HTML.
In theory those {{fa-icon}} components could spit out SVG if we wanted. I’d entertain a pull request that did that, although we would be wary of performance regressions and file size.
(also I am also curious why a dyslexic font couldn’t just ignore the icons and only apply to letters)
Because many of the icons substitute letters in the character set, which results in a dyslexic reader such as JAWS reading the equivalent lettering out.
The two obvious long-term solutions are unicode (once it has been sufficiently extended, we’re not far off) or some form of Title property, but I’m not sure any reader products at the moment would support either approach.
It’s not limited to people using a dyslexic font. It’s people using any own-font, or having a browser that fights you, like my firefox (I can’t really see why it blocks fonts, but I had to go look up how to enable them in some freaky about.config setting and then several reboots later it somehow either reset, or I had to undo it to get ZoomText to work in firefox, where stuff like font smoothing and any other weirdness usually has to be off to make ZT work well).
(ZT is screen magnification)
I’ve gotten used to seeing boxes everywhere, and if it’s decorative, who cares.
When it’s the sole visible text of something you use, like a button or a call to action, then it’s a problem.
Another set of users to think of: Dragon users. Can they always guess correctly the name of something represented with an image? Is a heart “love button” or “like button”? Only the Shadow knows…
(luckily you can get around stuff like no (known) names in dragon often by just looking for “buttons” or “links”, apparently… whew. Still sounds like a pain in the butt though)
Re bug reports: most users are like me: we’re lazy. We go elsewhere. We don’t go dive into the pit of figuring out bug reports. Instead, if we do anything, we b*tch on twitter or tumblr or something. Of course, without a bug report, how is anyone supposed to know there’s a problem? But, I’m just mentioning.
I’m sorry if I’m offending anyone by asking, but what the heck is a “Dragon” user? I knew a kid in college who thought he was a dragon, but I think that was mostly the LSD he was on talking…
I wouldn’t go that far. They’re already adding the font themselves.
Perhaps we can add the second part of @riking’s commit to core, then font awesome is forced always even if overwritten? Unless the font is doing something really odd.
Yes … IMHO that’s like telling someone since they chose to use a wheelchair, they’re responsible for workarounds to get equal access.
But agree that the @riking patch might be a good way to accommodate people with that extra need for accessibility, without affecting any standard users.
So to you, they altered their Discourse to use a strange font, overriding ALL fonts on Discourse, and thus have no part of the blame for the Font Awesome icons disappearing?!? I don’t see how that is in any way part of Discourse’s problem.
They very well could have chosen to not override the font-awesome parts. Even if the person is not running Discourse and they override ALL fonts, that is a bit different, but they will likely be accustom to the fact it breaks some parts of each website they visit.
SVG sort of solves the problem, but at what cost? How much larger does the page become that must be served to the Desktop and Mobile? I’d imagine it becomes significantly larger.
Plus wouldn’t you run into scaling issues with SVG? For those who have limited vision and run their browser at a larger font size than normal?
Deciding to use FontAwesome’s default implementation strategy is an implicit decision to “break” web accessibility guidelines because there is no semantic meaning contained inside the <i></i> markup. Personally, I think putting the blame on people who use a tool that doesn’t break web standards to assist with their disability is not an acceptable way to avoid creating web sites that can be used by as many people as possible.
These are good questions and should be explored before committing to SVG as a way to solve the problem. There are several different approaches and SVG was just one suggested by the presenter in the original post.
Can’t you use aria attributes to provide the accessibility data for font-awesome usage? I do admit, that just including the CSS styles doesn’t help, but that’s like putting an SVG image without any alt/title attributes. It isn’t the underlying image/font that is the problem, but the way the dev implemented it. Right?
