Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the use of role=tooltip #979

Open
scottaohara opened this issue May 9, 2019 · 15 comments
Milestone

Comments

@scottaohara
Copy link
Member

@scottaohara scottaohara commented May 9, 2019

Per discussions I've been having with developers and accessibility practitioners, as well as parallel discussions I know others have had on the same topic, there seems to be a general question of how useful the tooltip role is when implementing custom tool tips on the web.

Currently the prose for tooltip notes the element(s) it is used on should be referenced by the owning element witharia-describedby. As this attribute is what conveys the tool tip's contents to users when the owning element is focused, it's not clear what the purpose of the tooltip role is meant to be, since aria-describedby would communicate this information regardless of the existence of the tooltip role.

Regarding to how the ARIA specification could clarify the purpose of tooltip, it seems to me there are a few options here from indicating that some user agents may not do anything special with the role, to more clearly indicating how AT could better expose it. I'm sure others have some ideas here though, and I'd be very happy to hear them.

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented May 9, 2019

To me, a sensible approach would be to specify role="tooltip" as one of those magic roles that acts as a live region - that user agents should expose it when it appears, ideally. And remove the suggestion to explicitly tie it via aria-describedby. Because yes, as @scottaohara notes, it seems that the role currently has no discernible effect on its own.

@stes-acc

This comment has been minimized.

Copy link

@stes-acc stes-acc commented May 13, 2019

My expectation would be that at least "tooltip" is announced before its content is spoken to distinguish this information from any other associated text node text. But ARIA does not define screen reader speech output. It is all in the mercy of AT. Making this a live region won't change that.

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented May 13, 2019

Making this a live region won't change that.

no but it would remove the need to the also tie it via aria-describedby, and perhaps make it more in line with what authors may expect...

@stes-acc

This comment has been minimized.

Copy link

@stes-acc stes-acc commented May 13, 2019

If so you need additional JS code to update the region of control focus, otherwise you get no speech output, which is unnecessary in case of an existing relation.

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented May 13, 2019

As you'd likely already use JS code to show/hide the tooltip, I'm not sure this would be such an extra additional ask?

@stes-acc

This comment has been minimized.

Copy link

@stes-acc stes-acc commented May 13, 2019

You don't need JS to show the tooltip, see tons of examples here

@scottaohara

This comment has been minimized.

Copy link
Member Author

@scottaohara scottaohara commented May 13, 2019

While CSS can be used to show the tooltip, JS will still be necessary, especially per WCAG 1.4.13.

@stes-acc

This comment has been minimized.

Copy link

@stes-acc stes-acc commented May 14, 2019

Thanks for the hint.

