Accessibility issue due to aria-label

[ad1992]

Adding aria-label does announce it to screen readers but the container element on which the tooltip is shown, the text of that button for example won't be announced as shown in https://kazzkiq.github.io/balloon.css/ the text Hover me is not announced since the aria-label now just has the tooltip text which is an accessibility issue.

ideally, first, the button content should be announced and then the tooltip content.

For the accessibility, role tooltip should be added to the tooltip so screen readers announce it as tooltip but since it uses pseudo-element so won't be possible.

[ad1992]

@kazzkiq should we have both aria-label and data-balloon so the content is announced via aria-label and tooltip is visible via data-balloon?

Ideally, the tooltip should close on pressing the escape key as well so is there any way I can achieve that by adding an attribute to the tooltips if i add an event listener?

[s-yadav]

@ad1992

the tooltip should close on pressing the escape key as well so is there any way I can achieve that by adding an attribute to the tooltips if I add an event listener?

Why should we close the tooltip on escape?
The escape should be active for things that require an explicit action to open (like click).

For hover and focus, should we have an escape handler? Is the escape control mentioned on the accessibility spec?

should we have both aria-label and data-balloon so the content is announced via aria-label and tooltip is visible via data-balloon

Even if you use data-balloon you can't announce the text inside the data-balloon attribute. As the CSS based tooltip libraries use pseudo-elements for adding tooltip, you can't add role="tooltip" on them. So that's why the best way is to use aria-label for tooltips.

Ideally, first, the button content should be announced, and then the tooltip content.

There are in general two use cases for tooltips.

1. The element is for visual (icons/shapes), and the tooltip you add is to define what the element does. In this case you don't need anything to be announced from the element.

2. The element has text and the tooltip is a further description of that element. In such a case, the issue you mentioned will happen. But it can be fixed by incorporating button text information in the tooltip itself.

[ad1992]

@ad1992

the tooltip should close on pressing the escape key as well so is there any way I can achieve that by adding an attribute to the tooltips if I add an event listener?

Why should we close the tooltip on escape?
The escape should be active for things that require an explicit action to open (like click).

As per the guidelines When additional content is triggered on pointer hover or on keyboard focus, that additional content MUST be visually perceived and MUST be dismissible hence If the content obscures or replaces other content, it should be dismissed via keyboard without moving mouse hover or keyboard focus - such as by pressing the Escape key.

For hover and focus, we shouldn't have an escape handler. Is the escape control mentioned on the accessibility spec?

should we have both aria-label and data-balloon so the content is announced via aria-label and tooltip is visible via data-balloon

Even if you use data-balloon you can't announce the text inside the data-balloon attribute. As the CSS based tooltip libraries use pseudo-elements for adding tooltip, you can't add role="tooltip" on them. So that's why the best way is to use aria-label for tooltips.

Yep, that's what I tried mentioning above and hence sadly CSS tooltips will have some limitations when it comes to Accessibility.

Ideally, first, the button content should be announced, and then the tooltip content.

There are in general two use cases for tooltips.

1. The element is for visual (icons/shapes), and the tooltip you add is to define what the element does. In this case, you don't need anything to be announced from the element.
2. The element has text and the tooltip is a further description of that element. In such a case, the issue you mentioned will happen. But it can be fixed by incorporating button text in the tooltip itself.

Yep, I was talking about the 2nd case. I have tried incorporating the button text to the tooltip and it won't be a good user experience if we incorporate all the data to aria-label when it comes to using screen reader especially and also for sighted users the content will look repetitive which is again not a good experience.

[bobderrico80]

I believe using aria-description instead of aria-label would help. I gave this a quick try, and while the button styles/tooltips break (due to the [aria-label] selectors and content: attr(aria-label)), the screen reader (VoiceOver on Mac for me) reads first the button text, and then the tooltip text.

This also appears to be more in-line with what WAI-ARIA recommends. Their guidance assumes that the tooltip is in a separate element and recommends using aria-describedby to link the button with the tooltip element. aria-description allows this to happen all in one element.

I'm going to play around with this a bit more, and open a PR if it works. I'll also need to ensure backwards compatibility with [aria-label], as this would be a major breaking change if both aren't supported.

[bobderrico80]

Hmmm actually, aria-description may not (yet) be a viable option. According to the MDN page on aria-description:

Note: aria-description is still in W3C Editor's Draft for ARIA 1.3. For the time being, continue to use aria-describedby, which has been supported since ARIA 1.1.

Looking at caniuse.com, browser support only seems to be for Chrome and Edge at the moment.

For what it is worth, I do have a draft pull request for aria-description support (while also maintaining aria-label support). I also tested this with Chrome, FireFox, and Safari (despite lack of indicated browser support for the latter two) with VoiceOver, and it reads these as I would expect them to (ex from the demo, "Hover me, what's up?"), so this does seem to be an improvement.

However, I would be nervous moving to a not-yet-supported feature of two major browsers, so I'll leave it to the maintainers' judgement as to whether this is a wise move, and I'll move the linked PR to 'open' if so.