Tooltips for Calendar/DatePicker controls cannot be accessed by Keyboard users

[meghanking]

Environment Information

• Package version(s): current
• Browser and OS versions: Windows 10 + Chrome. Windows 10 + Chromium Edge

Describe the issue:

Keyboard users do not have access to the tooltip explaining the purpose of the control

Please provide a reproduction of the issue in a codepen:

https://developer.microsoft.com/en-us/fluentui#/controls/web/calendar

Actual behavior:

When mouse users hover over a control, a tooltip is shown. When keyboard users are focused on the same control, the tooltip is not shown.

Expected behavior:

When keyboard users are focused on the same control, the tooltip should be shown

Documentation describing expected behavior

MAS2.1.1 / WCAG 2.1.1
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={8492c4eb-c179-40ae-8777-cd044ed725a2}
MAS1.1.1 / WCAG 1.1.1
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={d2d2051f-bdc8-4af7-8e18-38aae867e216}

C+AI Web A11y SME Sarah Higley wrote up a great article: https://sarahmhigley.com/writing/tooltips-in-wcag-21/

My understanding is that using "title" attribute to show browser's default tooltips are not currently accessible and the browsers don't have a plan to change that anytime soon.

[paulgildea]

@smhigley FYI.

Thanks for the issue @meghanking !

[lorejoh12]

Gotta say, this is the first time I've been told NOT to use the title attribute... letting the browser handle making the tooltip popup is a lot more convenient and reduces bundle size over making your own or using a more complex popup control. From the article you linked (and the articles it linked further to), it sounds like the concern is that the title attribute does not consistently pop up on controls that are not focusable. This is most obvious in Chrome- tab to the button to go to next or previous month, see that the tooltip doesn't show it. Unfortunately, it also appears to repro in Chromium Edge...

I suppose the simplest fix here is to replace all instances of the "title" attribute with a <Tooltip /> wrapper. I'm not sure how that will affect bundle size/component performance, and will have to test that the expected information is still read out by screen readers with that component.

This would also be a good chance to do a pass on which elements have tooltips and which don't. I'm seeing for example that the button to switch between month and year picker has an aria-label, but no tooltip even on mouse hover, and it probably should.

[meghanking]

@lorejoh12 I also was taken aback when hearing that title was not the way to go.

I wish the browsers would fix the issues, instead of every product using the attribute to migrate to more complex controls.

Your simple fix is the same strategy that the product teams I work on are also doing across our experiences. That or removing the tooltips entirely, when the tooltip is redundant in some way.

[meghanking]

Hi @behowell and team. Is there an ETA on when this fix will be available?

[behowell]

It looks like this might have been assigned to me because it mentions tooltips, but Calendar isn't actually using tooltips.

@lorejoh12 can you take a look at this? It appears that Calendar needs to stop using the title attribute. It sounds like it could either just remove the attribute and not show anything, or use a TooltipHost to show the tooltips.

[smhigley]

The one thing I'd add is this is a pretty low-severity bug, since the up/down arrows' tooltip text is supplemental to understanding and using the Calendar UI. Arrow icons are universal enough that the tooltip text isn't necessary (which is clear since one potential solution is to remove them entirely 😄).

I wouldn't even consider this a WCAG violation since web authors aren't responsible for the title attribute display itself, and in this case a lack of tooltips doesn't interfere with understanding or operating the UI.

[msft-fluent-ui-bot]

Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.