WCAG 1.4.13. is new in WCAG 2.1. It has even not yet Failure examples as part of the "Failures" section (and still recommends "@@ CSS: Using hover and focus pseudo classes" as "sufficient technique which is strange).

Expect delays in adaption. Many implementations are still on WCAG 2.0.

I agree that in JS-based HTML frameworks we have always a great amount of JS control code that can be extended for such purposes. But I still doubt that adding a new live region to the page decoupled from the visual tooltip presentation will do the job. When used (as a concept extension) one day with interactive subcontent (like links) I see it more as a variant of the dialog role. It s not uncommon that tooltips are used this way and ARIA has to evolve in this direction.

Your idea also implies that devs should designate always a certain page area for "tooltip announcements" (the other option, having each control its own live region tooltip area is ridiculous, as you know since UI will be swamped with those areas). Given that, it seems that jQuery has already an implementation using a extra live region PER CONTROL.

Having just one region for tooltip updates could also have disadvantages, like a HTML code-wise decoupling of control with its very help description text which may have implications on check tools and automation in general.

I am also sure this topic should be discussed more listing pros and cons from a rational and independent perspective.

@patrickhlauke

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented May 14, 2019

a rational and independent perspective

because clearly we don't have that? ;)

Anyway, back to the original issue: what's the point of role="tooltip" in practice if it has no effect? Should AT announce the fact something's a tooltip when it's announced? Should they do it automagically or not?

@stes-acc

This comment has been minimized.

Copy link

@stes-acc stes-acc commented May 14, 2019

My expectation would be that at least "tooltip" is announced before its content is spoken to distinguish this information from any other associated text node text. But ARIA does not define screen reader speech output. It is all in the mercy of AT. Making this a live region won't change that.

@LJWatson

This comment has been minimized.

Copy link

@LJWatson LJWatson commented May 14, 2019

@stes-acc commented:

Expect delays in adaption. Many implementations are still on WCAG 2.0.

Which brings me back to a topic I've brought up before... testing ARIA implementations in the accessibility APIs is not enough. It satisfies the letter of the W3C's requirement for at least two independent implementations of every feature, but it doesn't follow the spirit (which is intended to give developers confidence that features are production ready in at least two agents).

When people see that an ARIA feature has made it to Recommendation, they assume it works in the real-world. Yet time and again we find cases where an ARIA role or attribute has only one screen reader implementation, or quite possibly none at all.

Anyway, I digress, but I do think this is an important topic.

@jnurthen

This comment has been minimized.

Copy link
Member

@jnurthen jnurthen commented May 14, 2019

@LJWatson This is off topic for this issue but I'll note the following:

  1. For future features in ARIA 1.2 and later the https://www.w3.org/WAI/ARIA/workflow states for an ARIA feature to be ready it needs "Positive confirmation of acceptance by multiple assistive technology vendors in the form of implementing support, or a comment in a public issue tracker that they intend to implement support."

  2. For already shipped features the https://github.com/w3c/aria-at project is intended to provide guidance as to how well a feature is supported.

@carmacleod

This comment has been minimized.

Copy link
Contributor

@carmacleod carmacleod commented Jun 1, 2019

I'd like to describe our tooltip use case... to make sure that it is not left out, and hopefully, to improve it. :)

We have a code editor, and a bunch of "command buttons" (some have icons, some have text; some are in toolbars, some are not).

The code editor uses tooltips in many ways. For example, if editing javascript, there are tooltips for:

  • showing a comment (if any) for the class/method/variable/etc at the current [hover/caret] position
  • describing annotations for the current line, such as compiler error/warning/info, bookmark, breakpoint, etc

The "command buttons" have a tooltip that may consist of just their name (i.e. for icons), or may be a sentence or two describing the function of the button (i.e. for more complicated commands).

Designers and users have made it clear that automatically popping up a tooltip in the editor every time the text caret moves into a class/method/variable or annotated line is terrible UX (very "in your face", obscures code, "too much information I don't need right now", etc).

Further, our users (who are developers - a picky and demanding lot 😉) don't like having button tooltips pop up automatically on focus. They find it startling and annoying.

So our solution was to make all tooltips only available "on demand". Either hovering over "a thing with a tooltip" or typing Shift+F1 on "a focused thing with a tooltip" will open the related tooltip.
In addition, we have shortcut keys to go to the next/previous annotation in the editor. Those move the caret to the next annotated word or line and pop up its related tooltip immediately.

Our editor actually only implements one "tooltip element", which it populates and positions as needed, to give the illusion of many tooltips. This "tooltip element" has aria-live="assertive" so that AT read it when it's populated and shown (i.e. invoked by keyboard or mouse). It doesn't currently use role="tooltip" or aria-describedby.

Our button tooltips don't have aria-live. They are created, positioned and displayed on hover or Shift+F1. They have role="tooltip", and the button references them either with aria-labelledby (if the button needs a name), or aria-describedby (if the button already has a name, and the tooltip content is a sentence or two with more detail than just a name).

The tooltips that provide a name are there for sighted users to make sense of an icon. Referencing name tooltips with aria-labelledby ensures that the same name is used for screen reader users.

@scottaohara I've never noticed the problem you mentioned in #987 (comment):

navigating to an element and having its accessible name exposed, and then attempting to navigate away but encountering the accessible name again.

because a screen reader user wouldn't bother opening a button's tooltip when they already know its name.

So, to the point of this issue, one possible use for role=tooltip could be to improve the "tooltip on demand" use case. AT could look at whether an element's aria-describedby points to an element with role=tooltip, and if so:

  • don't automatically read the aria description
  • play a small tone so that users would know there's a descriptive tooltip available (I think it would be too verbose to say "has tooltip")

Then users could choose whether or not to open the tooltip to hear the description.

Getting AT to buy into this would be hard, though, because so few apps (possibly only one? 😄) have on-demand tooltips.

@mcking65

This comment has been minimized.

Copy link
Contributor

@mcking65 mcking65 commented Jun 1, 2019

A relationship between a tooltip and the element it complements seems necessary to me because:

  1. As a user, coaxing a screen reader to repeat ephemeral live announcements is difficult.
  2. If the content of a tooltip could be focused by a reading or touch cursor, the AT would not be able to provide a function that indicates which element it complements.

For elements such as graphical buttons or interactive icons, the tooltip provided for the visual interface is often redundant when compared to the accessible name. While the tooltip may not be worded in exactly the same way as the accessible name, it may not provide any additional useful information. Thus, authors need a way of providing those tooltips without adding undesirable verbosity.

As for how a tooltip is announced, that seems like a screen reader design decision. I don't see a benefit to hearing the word tooltip first. Besides being a techy term that is likely meaningless to a non-developer, its content and the timing of its announcement seem like adequate distinction from other attributes that are currently announced automatically.

It might be useful to make a list of the most common uses of tooltips. Then for each, list the use cases that an assistive technology user may have for perceiving the tooltip content.

Common uses might include:

  1. Providing information relevant to all users that supplements the visually persistent UI.
  2. Providing modality-specific help or instructions for an element, e.g., help relevant only to mouse users, help relevant to only keyboard users, etc.
  3. Providing a text name for a graphical element.
  4. Providing a text description of a graphical element.

For each of the above, beneficial assistive technology behaviors could be quite different. If the tooltip is relevant only to mouse users, there are not likely many or any assistive technologies that would want to bother their users with it. On the other hand, if a tooltip is providing keyboard shortcut instructions, it would be particularly relevant to assistive technology users. Similarly, if a tooltip is providing an accessible name, it would be especially important, but you would not want the same behavior as the keyboard shortcut description.

@scottaohara

This comment has been minimized.

Copy link
Member Author

@scottaohara scottaohara commented Jun 2, 2019

Thank you for responding with your use case @carmacleod, there's a lot here that I think could really help in suggestions to make this role more useful. Additionally, I also think that Matt raises many good points in that further exposing a tooltip could be useful, but could also be completely unnecessary in some situations. If anything, both of your replies make me think it's even more important to narrow down when a role=tooltip should be used (e.g. for descriptions), and better indicate that the role should not be used when not necessary, so as to not create unnecessary verbosity, or functionality that is not useful for certain types of content.

A few notes per specific quotes:

So our solution was to make all tooltips only available "on demand".

I think this would be a wonderful solution for tooltips, e.g. native title attributes or ARIA tooltips. Let people know there was more information, but not announce it by default. It'd allow them to be available but not have to be revealed immediately, and thus hopefully less annoying. One of the reasons we even need "toggle tips" is due to the current expectation that a tooltip must be shown on hover/focus. If there were a command / visual cue to announce/show the tooltip when actually desired, this could even help reduce the need for toggle tip patterns.

Either hovering over "a thing with a tooltip" or typing Shift+F1 on "a focused thing with a tooltip" will open the related tooltip.

Again, some sort of "screen readers MAY/SHOULD let users know there is a tooltip associated with this element" would definitely promote this from a largely (presently) unannounced role to something that could create benefit, and would be in line with Matt's comment "A relationship between a tooltip and the element it complements seems necessary..." I agree with this fully, otherwise why use the role?

The tooltips that provide a name are there for sighted users to make sense of an icon. Referencing name tooltips with aria-labelledby ensures that the same name is used for screen reader users.

But the `role="tooltip" doesn't really do anything, right? It's not a description to the element. The role is not announced, nor would you want it to if it's just providing the accessible name. It's just using a role for the sake of the role and because it shares a similar visual design to a descriptive tooltip? Or am I missing something?

I've never noticed the problem you mentioned in #987... because a screen reader user wouldn't bother opening a button's tooltip when they already know its name.

It reads to me that your comment is reliant that there is a mechanism in place to let the user know a tooltip can be made available via activation (e.g. per your particular use case and how its been implemented). Under the current ARIA definition for a tooltip though, web developers are given the instructions should appear on hover/focus of an element, and while that may not always be triggered when navigating by virtual cursor, there are instances where it could. For instance, VoiceOver on macOS is but one example of where a tooltip could be navigated to after it was announced in context to the element it is associated with:

Zoe's tooltip demo where VoiceOver fired a focus event, revealing the accessible name 'tooltip'.  Keyboard focus remains on the 'like button', but VO cursor has moved past the button and navigated directly to the word 'like' within the 'tooltip', producing a 'Like' announcement but no tooltip role announcement.

To help mitigate against situations like this, I've often added an aria-hidden="true" to the exposed tooltip or accessible name, so that it isn't discoverable or announced beyond the context it was intended. But then, aria-hidden="true" added to a role=tooltip again begs the question, "why even use the role if its just going to be hidden?"

to the point of this issue, one possible use for role=tooltip could be to improve the "tooltip on demand" use case... Then users could choose whether or not to open the tooltip to hear the description.

Again, I'd be very much in favor of this, emphasis on description. I think where this gets murky though is adding the complexity that a tooltip can be a representation of an accessible name, on top of the current expectation that it is a description.

Per Matt's comment after outlining four use cases for a "tooltip" and "tooltip-like" UI element:

For each of the above, beneficial assistive technology behaviors could be quite different... Similarly, if a tooltip is providing an accessible name, it would be especially important, but you would not want the same behavior as the keyboard shortcut description.

Regarding my comments in the other issue, revealing an accessible name for an element in a manner that a designer might describe as a "tooltip", doesn't mean it actually needs to be coded as one, nor would it be always useful for someone to have it announced as one.

I think the use case you provided is a solid one for how tooltip could be revised to be more useful. I also think Matt's comments show that expanding role=tooltip to be used for things that aren't descriptions adds complexity to a role where then AT would need to figure out "is this a description, if so, do something useful. VS is this an accessible name, if so, maybe don't do anything?"

Ok, I think that's all I got to say about this right now? I hope this was helpful. Again thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.