Icon Fonts Verses SVG

I went down a rabbit hole for a little bit into the realm of icon fonts.

I personally feel that they solve a series of problems from a UX designer perspective, and was interested in the conversations around the strong opinions as to why they should be avoided.

To sum up the conclusion, as with any problem with implementing a user experience or accessibility solution, the answer indomitably is "it depends."

It all depends on how you're using them, who your users are, what your "product" is, and other technology you may have to accommodate to.

In the article "Seriously, Don't Use Icon Fonts" by Tyler Sticka, he lists some strong arguments against fonts, and for SVG's; such as:

  • Font Icons may not display the correct icon, or display at all, depending on browser compatibility or if the user has selected to use a specific font such as OpenDyslexic
  • Screen readers read out the font icon if it's not hidden
  • They don't allow for multi-color or animated images
  • It relies on unicode support to interpret them correctly and not get mixed with emojis
  • Most won't go through the effort to provide fallback images in case font icons fail; or even if you do, it will be too hard to maintain
Four star emojis and a horse replacing the last star
Example of unicode getting mixed up to replace the fifth star with a horse emoji on Etsy circ 2015


Since his article was written, there have been big advancements to some of the "broken font icon" issues he mentioned, and much more browser support.

In response to his article, Ben Frain wrote "Seriously, Use Font Icons" with a convincing list of reasons why you should use them, such as:

  • They are better supported by Android 2.3 which has less support for SVG's
  • They can scale and respond with any device-inherit text scaling settings
  • You don't need multiple font formats
  • They can have relatively robust visual styling applied with simple CSS
  • Pages render faster with font icons

Some of the take aways that I was able to apply this to was:

If you're using icon fonts to enhance existing elements, use aria-hidden="true" to make sure screen readers don't read the icon name. This is relevant if your primary use of icon fonts are to add a pleasant visual to things like buttons or section headers to call out meaning with, but not rely solely on the image to understand the meaning. For example, a delete button can have a hidden trash can font icon because the text in the button is "delete."

If you need to ensure that there's an icon that displays, use an SVG. If your experience relies on the user being able to see the image reliably in order to complete their tasks, make sure that wont be a problem based on a font issue. This is most relevant to images that you'd need animation, multi colors, and if you are trying to accomodate to users who may use a different font than the one you've specified for the site.

If you have excessive issues with SVG sprite sheets not working correctly, icon fonts might be more appropriate. It can be frustrating to not have sprites appear the way they're intended, and can cause confusion for users if it overlaps with another icon. If the use of the icon is straightforward, and not crucial to the experience, icon fonts might be an appropriate direction to take until issues can be fixed.

If you're having problems with the font icons not looking aligned to text consistently, consider standardizing SVG's for any icon that needs to appear in a consistent way next to text. This would be relevant to varying icon images that may appear out of alignment to text due to the fact that some images are different proportions to horizontally or vertically aligned text. The hack to address this would be having a custom font size for the icon, than the standard text, but that complicates things unnecessarily.

While the articles I read and reference may be outdated at this point, they still bring up relevant points about use, intention, and use cases about what's appropriate, and when to find an alternative.

Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
Read more

Pointer Cancellation: Real-World Examples

Image
 While reading through the Operable Principles, I admit that I was confused about the success criteria around pointer cancellation . The success criteria states, For functionality that can be operated using a single pointer, at least one of the following is true: No Down-Event: The down-event of the pointer is not used to execute any part of the function Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion Up Reversal: The up-event reverses any outcome of the preceding down-event Essential: Completing the function on the down-event is essential Some of my initial questions when reading this are: It mentions functionality using a single pointer, but what are the other options? Is there a double pointer? Do they mean that when they release the down-click the user is prompted to abort the action or undo?  Are they holding down a mouse button reading something tha...
Read more

Practice Site: Accessible Forms

Image
Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
Read more