feat: GAUD-10424 alt attribute d2l icon

[EdwinACL831]

jira

GAUD-10424

Description

Our d2l-icon component has some useful icons used on the LMS, like the tier1:dot which has one use on the content page to visually notify the user that there is a new message on a Discussion activity they are subscribed. Unfortunately for sighted impaired users, this is not enough. They rely on screen readers and the virtual navigation to get notified if needed, but screen readers are not able to interpret that icon because it is not accessible. This is not good since that icon actually accomplishes a purpose: Tell the user there is an update in the discussion (i.e., a new reply, a new post, etc.). Therefore screen readers should be able to interpret that icon as intended/designed.

This pr accomplishes that by combining the role="img" and aria-label="<image_description>" attributes.

The role is being set inside the fixSvg() function and the aria-label comes from the new alt attribute.

[github-actions]

Thanks for the PR! 🎉

We've deployed an automatic preview for this PR - you can see your changes here:

URL	https://live.d2l.dev/prs/BrightspaceUI/core/pr-7467/

Note

The build needs to finish before your changes are deployed.
Changes to the PR will automatically update the instance.

[dbatiste]

This is several years old, but possibly still relevant:
https://www.deque.com/blog/creating-accessible-svgs/

At the time, the a11y experience was varied to say the least.

Any chance you've seen this? If not, it would probably be good to review, and for us to do some x-browser, x--screen reader tests with this solution.

[dlockhart]

I'm not sure we want to do this. Whenever this request has come up in the past, we've always reluctantly recommended that they just go <d2l-icon role="img" aria-label="label here">. That turns it into a labelled image (or it should at least), but it's still not focusable or accessible to keyboard users, which is why we haven't documented this technique.

[dbatiste]

Yeah, icon-only isn't a good practice imo. Sighted users not using a screen reader are still at a loss trying to figure out what it means. But I know we use icons like this a lot, and so to me, really addressing the issue means much more.

[EdwinACL831]

Thanks to you, both Daves, for the feedback. I read the post (haven't seen it before @dbatiste ). We could try to implement a couple of the presented approaches and do the cross-browser testing as well.

Now regarding to the solution @dlockhart . explained, imho I think that since SVGs are being exposed through our d2l-icon component, seems that they should be accessible just right out-of-the-box and consumers should relay on it. Also, testing my changes locally, I was able to double check that adding the role + aria-label attributes do not make the icon to be focusable (using the tab). However, by using the virtual cursor (available when using a screen reader) I was able to reach those elements on the page, and listening how the screen reader announced them out loud.

But my 2 cents here are:

• I think d2l-icons should be accessible out of the box. Not the svg perse but the component that wraps it.
• Even though the icon is not focusable through tab, they are through the virtual cursor.

[dlockhart]

I think d2l-icons should be accessible out of the box

Just to clarify what I meant: thus far, we've only ever recommended using <d2l-icon> as a decorative component, not as an "image" that would require alt text. When using decoratively -- for example inside a button that already has a label -- it is accessible in that it can just be ignored.

Now having said that, there are definitely cases like the one behind this defect where <d2l-icon> is being used in a non-decorative context, as an image that should have alt text.

So the question we need to answer here is: do we want to build in support for <d2l-icon> to be something other than a decorative image? If we do this, we can't require an alt since for 99% of existing uses it's already decorative.

In retrospect, I wish we'd called this component <d2l-icon-decorative>. Then we could introduce <d2l-icon alt="text"> and make alt required.

[EdwinACL831]

I think d2l-icons should be accessible out of the box

Just to clarify what I meant: thus far, we've only ever recommended using <d2l-icon> as a decorative component, not as an "image" that would require alt text. When using decoratively -- for example inside a button that already has a label -- it is accessible in that it can just be ignored.

Now having said that, there are definitely cases like the one behind this defect where <d2l-icon> is being used in a non-decorative context, as an image that should have alt text.

So the question we need to answer here is: do we want to build in support for <d2l-icon> to be something other than a decorative image? If we do this, we can't require an alt since for 99% of existing uses it's already decorative.

In retrospect, I wish we'd called this component <d2l-icon-decorative>. Then we could introduce <d2l-icon alt="text"> and make alt required.

I understand better now, thanks for the clarification. And yes, if we want to be retro-compatible with the existing implementations/usages of our component, then alt should not be "mandatory". Therefore we can start making this more as optional and add those attributes in places where they make sense (if that also make sense). So I would change a little this implementation by adding the role attribute not while fixing the svg but just when the alt text is provided maybe?

That also would include to update our Daylight doc for d2l-icon to mention this new optional way of usage

[dbatiste]

So the question we need to answer here is: do we want to build in support for to be something other than a decorative image?

I think this is the key question. I might go out on a limb and suggest we always want these icons to be decorative for the reason I mentioned (sighted non-screen reader user unable to discern meaning of icon). Icons should never be used on their own to convey meaning. The meaning of some icons is fairly clear to me, many not-so. But that really depends on the user. I am sure there might be some edge cases where supporting alt text on icons might be helpful, but I also think it invites designers/developers to use them in this inaccessible way.