Icon Font Text Alternatives: Don’t Forget Them

In a world where we need to support screens of all sizes and resolutions and be as future-friendly as possible, many a designer and developer have turned to icon fonts.

They’re awesome! And certainly come in handy, especially depending on what browsers you support and whether or not you can use SVGs. It’s important to remember when using them, you need to think about accessibility.

The Problem

I see icon fonts without text alternatives all the time in my accessibility testing. If you’re using an icon font for a purpose beyond just decoration, and it conveys content, you need a text alternative.


<ul>
    <li class="icon-twitter">
      <a href="http://twitter.com/myprofile" title="Twitter"></a>
    </li>
</ul>

Often, the li will have use :before and have some CSS attached to it displaying the icon font. Many designers and developers then rejoice as lovely icons look, well lovely, at any size on any screen.

But.

This is a link. It has no link text. We’ve essentially done what’s equal to putting an image inside of a link without an alternative text attribute.

  • The link uses only icon fonts inside the <a>, but icon fonts are not announced by screen readers.
  • The title attribute may be intended for screen readers, but it’s not announced by default by screen readers either, and it’s really only useful for users with a mouse. See this post for more info on the title attribute.
  • When a screen reader announces these links, it says: “Link”, which isn’t descriptive and doesn’t tell the user what the link does or where it goes.

Bummer. But wait!

The Solution

We can fix this, and easily.

  • Links should always have link text.
  • Adding a screen-reader-text class that would be hidden off-screen, maintains the design of having the icon only, but provides a text alternative.

The markup might look like this:


<ul>
    <li class="icon-twitter">
      <a href="http://twitter.com/myprofile">
        <span class="screen-reader-text">Follow me on Twitter</span></a>
    </li>
</ul>

Now, a screen reader user hears what that link is for and where it goes. It says: “Link: Follow me on Twitter.” They just might follow you on Twitter too!

It’s easy to forget small, but important details like this, but also easy to fix.

Other Helpful Blog Posts

A Workflow for Testing Web Accessibility with Free Tools

Learning how to test for web accessibility can be overwhelming, even for the most experienced web worker. However, if you approach the testing bit by bit throughout the creation of your project, it becomes  more manageable.

Plus, since you’ll be attacking accessibility from the beginning, you’re naturally planning for it. That means you have a much better opportunity to create a website or web application for everyone, rather than one that frustrates some users, causes matainence problems for you or your team and potentially puts you at risk legally.

Introduction

In this post, inspired by my talk at the Code(Her) Conference, I’ll lay out a simple workflow for testing your website or web application for accessibility with free tools while building it. The worflow isn’t a secret or anything groundbreaking. The W3C recommends much of it already, but I add a step or two, talk about order and importance of each step.

I’ve created a simple website – a11y.me that has all of the resources I mention here, plus many more. Use it, and feel free to suggest new tools by opening an issue on Github.

Before we dive into a testing workflow, you should be familiar with the Web Content Accessibility Guidelines 2.0. These guide much of the workflow, especially the broad principles that form the guidelines. It might also be helpful to know how people with disabilities use the web.

Thinking about accessibility early on in your design process can pay off in a big way. WebAIM has a simple, informative infographic geared toward designers. It touches on many important principles of an accessible website or application.

This workflow won’t cover everything you would need to do for a thorough accessibility audit, but it will expose you to some of the more important things to check for when it comes to web accessibility. Hopefully, once you develop a ryhthm, you can do all these checks in 30 minutes or less. However, ideally you’re doing a handful of them as you design or build new interfaces.

Automate, Automate, Automate

Let a few robots do some of the work for you. I like to start out using three automated tools that can help identify large trouble spots that you may need to focus on as you move forward in your project.

First, I run the HTML and CSS of a page through the W3C validators.

You’ll want to look for any obvious errors. Sometimes, malformed HTML and CSS can lead to accessibility issues. You may not be able to have perfectly validated code and that’s okay, but make sure any errors aren’t causing issues elsewhere.

Next, I like to use two accessibility testing tools that can spot problems in your code. The first is an extension created by Google for Chrome called Accessibility Developer Tools. From the description:

This extension will add an Accessibility audit, and an Accessibility sidebar pane in the Elements tab, to your Chrome Developer Tools.

To use the audit: go to the Audits tab, select the Accessibility audit, and click Run. The audit results will appear as a list of rules which are violated by the page (if any), with one or more elements on the page shown as a result for each rule.

This tool outputs text in the Audits tab of the Chrome Developer Tools. It’s fairly accurate and a great way to see potential accessibility barriers. You can use the results to take a deeper dive into problems later in your testing.

