Set default aria-label or add <title> to SVG for accessibility

[StefanH-AT]

Package

• lucide
• lucide-angular
• lucide-flutter
• lucide-preact
• lucide-react
• lucide-react-native
• lucide-solid
• lucide-svelte
• lucide-vue
• lucide-vue-next
• Figma plugin
• all JS packages
• site

Description

This seems related to #477 but with different intentions

Lucide icons svgs don't seem to have a <title> tag and don't set an aria-label attribute. For accessibility, it's advised to label icons. While it's possible to label these manually, I don't think it would hurt to offer the option to set default labels for all icons using the icon's own name.

Example of what I currently have to do:

<LucideMailbox aria-label="Mailbox"/>

Of course, these labels would often have to be overridden anyway depending on the context. A chevron down icon shouldn't just be labelled "Chevron down", but describe what it means in context like "Keep scrolling icon" or "Dropdown icon"

But yeah I think setting the label to the icon name is a reasonable default. Simple Icons already does this using the <title> element inside the svg.

Use cases

Labelling icons helps with accessibility and improves screen reader support

Checklist

• I have searched the existing issues to make sure this bug has not already been reported.

[jguddas]

My first reaction is that that's not enough, but I guess bad alt text is better than no alt text at all.

[karsa-mistmere]

My first reaction is that that's not enough, but I guess bad alt text is better than no alt text at all.

Yeah, same reaction here, but I kind of disagree: bad accessible text is most definitely worse than no text at all. Icons should only ever have accessible text if that text is helpful, irreplaceable and not redundant. Decorative icons do not require an accessible label; just imagine buttons that screenreaders read out as "File archive two download ZIP archive" et cetera.

I feel like we should definitely add better a11y support but accessible text for icons is 100% something that people should be able to opt into rather than have to opt out of probably 99.9% of the time.

[StefanH-AT]

My thought was that it would be opt-in and disabled by default. Most devs don't care about accessibility anyway but for those that do, default labels could be a good starting point just so you don't have to constantly repeat "yes this home icon is the home icon"

[karsa-mistmere]

My thought was that it would be opt-in and disabled by default. Most devs don't care about accessibility anyway but for those that do, default labels could be a good starting point just so you don't have to constantly repeat "yes this home icon is the home icon"

Then again, home is currently incorrectly named, according to our naming guidelines it should be house.

"house" is what is depicted.

"home" is the use case.

"An icon depicting a house" would be an accessible label of the icon when standing alone as a decoration.

"Home" could be a further label when used as a non-labelled icon button.

Without additional context, we just don't know which of these labels would be correct, not to mention icons that have multiple use cases.

[ericfennis]

Hmm, interesting discussion.
It depends on what you will do with the icons. We really should write that accessibility guide on the docs site.
Icon buttons should have an aria-label describing the action, but a button with an icon in it is maybe not the correct accessible text if we add this by default to every icon.

For example, this "add to cart" button. A screen reader will read "Shopping Cart Plus Add to cart", which is in my opinion not ideal to hear.

Making this "opt-in" feels a bit like a feature that nobody will use, since describing it by yourself with an aria-label is a more obvious choice if you try to improve accessibility in your app.

But interesting discussion, I'm curious how an accessibility expert will look at this

[StefanH-AT]

Thought more about this and now that I'm localizing my page I realized that this issue is also in conflict with i18n as well. It think it's probably better to add labels manually as you have suggested. Simple icon's brand icons include default labels, but they're all brand names where the meaning doesn't change depending on context or language, so the use case is just different.

I think it wouldn't be a bad idea to encourage users to add labels to their icons in the docs