Aria-label for links

[lexkom]

Add editable aria-label field for links and buttons.

I think, it should be like "rel" field in the link settings.

[talldan]

I think the idea is that you shouldn't need an aria-label if the text in the button/link is clear, but I've added the Needs Accessibility Feedback label for more information on this.

[lexkom]

Yes, when link has text that exactly described it, aria-label isn't needed, but if it is a button with text like "Learn more" - aria-label required. Thank you

[alexstine]

The accessibility team has decided on the Friday accessibility team meeting that this may not be the best solution. Our recommendation is to close this issue out and maybe head in the direction of #22332. Slack archives link: https://wordpress.slack.com/archives/C02RP4X03/p1598023411125200.

Thanks.

[asafm7]

@alexstine did the team take buttons with only an icon (inline image) into account?

[alexstine]

@asafm7 I think aria-label would be better than nothing on buttons/links with only icons but there also should never be an option in Gutenberg to have icons in link/button text only. This is really not accessible unless the meaning of the icon is very clear. For example, if you had aria-label="Follow Us on Facebook" with a Facebook icon, one could likely guess the accessible name using a voice dictation program. Icons mean different things to different people which is why text should be used but it's a fight accessibility professionals will never win against sighted designers.

CC @afercia for his thoughts on this subject.

Thanks.

[asafm7]

Thanks @alexstine I understand what you are saying, but the web is dynamic, and sometimes icons help. In some cases, icons can even be better and more understandable than text (icons, for example, are less language-dependent, and this sense might even be more accessible than text). When icons are used, it would be good to be able to make them accessible.

In my case, I use the Buttons block inside a Navigation block, for some of the navigation links - mostly to save space. I place inline images (icons) inside buttons, for example for a wishlist page and home page links. In the absence of other accessibility options, I add text below the icons and set the font size to 0. I don't feel like it's a solid solution.

[alexstine]

@asafm7 Can you explain what you mean? Are you saying instead of "Add to wish list" you just have an icon? I would argue that icons are extremely subjective as it's an issue we've faced in Gutenberg back-end. I would assume most people would associate a "heart" icon as a favorite action but I think it's a crazy argument to make that icons could make more sense then text.

The problem with using aria-label is for people who use voice commands, it's hard for them to know what the accessible name might be based off what the icon is. For example, it could be "Share on Facebook" or "Follow-us on Facebook" depending on the context. Icons do not provide context.

One of my classic annoyances is when developers think this is okay for submenu triggers. If you were using voice commands, would you know to speak "About submenu" just because there was a ⬇️ icon present? If for some reason, the accessible name was only "About" and the submenu had aria-expanded="false" aria-haspopup="menu", they may not be able to open the submenu if the top-level link also had the accessible name of "About". In that case, it would likely activate the first occurance of the link which would be the link and not the trigger to open the submenu.

Playing devil's advocate, most modern browsers can translate pages today. I'm not saying that's perfect by any means but at the same time, you can't find one browser out there that dynamically fixes accessibility problems. Even if you could, accessibility is a guess for AI, language translation is language translation, based in fact. Language translation in this point in time is easier. I hate to split hairs on inclusion but I think the argument for accessibility in this point in time is still a little stronger.

My disability makes me quite bias though, we'll see if others wish to chime in.

Thanks.

[asafm7]

Thanks @alexstine

In this case, I was referring to a navigation link to a wishlist page. You can check it here:
https://hobbies4.life/
The wishlist and home menu items are icons. Please let me know what you think.
Regarding:

I think it's a crazy argument to make that icons could make more sense than text

In some cases, I don't think it is such a crazy argument. Icons, and symbolism, can be a powerful and efficient way to communicate. As I mentioned before, one advantage is icons not being language-dependent. Also, in some cases, icons might communicate a message faster than text. Road signs make use of these two facts. (after all, letters are symbols. In some languages, you can easily trace the symbolic origin of a letter being an "eye" or a "bull").

Of course, icons are not bulletproof, but neither is written text. And anyway, one needs to be able to see the icon, and see it clearly, to make use of it.

Not everyone can, and that's what we are trying to help with.

If I understand you correctly, you say that icons should never be used for communication. For this reason, we shouldn't provide means of making icons accessible. Maybe even hoping that without the means for accessibility, people will be discouraged from using icons. But in many cases, people will keep using icons (sometimes for good reasons). As you said, it is a fight that can never be won. I believe that not giving people the means of making icons accessible might hurt the accessibility cause rather than help it. Let me know if I misunderstood you or missed anything.

How well people communicate is up to them. But we can at least give them the tools to do so.

In my case, I believe that adding a "wishlist" aria-label to an icon navigation link (inside a <nav> tag) can be helpful. Let me know what you think.

Actually, in this case, besides an aria-label, a "title" HTML attribute can help remove possible uncertainties for people without seeing disabilities by hovering over the icon, and without having to click it. This makes me think that maybe a more robust solution will be the ability to add any custom HTML attributes (Elementor has such a feature).

I'm not sure I followed your submenu example as it is quite late for me. But I will return to it tomorrow, as it is important for me to understand. Submenus can be quite ambiguous and confusing for people without disabilities as well. I remember reading this article a while ago:
https://css-tricks.com/in-praise-of-the-unambiguous-click-menu/

[joedolson]

We shouldn't add an aria-label on a link that contains an icon, because the label belongs on the icon; an icon-only control absolutely needs a label, but that label shouldn't be the link, it should be the icon itself.

And, overall, it's better to use screen-reader accessible hidden text in a case like this, as it will provide a label even if CSS fails to load. That's a rare case, but it's not impossible.

@asafm7 What is your mechanism for adding icons to links that doesn't allow you to provide them with an accessible name of their own?

[asafm7]

Thanks, @joedolson.

The mechanism is an Inline image inside a Button block (inside a Navigation block).