Next on our automation tour, I like to use Wave. The web version takes a URL, processes it and gives you all kinds of data on your site page or application. Much like the Accessibility Developer Tools for Chrome, this can help you get a broad picture of where your problems lie. Some find it more helpful because it includes visual icons and represents accessibility features like WAI-ARIA roles nicely.

Careful though, the web version does not process JavaScript. If you need that, you can use Wave’s equally awesome toolbar add-on for Firefox.

Next, we dive into some of these details. It’s important to mention that from here on out, the order in which you do these isn’t imprtant. I like to run the automated checks first for help with the big picture and run the page through a screen reader last to help conform things. However, the items in between can be moved around. Maybe you’re only performing one or two at a time while you work on a specific component. That works too!

We All Like Titles

Now that we have a good overview of what’s happening on our page, we can do one of the easiest checks of all. Look at the page title. You can find them in the title tag in the head element. They’re used by screen readers, search engines, browsers and other technology on the web. A good page title provides an overview of what the page is about and gives context to users.

ALT Rock

All images need an alt attribute so screen readers and other assistive technology can describe them. The Wave tool works perfectly for seeing which images have one, what it says and which ones lack it. Alternative text can vary widely from image to image on a site, all depending upon the context of the content around it. WebAIM’s alternative text article explains everything well.

Heads Up

Making sure a page has headings is another easy thing to check. You can use the Wave tool for this. It allows you to see a page’s structure without page styles. At the mininium, a page should have at least one headings and it/they should be marked up like a heading. Example:
<h1>My Heading</h1>

Color Me Bad

Finding the perfect color combinations that are both accessible and harmonize with a design vision can be challenging. However, if you think about accessibility early, stay flexible and experiment, it can done. My three favorite colors tools all come out of the same place: North Carolina State University’s Accessibility Department.

  • For creating an accessible color palette, check out the Color Palette Accessibility Builder. You can enter colors by their hex code values and determine if the color comibinations (background and foreground) meet WCAG guidelines.
  • For pulling colors from an existing web page or application for analysis in the Color Palette Accessibility Builder, check out the Color Extractor.
  • For analyzing the color combinations on a full web page or parts of a web page, you’ll want to check out the Color Contrast Analyzer for Chrome. It does two things that many other color analysis tools do not: You can check text over top of background images or gradients, analyze text in images.

Each of these tools has unique strengths, depending on which part of the design process you’re in. Matthieu Faure created my other favorite color tool, called the Tanaguru Contrast-Finder. With this tool, you can insert a hex value for a color, and if it does not meet WCAG standards, it will suggest other colors. Perfect when you need a bit of accessible inspiration!

Can You Make It Bigger?

For this next check, you don’t actually need any special tools. It’s always a good idea to increase the size of your text by at least one and half times to check if your text can be resized and whether or not your design breaks down.

Some users need to change text size and other aspects of text display: font, space between lines, and more.

WebAIM says:

For development purposes, it is best to use relative units (such as percents or ems) to specify font sizes rather than absolute units (such as pixels or points). This provides much flexibility in modifying the visual presentation using CSS. For accessibility, because modern browsers adequately resize text regardless of how the size has been defined, it is not vital that text sizes be defined in relative sizes.

This is solid advice, but if you use relative font sizes, you’ll respect a user’s preferences and your adjustments will be easier within responsive design.

Look Ma, No Mouse

I love looking at a site or application’s keyboard navigability and visual focus. Often, it’s the one thing I do if I don’t have time to do any other testing. Like the last test, you don’t need any special tools.

Test this in Chrome since you do not have to enable any special options for it to work. Simple open a web page and press the tab key. You should be moving forward through the page. Pressing the shift key plus tab moves you backward.

Label Me, Please

Lack of form labels represent one of the most common accessibility errors I see in my own accessibility testing. Fortunately, it’s one of the easiest ones to fix.

The Wave Tool helps you spot missing or unassociated form labels quickly. Use the same methods for keyboard testing here and make sure you can reach each form label and button, and activate them.

Multimedia, Really

No special tools required here either!

Look at your site or application to see if you’re using any kind of multimedia (audio or video) content. If you have it, does:

  • it have controls that are keyboard accessible?
  • it have transcripts or some sort?
  • it contain captions?

Basics, Basics, Basics

This next check gives you a 50,000-foot view of your page or application. Grab one of the Developer Extensions and get to destructing.

You’ll want to turn off CSS, images and make the page as linear as possible. Look for any missing pieces of the page.

You Talking to Me

