Buttons That Are Only an Icon

A header made of pictures

Look at the top of many small business sites on a phone: a logo, then a row of small pictures. A magnifying glass, a heart, a little person, a shopping bag, three lines.

The footer adds a row of social logos, and a speech bubble floats in the corner, waiting to open a chat.

To a sighted visitor who knows the conventions, most of these are clear enough. To a screen reader, which speaks the page aloud, many of them are nothing at all.

And plenty of sighted visitors know the conventions less well than designers assume.

What a screen reader hears

A screen reader announces each control by its role and its name: button, search; link, cart. The name comes from text in the code, not from the picture.

An icon drawn with an icon font, or an image with no description, leaves the control with no name. The visitor hears button, or link, or the address the link points to, read out character by character.

Move through a header of six such icons and the result is six near-identical announcements, with no way to tell search from the cart.

Icons that often arrive without names

• The magnifying glass that opens the search box.
• Three lines for the menu, especially on phones.
• The cart or bag, often with only a number beside it.
• Social logos, each one a link to a different site.
• The cross that closes a pop-up or a chat window.
• Arrows that move a slider or gallery along.

The fifth causes the most trouble. A pop-up whose close button has no name can leave a screen reader user stuck inside it, unable to find the way back to the page.

Sighted visitors guess too

Icons are less universal than they look. A heart might mean save, like or favourites; a star might mean the same, or a rating.

A speech bubble could be chat, comments or a contact form. The share symbol on an iPhone looks nothing like the one on an Android phone.

Visitors who use the web less often, and many older visitors, hesitate over icons designers read without thinking. On a phone, a thumb hovering in doubt is often where a visit ends.

What WCAG 2.1 asks for

WCAG 2.1, the latest version of the web's accessibility guidelines, expects every control to have a name software can read, and every image used as a link or button to have a text alternative describing its purpose.

It also asks that a visible label, where there is one, appears in the control's name. People using speech recognition click by saying what they see, and a button showing Search but named magnifier will not respond.

A requirement new in 2.1 covers contrast. Icons that identify a control need a contrast of at least three to one against their background, so pale grey icons on white fail.

Naming an icon properly

The name should describe what the control does, not what the picture shows: Search, not magnifying glass; Close, not cross; Our Instagram page, not camera.

The neatest way is real text inside the button, hidden visually but available to screen readers. Another is an aria-label, an attribute that gives the control a name in code.

The icon itself should then be marked as decorative, so the screen reader does not also try to read the icon font's character.

For icons that are images, the alt text carries the name. An image link with an empty alt is a link with no name.

A worked example

An independent record shop with an online store had a header of five icons: search, account, wishlist, cart, and a map pin for the shop's location.

A customer who is blind emailed to say she could not find the cart. Her screen reader announced the header as button, link, link, link two, link.

The icons came from an icon font, and the theme had never given them names. The footer's social links read out their web addresses, and the slider arrows said nothing at all.

Each control was given a name describing its job, and the icon characters were hidden from screen readers. The cart's name now includes the number of items in it.

Search and the cart also gained visible words beneath their icons, since those were the two the shop most needed people to find. The map pin became the shop's address, in text.

Tooltips are not labels

A common half-fix is a tooltip, the small label that appears when a mouse hovers over the icon.

Phones and tablets have no hover, so touch users never see it. Screen readers do not read it consistently, and keyboard users often cannot trigger it at all.

A tooltip can sit alongside a real name. It cannot replace one.

Testing it yourself

On an iPhone, turn on VoiceOver and swipe right through your header, one control at a time. Every announcement should tell you what the control does.

In Chrome on a computer, the Audits panel in the developer tools runs an accessibility check that flags buttons and links without a name.

Then move through the page with the Tab key and watch where the focus goes. An icon the keyboard cannot reach is a separate problem, and a common one.

The counter-case

Not every icon needs a visible word. A play button on a video, a cross on a pop-up and a cart with a count are understood widely enough to stand alone.

Space is real on a phone, and a header with six labels can be worse than one with icons. Visible words matter most for the main actions and the less familiar symbols.

What is never optional is the name in the code. A visitor who cannot see the icon depends on it entirely.

Name every icon by what it does, and put words beside the ones that matter most.

Checking your header

1. Swipe through your header with VoiceOver or TalkBack.
2. Run the accessibility audit in Chrome.
3. Name every icon by what it does.
4. Hide the icon characters from screen readers.
5. Add visible words to search, menu and cart.
6. Check icon contrast against the background.
7. Replace tooltips with real names.

Step one is the most persuasive five minutes on this list. Hearing your own header read aloud as a row of identical buttons explains the problem better than any guideline.

Another structure screen reader users rely on is covered in headings picked for how they look.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.