sábado, 28 de enero de 2012

Icon Fonts Follow up

Since publishing a section from The Icon Handbook as part of 24 Ways last December (Displaying Icons with Fonts and Data- Attributes) I've been involved in a few discussions regarding its cons, some of which have since gained workarounds, and it felt a good time to do a follow up post.

First of all, its worth mentioning the context of the article – it's from Chapter 6, where all the various possible methods for deploying icons on the web are laid out. This includes creating icons with CSS, which isn't something I'd recommend, but just may be a solution for someone out there and work well in a particular context. In the same vein, using fonts to display icons is just one of the options.

Lets go over the 2 cons that keep coming up:

Unicode Mapping

Jon Tan states (rightly) that where matching unicode characters exist, the key should be mapped to that (such as the heart symbol for Favourites) and others that don't to Private Use Areas where they have no associated meaning or content. This isn't a problem with the technique as much as the current implementation of the fonts. Its solvable, although doing so will add an extra layer of complexity in specifying the correct letter. There's also not going to be many icons that can be mapped of course.

Drew Wilson has improved this situation with his release of Pictos Server – a typekit style hosted service where you can choose only the icons you want in the font, as well as what letter its mapped to. It also helps another issue with the technique – that of icon choice. Adding a new icon to a font is complex work, but with 650 to choose from, its less likely to be an issue.

Another option here is IcoMoon which allows icons to be mapped to Private Use Areas in Unicode, thereby avoiding odd content altogether.

See also:

Screenreaders speak generated content

Using CSS to insert content has the side effect of the icon letter being read out by screenreaders. Not the worst accessibility issue, but confusing.

However Eric Eggert discovered that this can be avoided with the ARIA attribute: aria-hidden="true". This is required for every instance, but Eric also points out that this can be automated with a small snippet of javascript. Read Eric's post A better way to use icon fonts. Not all screenreaders support ARIA, so it may be best avoiding the need altogether by using Private Use Areas mentioned above.

But…

For me, the biggest issue is pixel crispness. Unless you spend an awful lot of time hinting the font properly, you just won't get the same crispness that you can achieve with a PNG.

Once everyone has high density screens this won't be an issue, but in the meantime, I'm thinking more along the lines of SVG Sprites to implement my own icons and gain scalability.

No hay comentarios:

Publicar un comentario