Lastly, I run the page or chunks of the page through a screen reader. I typically use VoiceOver, but other options exist. Using a screen reader is an aquired skill. Be patient. WebAIM has articles on evaluating web accessibility in many of the major screen readers. Much like the “Structure” check, I look for missing pieces or items that deserve more attention.

And Onward

Hopefully, this helps you not only see a possible workflow, but a handful of tools to get it accomplished. Now, go make the web more accessible. And remember, ship code that’s closer to better than before than absolutely perfect.

Video

Now is the Perfect Time

I love this talk by David Berman on the current state of making things accessible and how it can lead to breakthroughs. Some quotes I like:

It all starts off with designing for extremes. The key here is when we design for the extremes, everyone benefits. … We live in a time right now where it’s never been easier to make everything accessible to everyone.

Joining Automattic

I’m thrilled to announce that I’m joining the Automattic family soon as a Theme Wrangler.

For those that don’t know, Automattic runs WordPress.com, Jetpack, Simplenote, Cloudup and other awesome web products. Woohoo! (I keep asking my wife if it really happened. She assures me it did.) :) It’s hard to put into words what this means to me, but I’ll try. It’s my dream job, yes, but it goes beyond that.

I’ve been lucky enough to work for and inside some organizations with fantastic missions. I don’t get excited unless I’m attacking big problems with a chance to drive change. From being a newspaper reporter, to working for a one of the oldest disability organizations in the United States to working with one of the United States government’s most watched and most admired “start-up” agencies, a lot of my work has been for a “greater good.” At least I hope so. :) At Automattic, I get to combine a lot of the passions I’ve developed along the way: publishing, WordPress, web standards and accessibility, and open source and the open web. All for a greater good: making the web a better place.

But how can someone who builds and cares for WordPress themes do that? I wanted to be a Theme Wrangler because I believe that a good WordPress theme can open up a new world to those using it, and in turn, reveal something unique about the site’s owner to the world. A theme can become the centerpiece to someone’s story. That’s something I want to do for as many people as possible. I look forward to whatever form that takes, including helping themes evolve in new ways and bringing my accessibility experience to my every day work on WordPress.com.

The best is yet to come.

Quote

The Personal Blog

Fred Wilson on the personal blog:

There is something about the personal blog, yourname.com, where you control everything and get to do whatever the hell pleases you. There is something about linking to one of those blogs and then saying something. It’s like having a conversation in public with each other. This is how blogging was in the early days. And this is how blogging is today, if you want it to be.

Quote

Feature Misuse

Karl Groves in a post about HTML5, Longdesc and accessibility:

For nearly a dozen years now, I’ve been employed in a capacity which gives me a day-to-day glimpse of how professional web developers are using markup. I see HTML abuse on a daily basis. Bad HTML permeates the web due to ignorant developers and is exacerbated by shitty UI frameworks and terrible “tutorials” by popular bloggers. In my years as an accessibility consultant I’ve reviewed work on Fortune 100 websites and many of the Alexa top 1000. I’ve reviewed web-based applications of the largest software companies in the world. The abuse of markup is ubiquitous.

You should read the whole thing.

IndieWeb Member

I’ve tinkered with my site a lot over the past weekend to make it more IndieWeb-friendly.

What does that mean? You can learn more about the IndieWeb movement on the site and read about its principles. Basically, you want:

  • Your content to be yours
  • To be better connected to all services
  • To  control how things work

These are novel concepts only because we’ve grown use to social networks and tech giants running the web. It doesn’t have to be this way.

I’ve tackled a number of things on the Getting Started page of IndieWeb Camp. I:

  • Joined the IRC channel.
  • Already had a personal domain and hosting. :)
  • Set up web sign-in.
  • Already had WordPress ready to go for content publishing. :)
  • Installed a link shortener plugin.
  • Started: Publish (on your) Own Site, Syndicate Elsewhere and automating it with IFTTT.
  • Already had a WordPress theme that supported basic Microformats.
  • Ported some photos from a photo blog to my own site.
  • Set up webmentions and semantic-linkbacks via the IndieWeb plugin. I’m pulling in mentions from Facebook, Twitter and Google Plus thanks to Brid.gy.
  • Cleaned things up a bit by removing custom post types on the site, adding a new favicon and fixing a few bugs.

The WordPress page was a great place to start.

Doing this wasn’t that hard, especially after listening to a recent talk on the IndieWeb by Tantek Çelik. I don’t know yet if I’ll keep all this going as some of it may not suit my needs. This may just be an experiment, however, I do know one thing: I’m going to keep publishing on my own site.