Add aria-label in addition to the alt prop

[brandonleboeuf]

Browsers usually display the <title> as a tool tip, but for a11y, shouldn't this also have the aria-labelledby aria-label?

MDN refrence: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title

[rektdeckard]

That's a good shout-out. We'll add this to the upcoming 2.0 release. Thanks @brandonleboeuf!

[rektdeckard]

Wait, it looks like this attribute is for use when the element is labeled by visible text, which is not the case with icons. Are you sure there is an accessibility concern? I am pretty sure the <title> element achieves the desired effect for screen readers.

[brandonleboeuf]

Good catch @rektdeckard ! I did mean aria-label, not aria-labelledby.

It is needed, as the icons are currently being skipped by the screen reader, even when there is something passed via the phosphor alt prop. As a work around, I have been adding a wrapper div with the aria-label around any phosphor icon that needs to be read by the screen reader.

From MDN on the title not being read by screen readers: "Text in a <title> element is not rendered as part of the graphic, but browsers usually display it as a tooltip. If an element can be described by visible text, it is recommended to reference that text with an aria-labelledby attribute rather than using the <title> element."

Though, looking at aria-labelledby, it does state to use aria-label instead if there is no visible text to reference, as you pointed out.

[rektdeckard]

Noted! Though, as our library docs mention, any and all valid SVG attributes you add to an icon will be applied to the rendered DOM node, so the real solution for you to just add that attribute to the icon yourself. Our title fix was specifically a convenience to address <svg> elements not respecting this attribute in the same way that HTML elements do, IE will not show a native tooltip on hover.

<House size={32} aria-label="An icon of a house" />

This will do you right. If you want both a tooltip and aria-label, add both, using alt for the title. Working example.

[brandonleboeuf]

Thank you!

I think having the alt prop makes it feel like an <img> rather than an<svg> element, which would also make me think that the alt text would be all that's needed vs adding the aria-label?

It would be nice to have aria-label? added to Props section of the readme.md so that it eliminates that confusion since the docs currently state that the alt prop will "add accessible alt text to an icon".

[rektdeckard]

This is good by me 👍

[benface]

I am a bit confused by the resolution here. What is the point of the alt prop if it's not to provide an accessible label to screen readers? 🤔 I feel pretty strongly that it should set aria-label on the <svg>, not a <title> (which is accessible in some browsers but not all, e.g. Safari based on my tests). Would you please reconsider @rektdeckard? 🙏 Happy to submit a PR.

[rektdeckard]

@benface honestly, I don't think we should have done the alt thing to begin with. I took the suggestion in #22 and the changes made in #23 to mean that this would be accessible to screen readers. And though I don't like to add needless shorthands for things that have a perfectly good idiomatic/native way to do it, I merged it anyway. It seems this was not a good assumption.

The issues I see with modifying it further to add an aria-label attribute is that:

1. You can already just add an aria-label to the icon as a regular prop, and this is what I'm arguing should be done
2. What happens if you have both an alt and aria-label prop? Which takes precedence? Do you expect them to merge or overwrite? (discussed similar thing in Icon instance className overwrites context className #83)

Shorthands for things that are already short are bad. The thing I'd consider doing is deprecating the alt prop altogether, and recommending using the native HTML approach.

[benface]

Ah, I understand @rektdeckard. Good idea to deprecate it then. (I would personally like if aria-label was required for icons, but I understand that's an unpopular opinion.)

[rektdeckard]

@benface I'll remove it from the IconProps type in the next minor version, but will probably keep the behavior around, just to safely deprecate.

Would like to educate myself a bit more on the accessibility best practices here, but it seems like there are definitely some cases where icons do not need to be labeled, such as when used for decorative purposes or made redundant by control/input/button labels. Not sure if I would want to force it.

[benface]

Yes @rektdeckard you are definitely right, but I prefer making it required so the developer is forced to think about it. And, if there is no need for a label, they can do alt="", like for img.