Instead of crafting a totally new technique to deal with this (which I’ve dabbled with in the past) let’s lean on what we’ve already started. But that functionality also needs to be audibly obvious.
Hopefully that functionality is obvious visually, with some kind of rollover state or general design obviousness. For instance, a shopping cart icon that you can click to go to your shopping cart. Say we have an icon that is a link or in some way functional, but it isn’t accompanied by any text. We’ll cover mapping characters at the end. But if you prefer class names, more power to you, that’s fine and doesn’t change this technique drastically. I find this perfectly semantic and even future proof (you could always select uniquely down the line even if you change the character). In our icon font, we map those special characters to the icon we want to use. icon-stats or something), we’re using a data-* attribute to hold exactly which character we want to insert. Holy cow that’s easy eh? Notice we aren’t using a specific class name for the icon (e.g. Speak: none /* Not to be trusted, but hey. And as a double-win freebie, this combined technique is ideal for keeping our CSS lean and mean as it requires no class-name-bloat and works well with the next use case we need to cover.įont-family: icons /* BYO icon font, mapped smartly */ If we combine the markup technique and pseudo element technique, we can insert the icon with no VoiceOver weirdness. One more dash of bad news, even with aria-hidden on the markup surrounding the icon, VoiceOver on OS X will announce “HTML Content” when in focus.
The good news is that if we use a bit of markup, we can use aria-hidden attribute to prevent it from being spoken. Pseudo elements just aren’t in the DOM and thus that probably makes it harder for third-party apps to do. ( reference 1, reference 2) Well, perhaps “fortunately” as if I’m reading the spec correctly that’s what it is supposed to do. Unfortunately, VoiceOver on OS X does read the content of pseudo elements. Using a pseudo element is tempting because 1) they aren’t read by most screen readers 2) we don’t need dedicated markup for the icon which is a semantic ideal. So to get that icon in there (remember we’re talking font icons here, we can’t just pad the left and use a background) we’ll need to insert some content. Let’s say we have a header like “Stats” and we want to set it apart from other headers on the page and emphasize it’s meaning. This ground has been treaded before, but I think the following techniques are a small step forward. As little awkwardness for screen readers as possible.You want the icon to stand alone but still be functional or informational.Where are we at right now in terms of the best markup for using icon fonts? Let’s cover some options I think are currently the best.
0 kommentar(er)
