Well-scoped and seems reasonable. @JScherer-WMF would you be able to weigh in on whether you think we should do this?

In T329534#9823494, @SToyofuku-WMF wrote:

Well-scoped and seems reasonable. @JScherer-WMF would you be able to weigh in on whether you think we should do this?

We should do it. Curious if this also impacts screen reader a11y experiences and keyboard navigation experiences. If so, I would recommend higher priority. Next steps would be to write the relevant label copy based on the list above. Shouldn't take much work from my end, so I'll pop this ticket into the incoming column so we can prioritize it and triage effectively.

@bwang @KSarabia-WMF I know we have aria-labels for most of this - any reason we don't have title as well?

@Jdlrobson
Looking at Technique H33, and how I'm interpreting it, the title attribute is not mandatory for WCAG compliance.
In the guidelines, due to user agent limitations, the title attribute is not always accessible, especially for screen reader users. This is why WCAG recommends being cautious when using it and suggests other methods, like:
• C7: Using CSS to hide a portion of the link text.
• H30: Providing link text that describes the purpose of a link.

TL;DR It’s recommended to use more reliable methods, like making the link text descriptive, rather than relying solely on the title attribute.
cc: @bwang Feel free to chime in though in case that doesn't sound right.

Yeah, I had the same conclusion as @KSarabia-WMF when i researched in the past. Titles aren’t required, and sometimes result in unexpected output in screen readers (ie they cause this bug: https://phabricator.wikimedia.org/T312891). The content inside title attributes isn't accessible, most of the time that info is not available to screen reader users and in some cases, they actively make screen reader experiences worse.

Some additional design context for @JScherer-WMF: historically title attributes are used for providing supplementary info, like a longer description or keyboard shortcuts.
{F58025793}
In the past, the keyboard shortcuts is what editors would complain about when we forgot the title attribute. Many of the descriptions arent that helpful and probably should be removed, ie:
{F58025795}

If we have UI that's particularly complicated and needs longer descriptions, we should use some other solution like an "i" info button, or just having text to explain things, rather than using a title attribute. For keyboard shortcuts, we should just design a proper shortcut experience for power users, rather than relying on accesskeys, which are also not recommended according to MDN and have caused many bugs in the past.

All that said, there is a real need to provide a visual label for icon buttons. This should be solved with an accessible implementation of tooltips. Tooltips should be in Codex now (https://phabricator.wikimedia.org/T340456)

So in short, I would not recommend adding title attributes. For icon buttons that need a visual label, I think we should investigate using Codex (we’d need to consider the JS and bundle size). For the existing title attributes, ideally someone can audit the copy, and see if there’s any we can remove or make consistent, with the long term goal of replacing them with another solution.

https://inclusive-components.design/tooltips-toggletips/
here’s more resources on it if anyone is curious to learn more

Thanks for the context @bwang and @KSarabia-WMF ! This is really informative. Based on this new information, we only need extra description for the main menu button, the collapsed, ToC, and the personal tools menu button because those are unlabelled. Hide, move to sidebar, and languages buttons have enough descriptive text already.

Maybe I'm misunderstanding the implementation of the Codex tooltips, but I don't think they would work very well to add an on-hover description to unlabelled icon buttons. What approach would you recommend in those cases?

@JScherer-WMF why do you think the codex tooltips wouldnt work well? i think they have examples that look very similar to unlabelled icon buttons https://doc.wikimedia.org/codex/latest/components/directives/tooltip.html#usage

In T329534#10158483, @bwang wrote:

@JScherer-WMF why do you think the codex tooltips wouldnt work well? i think they have examples that look very similar to unlabelled icon buttons https://doc.wikimedia.org/codex/latest/components/directives/tooltip.html#usage

You're right. I thought that the tooltip component needed an "i" icon every time. But if we can use it on other elements without adding an extra icon, it would work well.

Need copy for the appropriate tooltips before proceeding:

• main menu button
• the collapsed
• ToC, and the personal tools menu

@JScherer-WMF, @ovasileva - could you take a look and provide copy guidance?

Just added some copy to the description @ovasileva

Change #1105941 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/skins/Vector@master] Add Missing Title Attributes

https://gerrit.wikimedia.org/r/1105941

I chatted with @bwang about this and we believe that adding Codex tooltip rn would not be the best approach bc it will increase the bundle size. So I added title attributes for the time being. Bernard has written a ticket requesting that the DST add a CSS-only tooltip. Once that is available we can replace the title attributes with that. I will also write a spike for exploring loading modules after a user first interacts with the page, as that could be another option for this type of scenario.

Change #1105941 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add Missing Title Attributes

https://gerrit.wikimedia.org/r/1105941

@JScherer-WMF @ovasileva @LMora-WMF Sorry for the late input on this, but I just realized the labels include verbs like "Open" or "Change".

I don't think the tooltip copy should have those verbs, it should just be "Main menu", " Personal tools", and "Table of contents". The tooltip text should be the same as the label and/or aria-label. The buttons can open or close the menus, and there is already aria attributes that indicate the dropdown state. Even if we made the tooltips dynamic (i.e. "Open main menu" and "Close main menu"), it would be repeating information.

Change #1108138 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/skins/Vector@master] Updating String for Title Attribute

https://gerrit.wikimedia.org/r/1108138

Change #1108138 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Updating String for Title Attribute

https://gerrit.wikimedia.org/r/1108138