In part 1 of design system accessibility I discussed the topic of colors. Part 2 focuses on another really important aspect: Icons.

Icons are a major part of any modern interface. They are functional and add a pleasing visual at the same time.

If designed well, they are easy and quick to recognise and understand. They also need little space compared to text buttons.

Often you don’t need to translate icons and they bring the brand even into very minimal products.

If you are building or working on a design system, chances are you include an icon set or at least some icons. So let’s find out how to make sure your icons are accessible for all users and across all devices.

Functional vs. decorative icons

Functional icons have an important function and thus need to be accessible. Purely decorative (presentational) icons don’t add anything apart from an aesthetic touch. They are not needed for navigation and don’T have to fulfil accessibility requirements.

Functional

The following types of icons are functional:

• stand-alone icons that are interactive, for example an x to close a dialog
• icons that are combined with a label, e.g. on a button or in a form field
• icons that are used instead of label, e.g. for social media links in your profile settings
• generally all interactive icons are functional

Decorative

These types of icons are decorative:

• icons that are purely visual and not part of the content
• icons indicating the type of content that follows. But only if it is apparent without the icon as well. For example removing a date icon next to a date string can be considered decorative. The formatting of the string should be enough to indicate that it is a date.
• icons that are next to an interactive label but not themselves interactive. But only if the label makes clear what it can be used for by itself, e.g. a pen next to an edit link.

Color

Color is one of the most important aspects of visual accessibility and this is also true for icons.

Functional icons must have at least a 3:1 contrast ratio with the background (wacg¹). This is to assure they are easy enough to see. Icons that are purely decorative don’t need to fulfil any requirements (wacg²).

For interactive icons make sure that color is not the only indicator to show what action is performed.

Size is another important aspect. Make sure to consider all platforms your icon will be seen on. A TV has different size requirements than a mobile phone.

Touch devices need bigger icons as touch targets compared to mouse-controlled interfaces.

Sometimes the size of your icons is too small, but you can’t change it. One example is an icon set with only one size, that you use for interactive and non-interactive icons. In this case a good trick is to add invisible space (padding) around the icon, to increase the touch target.

But be aware that your UI may still feel unpleasant to your users, because it appears to be hard to hit the small icon. This negatively affects perceived usability, even though the touch target is big enough.

44x44 px/dp/pt is the minimum recommended size for pointer inputs or touch targets (wcag³). This makes it easy to interact with the target using a mouse or your finger. Size is especially important for users with reduced motor skills, like those who suffer from Arthritis or Parkinson’s disease.

Besides the icon size itself, also consider the size of the space between icons or interactive elements.

Shape

Complexity

You should favour simple shapes over complex ones. This makes your icons more robust and in most cases easier to understand. The hard part is to find the right balance between too little and too much detail. A helpful tip is to remove details and ask users what the icon shows. If they can still recognise it, you can remove the details. Some icons may need a small amount of unnecessary details to fit in with the icon set. If those are just a few cases, it should be no problem.

Large icons profit from complexity, small icons should be simple.

Large icons

If you use icons in sizes of 100px or more they should be categorised as illustrations. Large icons often profit from more details, depending on your brands illustration style. Sometimes icons look out of place when they are lacking detail at a large size.

Line thickness & gaps

The right line thickness is crucial, for outlined icons or small details. Lines that are too thin, lead to visual issues on low-resolution devices. They may also be problematic for people with visual impairments like cataracts. Luckily there are a few easy things you can do.

Avoid hairlines & small gaps in cons

Avoid hairlines
Very thin lines (smaller than 1px mostly at 1x resolution) can visually disappear. They either turn into a light grey smudge or merge with other elements into a big blob.

Avoid small gaps
For the very same reason, it is best to avoid small gaps. They often clot together and are hard to make our. This is similar to letters without ink traps in the printing days.

Test your icons on black and white
It is important to test icons in black on white and in white on black to spot issues. Lines may appear different if the background or foreground has the stronger luminance. This may make icons hard to recognise. This issue is especially problematic for users with cloudy vision.

Preview icons at different sizes and resolutions
Icons look different at in smaller or larger sizes and resolutions. You must test every icon at every size it will be used in. This lets you spot details clotting or disappearing especially at smaller sizes.

To verify that your icon works across all resolutions it is often enough to pick the extremes. If it performs well at 1x and 4x you should be all set. If 1x is a problem, you need to increase the resolution until the icon works. Now you know that you need to create a custom version for lower resolutions or adjust the icon overall.

Personally, I never saw an icon that did not work at 2x or larger. Most problems arise at 1x.

Don’t let your high-resolution mac and iPhone mislead you! Many offices users have 1x displays. Also ATMs, ticket machines and industrial interfaces use 1x and will do so for the foreseeable future.

Line thickness across icon sizes
Line thickness must be checked and possibly adjusted across different icon sizes.

If you use icons in 16px, 20px and 24px in the same interface you should consider redrawing the icons for each size. If you scale the icons, the lines will be thinner in the 16px icon compared to the 24px icon. This seems fine if you look at one icon in isolation, but not if you see together in the UI.

States

On / off

