Accessibility Guidelines for Icons That Name a Control
Accessibility guidelines for an icon set are rules about the control, not a style pass on the drawing. An icon that looks sharp can still leave a button with no name, a target that is hard to hit, or a stroke that disappears on the background. This is a production note for interface icons. It is not a certification, a legal opinion, or a promise that a checklist replaces testing with the people who use the product.
Pair this with responsive icons and optimizing icons for web. The grid and the file size do not decide the accessible name.
Where accessibility guidelines start
Start with the control, not the SVG. If a button has a visible text label, the icon is often decorative and the label is the name. If the button is icon-only, the icon is the name, and the name has to exist in the markup where assistive technology can find it. A tooltip that appears on hover is not that name. Many people do not hover, and a tooltip is easy to miss.
The W3C’s understanding page for non-text content is the place to read how non-text content is supposed to have a text alternative, and when a decorative image is exempt. Read the current page. Do not copy a paraphrase from a slide into your component library and call it done.
Decorative means the icon adds no information the text does not already give. A trash can next to the word Delete can be hidden from the accessibility tree. A trash can alone on a button cannot. Write that distinction next to the component, because designers and engineers will disagree about it in the week before launch.
Name the control in the markup
Put the accessible name on the button or link, not only inside a title element buried in the SVG, unless you have tested that combination in the browser and screen reader you ship. A visible label is the most reliable name. If the label is visually hidden, it still has to be in the accessibility tree, and it has to match what the icon is understood to mean.
Do not use the file name as the name. “icon-24-trash-final” is not a name. “Delete” is. If the same icon means archive in one place and delete in another, you have two controls, and the drawing is not the problem. Accessibility guidelines cannot rescue a symbol that means two different actions.
If you inline the SVG, decide whether it is hidden as decorative or exposed as the alternative. Do both and the user hears the name twice. Do neither and the user hears nothing. One component, one decision, written in the component’s comment or documentation so the next person does not flip it.
Contrast and target size without invented numbers
A light icon on a light bar fails for a different reason than a missing name. The W3C understanding page for non-text contrast describes contrast for graphical objects that are necessary to understand the content. Open that page for the threshold that applies to your version of the guidelines. This article will not restate a ratio from memory. Ratios change in how people quote them, and a misquoted ratio is worse than a link.
Check the icon on the background the product uses, including a theme switch if you have one. A stroke that looks fine on a white artboard can vanish on a pale gray toolbar. Fix the color in the component. Do not “fix” it by adding a drop shadow that only shows up in the design file.
Target size is the size of the control, not the size of the drawing. The understanding page for target size minimum is where the current minimum and its exceptions are written. Read it before you argue about padding. You can keep the symbol small and still make the button large enough. Padding is allowed to do that work. Inflating the drawing until it fills a tiny hit area is how icons get blurry and controls stay hard to use.
How to apply accessibility guidelines while you draw
Draw the symbol so it still reads at the size the control uses. A symbol that only reads when it fills your screen will not read in a toolbar, and no text alternative fixes a symbol that sighted people also cannot recognize. Simplify the metaphor. A trash can does not need a lid, a pedal, and a liner.
Do not put essential information in color alone. A red icon and a green icon that share a shape will not communicate status to someone who does not see those colors as different. Add a label, or change the shape, or both. The icon can still be red. It cannot be the only signal.
Motion is optional. An icon that shakes to mean error is easy to miss and hard to tolerate. Keep a static state that carries the meaning, and leave animation off when the user prefers reduced motion. You do not need a second icon file for that. You need the component to render the still symbol.
Review with the name exposed
Review a row of icon buttons with the visible labels removed, and read the accessible name of each one. If you cannot tell what the control does from that name, the icon is not finished. If the name and the icon disagree, fix the name or the icon before you debate the stroke width.
WAI’s tutorial on decorative images is a useful companion when the team argues about alt text on icons that sit beside words. Use it to separate decorative from informative. Then test one screen in a screen reader, not only in an automated checker. A checker can tell you an image has no alternative. It cannot tell you the alternative is the wrong verb.
Keep a short exception list. A logo that must stay a specific shape may not meet the same simplification rule as a system icon. Write the exception on the component. Unlabeled exceptions become the new default, because people copy the file they see.
What not to add
A title attribute on a span does not finish the job. The SVG file name is not a name either. Shipping a font icon and hoping a private-use character is announced as a word fails when the font does not load: the user gets a blank or a missing glyph, not the word “settings.”
Pasting a contrast ratio into the design system from memory is the other trap. Link the understanding page and record the value you measured, with the colors you measured, in the component notes. Accessibility guidelines quoted incorrectly are how a set looks compliant and fails the first audit.
One control before the whole library
Tomorrow, take one icon-only button in the product. Confirm it has a name in the accessibility tree, confirm the control’s target is the thing you meant to size, and look at the icon on the real background. Fix that one control before you redraw the library. That is the practice.
When a new icon arrives from a set you did not draw, run the same three checks before it enters the library. A beautiful download can still be unlabeled, low contrast, and drawn with a stroke that disappears at the size you use. The download is a starting file. It is not an accessible control until the component says what it does.
Store the decision beside the component: decorative or named, the text of the name, and the background colors you checked. A decision that lives in a chat will not be there when someone swaps the icon. Accessibility guidelines only work if opening the component opens the rule too.
If two teams share the set, they share the naming rule. One team calling the same symbol “remove” and the other “archive” will ship two behaviors under one picture. Agree on the verb, write it down, and reject icons that arrive without one. The drawing can wait. The name cannot.
Review the same screen with keyboard only. If the icon button cannot be reached, focused, and activated from the keyboard, the drawing is irrelevant. Focus style belongs on the control, visible against the background, and it should not be removed because it “cluttered” a screenshot. Accessibility guidelines that stop at alt text miss the people who never use a pointer.
Keep the language of the name in the product’s language. An English verb on a screen that is otherwise translated is a failed name, even when the icon is universal. If you do not have the translation yet, do not invent one in the component. Leave the control out of the release until the name exists. A missing button is clearer than a button whose name is a guess.
After the three checks, look at one more thing: what happens when the icon file fails to load or the inline SVG is stripped by a sanitizer. The control should still have its text name. If the name lived only inside the SVG, sanitizing the SVG removed the name. Put the name on the button. Let the SVG be the picture.
