-
-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(docs): added accessibility guide #2122
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The content of the images is not accessible, the alt text is different from the content of the image. I would generally prefer if we moved the text out of the images and made them just normal text.
- Would be nice to have a section on flashing images and use reduce motion as well
- Also
aria-label
is not perfect, using something like RadixUIsAccessibleIcon
is something that we should point people to use instead. - A section on who this for and why you should do this would also be nice.
We can also point people to resources that they should reference, be it just the WCAG or even component libraries or guides like https://inclusive-components.design/toggle-button/ |
For the most part this is entirely intentional, these are illustrations, I've added accessible text where there was information otherwise missing, but most of these illustrations contain redundant information that is not useful to be read out as is. There's probably room for improvement, on that I can agree.
We don't really have ootb support for such animations, so I'm not entirely sure if it's relevant within the context of Lucide.
Well, the current guide does recommend not using it in places where it's problematic, but you're right, there probably space for some more nuance about this.
Is it not for everyone using Lucide? 🧌
Great idea, we should definitely add a "Further resources" section! |
Example: Your should give your icons enough contrast so people with visual impairments, be it physical or just them being outside in the glaring sun can still get the amazing benefit of looking at those cute icons. |
Tailwind based example: You can do |
Yeah, but this is entirely dependant on Tailwind, I think it should be their responsibility to educate people about using their animations responsibly. :) (To be frank, this should be their default, it shouldn't be something to opt into.) |
…rate on not using it.
docs/images/a11y/alttext-buttons.svg
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could even set aria-hidden="true"
on decorative icons like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did some actuall user research on this, having decortive images be read out as image
by your screen reader is apperently super annoying.
So 👍 for adding aria-hidden="true"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused, does this mean that simple SVGs with no accessible text are currently being read out? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh jeez louise, that's awful. 🤮
+1 for adding aria-hidden then. Best course of action would actually be to automatically add that no matter what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hiding the icon by default sounds super dangerous.
As I see it there are 2 okayish options:
- Add a default label that is a descriptive representation of the icon. Set default `aria-label` or add `<title>` to SVG for accessibility #2121
- Make setting a
label
/aria-hidden
attribute mandatory and well documented for when to use what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Add a default label that is a descriptive representation of the icon. Set default `aria-label` or add `<title>` to SVG for accessibility #2121
Terrible-terrible idea, as I've already explained in #2121:
- Accessible labels on functional icons should describe the use case, not the graphical representation (and even that isn't necessarily unambiguous, especially considering abstract icons).
- Decorative icons on the other hand should have no accessible label whatsoever.
- Make setting a label / aria-hidden attribute mandatory and well documented for when to use what.
Supporting any kind of accessible label would lead to breaking changes, since we cannot use either <title>
nor aria-label="..."
as already discussed in previous threads. That means we would have to add at least one extra element to the DOM and inject CSS where there previously were none (or use inline CSS for our visually-hidden
util).
Hiding the icon by default sounds super dangerous.
I don't really see why, it is practically never advisable to set an accessible label on an icon itself, but instead on other interactive elements, or using some kind of visually-hidden
/sr-only
util class, but that by nature will be on a different element as well.
closes #2121
What is the purpose of this pull request?
Before Submitting