The most simple state changes between enabled and disabled, on and off. For example the items in a mobile bottom bar, or a favourite icon are typical cases for an on/off state.

The standard way to visualise this is by using switching from an outlined icon (off) to a filled one (on).

Spotify⁴ recently worked out one of the harder problems of this approach: the search icon.

Outlined and filled icons makes differentiating on / off states easy. Not relying on color/luminance changes, avoids problems for visually impaired users.

Note: If your brand restricts you to only filled or outlined icons there are other solutions. For example adding a background shape, or an indicator, like a dot or line, below the active icon.

Complex states

Even when there are only two options, sometimes the state change is not capture well in a boolean (on/off) change. In this case it makes sense to use a different icon for each state.

Placing the icons for all states into the same shape, like a circle, helps to visually tie them together.

A common example is a todo-list. An empty square indicates an “open” item and a square with a checkmark a completed item.

Sometimes you can also use an icon as an indicator only. The user can change the state somewhere else, e.g. in a context menu. An example is a stat that indicates a favourited item.

Pressed / processing state

If actions may take a moment, e.g. when waiting for a server response a pressed or processing state is important. Without any feedback users don’t know if they successfully pressed the icon or missed it. This is especially important if you don’t use an optimistic UI approach⁵.

You can either add a background shape that indicates the user has pressed an icon or you replace it with a spinner.

The most important criteria when designing or choosing an icon, is if it will be easy to understand. There are to parts to this question:

1. Is it easy to understand what the icon depicts?
2. Is it easy to understand what action or state the icon stands for in your interface?

Whenever possible you should use icons that are commonly use for the same purpose. This will make it easy for your users to understand your interface according to Jakob’s Law⁶.

When choosing icons, make sure to get a good understanding of your target audience. A users age, tech affinity, etc. may impact which icons they understand. For non-tech people a “network icon” may be hard to understand so a world or even better www. is a better icon for a website.

Many young people may know the “save” icon, but fewer and fewer know what it depicts, which makes it less ideal.

Internationalisation

One of the benefits of icons is of course, that they do not need to be translated. However, this is not true for all icons. You should test your icons to make sure that they perform well, at least for people in your major markets.

Ethical considerations

This is not an accessibility issue. But it is still important to make sure your icons are inclusive and ethically acceptable.

Gender representation
When using “users” icons (e.g. for a profile), make sure to use gender-neutral icons or have multi-gender icons (e.g. two people).

Often you can resolve this differently, e.g. by using a pictures or initials for the profile. Or by allowing users to choose an avatar or icon from predefined options.

Context
The context in which an icon is used may be important as well. When dealing with people or animals using a trash icon to remove them from a list feels wrong. You are not trashing a person, you remove them from your list. Only use a trash icon to permanently delete something non-living.

The like button is another example. Most social networks replaced it with one that allows you to choose from different reactions⁷. This way you can show your support for sad, or negative posts without “liking” it.

Icons & text labels

It is always a good idea to add a label to your icons. While this does mean you need to translate them, it also makes actions more clear. The icon is still helpful to guide the users attention. It also makes the interface easier to scan and remember the position of actions. We are visual creatures after all.

A few icons profit less from text labels than the rest. This includes the “back arrow”, the “more dots” or the “chevron” used to emphasise clickable list items.

For other icons it is essential to add labels as their meaning depends on the context / app. For example the “person” icon could mean different things in different apps.

The iOS phone app used the person icon for your contact while instagram used it for your profile.

Consistency

Consistency is important to make your UI predictable and easy to learn. Icons should be consistent in style and the concept they visualise.

Style

Let’s assume in your menu, outlined icons are your defaults and filled ones are used for the active state. This should be an overall rule. Whenever you use an inactive or stateless icon, it should be outlined. This allows user to learn how the UI works and makes it predictable.

Concept

Using the same icon for the same concept and only for this one concept is important as well.

When you use a “person” icon for profile, you can’t also use it for friends. Similarly using an iOS share icon on one screen, and an android version on another will confuse your users.

Input specific requirements

Mouse navigation

For mouse-controlled interfaces interactive icons need to fulfil the following requirements:

A hover state
To assure that users notice that the icon is clickable, every icon must have a hover state.

Minimum size
Interactive icons, also for desktop, must have a target size of at least 24px * 24px (wcag⁸).

If your icon is smaller, adding padding (empty space) around it, that is clickable is a valid option. You can do this by adding the space to the icon itself, or by adding it via code. This increases the interactive target without affecting the visual size.

Keyboard navigation

For keyboard users there are two extra requirements:

Enable user focus
You must make sure that any stand-alone interactive icon, can receive focus. This can be achieve by adding tabIndex=”0”.

Only add a tab index to interactive elements that don’t automatically receive focus. Also never use a tabIndex greater than zero⁹.

Add a focus outline
Any interactive item must get an outline so keyboard users know which item is focused. If you are using stand-alone icons you probably need to manually add a focus outline.

You can achieve this with the :focus pseudo-class and the CSS outline property.

Focus is a complex topic and I will not go into details here. If you want to learn the specifics of implementing it, I can recommend Sara Soueidan’s article¹⁰.

Touch screens

When using icons on touch screens, size is the main thing to consider. On mobile sizes of 44px44px or 48px48px are traditionally recommended.

For newer devices standards are not quite so readily available, so you need to do some research. Apple for has recommendations for button sizes on watchOS¹¹ that may be helpful.

TV & remote-controlled devices

For TVs and other remote controlled devices size and focus are the aspects to keep in mind.

Size
Normally the viewing distance for remote controlled devices is quite large. This means you need to increase the size of your icons. While this may be counteracted by a lower resolution, it can give you the chance to add more details. However you have to test this on your target devices.

Focus
On remote controlled devices, showing focus is the most important thing. Due to the nature of the input, the user is very disconnected to the focus position. The only way to know where the focus is, is through visual clues. This makes a visual focus indicator as important as for keyboard only navigation. The only difference is that on remote controlled devices all users need this focus. So make sure your interactive icons have a good focus state.

Technical implementation

Implementing accessible icons is a huge topic. I will only cover the most important aspects in this article. Refer to Sara Soueidans excellent article on accessible icon buttons¹² if you want to know more.

Format

Raster images (pngs, jpgs, webp)
The problem with raster images is, that they don’t scale with the screen resolution. This means you get blurry icons on high resolution devices. To avoid this you must provide icons in 2x or 3x. This solves the issue, but results in bigger file sizes with a negative impact on performance.

On the plus side, if you display the icons using an img tag you get the alt attribute. This allows you to provide an alternative text for screen readers.

If you use your icon in combination with a text label, you should set alt=”” so that the label is not read out twice.

When using icons as css background, you need to provide a label via the aria-label attribute. This is only necessary if you don't have a text label.

SVG icons
You can load Svgs into your product in different ways: Using an img tag, as a css background or with an svg tag.

If you use any of the first two options, the aspects mentioned in the raster image section apply as well.

If you use an svg tag there are a few different things to consider¹³.

1. Set role=”img” on the svg
2. add a title tag within the svg.

<svg role="img">
  <title>Good Label</title>
   ...
</svg>

The more common case is to add a text label to the svg, or add an aria-label attribute to the parent element (e.g. a link element). In this case you must add the aria-hidden=”true” label to your svg.

<a href="/" aria-label="Good Label">
  <svg aria-hidden="true" ... ></svg>
</a>

Icon fonts
While icon fonts are not as popular as they used to be, they are still common. Fontawesome, the most popular icon font, is still in active development. It also has great docs on accessibility for icon fonts¹⁴.

Icon font icons are typically applied by using a class which will add the icon to a pseudo-element. It is recommended to use a span tag as the container, since it has no semantic meaning. This means you will have to take care of the accessibility aspects yourself.

The parent element, span in our case, must have a role=”img” attribute as well as an aria-label.

As before, if your icon is part of an interactive element, like a link or button it is different. In this case use a span without a role or aria-label attribute. If needed, those attributes must be placed on the parent element.

Sprites
A sprite is an image that combines multiple icons into one file. The most typical sprite formats are png sprites (raster) and svg sprites. Just like with icon fonts you need a parent container, typically a span. If use a link, button, etc. you can with an icon you can skip the span element. Over at css-tricks¹⁵ you can learn more about sprites in general.

If used within a link, button, etc., the accessibility aspects should be addressed already. If your icon gets falsely read out by the screen reader, adding an aria-hidden label will solve it.

Svg sprites¹⁶ are a little bit more complicated.

In the sprite svg file some suggest to add a title and a desc to every icon within the symbol tag. But it seems to be rather unreliable so using a label when using the icon gets you better results. There is an interesting discussion on this gist¹⁷, if you want to dive in deeper.

<symbol id="warning">
    <path .../>
</symbol>

When using decorative svg sprite icons you only need the presentation role.

<svg role="presentation">
    <use xlink:href="sprite.svg#email"/>
</svg>

Functional icons within interactive elements just need an aria-hidden attribute. If the icon itself is interactive, you need to:

1. add role="img" to the svg tag
2. add an aria-label property to the svg tag
3. add a title attribute the the svg tag

<svg role="img" title="warning" aria-label="warning">
  <use xlink:href="sprite.svg#warning"/>
</svg>

Functional vs. decorative accessibility requirements

The requirements for functional and decorative icons differ greatly. This is because functional icons have an important function in the UI. Decorative icons in contrast can be omitted without effecting the content.

Functional icons

Functional icons must fulfil all the requirements mentioned above. They are integral parts of the interface like a button or link.

When a functional icon is in focused you must assure that an alternative text (aria-label) is read out. This text should describes the action that the icon performs.

Icons nested within interactive elements like buttons or links, must be hidden from screen readers. This prevents the screen reader from reading the action or label twice. To achieve this the nested icons needs an aria-hidden label.

Decorative icons

While it’s great if decorative icons fulfil accessibility requirements, it’s not required¹⁸. This is because decorative icons have no impact on the usability or understandability of the content.

But you assure that screen readers and keyboard navigation ignores decorative icons. You achieve this with an aria-hidden attribute. The icons must also not be focusable which you achieve by adding a tabIndex=”-1” attribute.