Tooltip: should have role=tooltip

[guest]

The tooltips do not have ARIA markup. More specifically, wairole="tooltip" should be an included attribute.

[Becky Gibson]

the tooltips do have an ARIA role of alert. This role is used because it is currently supported by the screen readers. When the tooltip is displayed it gets spoken by the screen reader.

We could use the tooltip role but it would be more difficult to implement. If the tooltip was marked with the role of tooltip, the items which causes the tooltip to get displayed would have to be updated with the describedby property when the tooltip is made visible. We would have to add a unique id to the tooltip text element. This might have implications for our reuse of the same object to implement tooltips.

I moved this to Milestone of 2.0 so we can revisit when better support for tooltip should be available in Firefox 3 and screen readers

[alex]

Milestone 2.0 deleted

[Becky Gibson]

currently JAWS 10 is the only screen reader to support the tooltips role. Since the alert role works in older versions of JAWS and Window-Eyes, I'd like to wait longer to change the role from alert to tooltip. JAWS 10 was just released in Nov. 2008 so moving this to 1.4

[Becky Gibson]

Moving this to 1.5 since I can't get the tooltip role to work in Firefox 3.5. The problem is related to the order of event processing in Firefox. Firefox assumes that the aria-describedby information is already set when the target element gets focus. Since we are using the same element for all tooltips on the page, the aria-describedby gets set in response to the focus event to the target element. Although that doesn't explain why the previous describedby information is not spoken?

[Becky Gibson]

My mistake - if I add the aria information on the focus event (and not after the current timeout implementation) it will work. Using the tooltip role is better than using alert because now JAWS will complete speaking the button/object label before speaking the tooltip. Previously JAWS would speak the alert/tooltip text before completing the object text. Would like to commit for 1.4 after a review by Bill.

[Becky Gibson]

use hidden div for ARIA text

[Becky Gibson]

Updated the patch to use a hidden div for the ARIA describedby information. This allows me to set the describedby information in the onHover() event handler for focus and mouseover without affecting the visible text. However, since this does not work with the current version of JAWS 10 I am moving this ticket to 1.5 (it does work with a JAWS 11 public beta, though).

[bill]

Sounds better. (For the record, as we discussed on IRC yesterday) bypassing the setTooltip() API to set the text of the tooltip has issues like that as the users mouses off of one trigger node onto another, the tooltip for the old trigger node changes it's text as it's fading out. Also just on general principles it's bad to bypass the API and muck with the internals of MasterTooltip.

About the new patch, I don't see a reason to put the hidden <div> inside of _masterTT. I thought it would just be a separate <div>, how about just using Tooltip.domNode? Although, not sure if Tooltip.domNode is set when the widget is created programatically or the tooltip's contents are changed dynamically via attr("value", ...). So that would need to be changed, probably with a _setLabelAttr() method.

[Becky Gibson]

better way to implement aria tooltip but still screen reader issues

[Becky Gibson]

So, I have found a better way to implement the tooltip. I just add a describedby to the target node that points to the tooltip node. Then when the tooltip is hidden and show, set the aria-hidden value appropriately on the tooltip node. Note that the tooltip node is never visible on the screen but the contents will be spoken by the screen reader based on the aria-hidden value. The only problem with this is that it does not work for anchors and plain text. It also does not work in IE 8. So, will not check in for 1.5 until I work out those issues.

[Chris Mitchell]

reassign due to inactive committer. please triage accordingly.

[bill]

Mike, any thoughts on this? I figured you had already handled in for 1.8 but I see that Tooltip still has role=alert, so not sure if there's something else to do?

[mikeb]

I don't think there is anything left to do. I used role="alert" for the tooltips because they don't require focus to be closed - see the last sentence in this section: ​http://www.w3.org/TR/wai-aria/roles#alert JAWS14 reads out the tooltip alerts just fine on the test page. I'll close it out.

[Becky Gibson]

I still have concerns about this. I suspect at some point using alert for a tooltip will be "forbidden" by the ARIA specification. The problem with using alert is that the screen reader will immediately start speaking the tooltip text. Often, the information for the object the tooltip is enhancing doesn't get spoken. For example it used to be on the mail demo when I used the tab key to put focus on the New Message menu item, JAWS would never finishing speaking "New Message" but would immediately interrupt by speaking the tooltip. I haven't been in the code in awhile but in the long run it would probably be better to be using the correct aria role sooner rather than later as I suspect we will be forced to do so at some point in the future. Just my two cents.

[bill]

Replying to mikeb:

I used role="alert" for the tooltips because they don't require focus to be closed - see the last sentence in this section: ​http://www.w3.org/TR/wai-aria/roles#alert

I don't understand what this means; the user doesn't close tooltips manually, do they? The tooltips just fade out when you leave the blur the element, or after a certain duration.

It seems like this ticket can be fixed pretty simply, by changing the Tooltip to role=tooltip, and then changing showTooltip() and hideTooltip() to set and remove the aria-describedby property . The one complication is that showTooltip() is not passed the focused node, but rather an ancestor of the focused (or hovered) node. Not sure if setting aria-describedby on an ancestor node works for JAWS or not.

[Slavon]

​http://badbeath.tumblr.com/

[LiamC]

In a project I am working on role="alert" on the Tooltip is not just semantically wrong, but it causes the Tooltip to "shout over" all other form element label information. Our a11y team are failing our form widgets that use Tooltip for validation messages because of this. We have tested the widgets with role="tooltip" and the target having an aria-describedby reference back to the Tooltip. This setup works great. Jaws 14.0.4004 reads all the label information and then the Tooltip content.

I agree with Bill in comment:14 above. However, one use case that I think has been missed in the comments above is when, the Tooltip target already has a value set for aria-describedby. In this case, the aria-describedby value before onShow of the Tooltip needs to be stored and later restored onHide of the Tooltip.

EG:

Javascript: A tooltip is used for validation messages

new Tooltip({
  connectId: ["firstnameInput"],
  label: "* This is a required field"
});

...

HTML: The target node already has the aria-describedby attribute set to reference hint text id:firstNameHint.

<div id="firstNameWrapper">
  <label for="firstnameInput">First name:</label>
  <div class="dijitReset dijitInputField dijitInputContainer">
    <input type="text" 
           name="firstname"
           id="firstnameInput"
           aria-describedby="firstNameHint" 
           value="" />
    <span id="firstNameHint" style="display: none;">
          Enter your first name only
    </span>
  </div>
</div>

Referencing the above HTML snippet, (ignoring multiple Tooltip targets for the sake of simplicity), if a Tooltip was attached to the text input element firstnameInput the rough process would need to be something like the following:

before onShow:

this.oldAria-describedby = 
      domAttr.get(targetNode, 'aria-describedby');    // firstNameHint
domAttr.set(targetNode, 'aria-describedby', this.id); // tooltipId

onHide:

domAttr.set(targetNode, 'aria-describedby', this.oldAria-describedby);

I hope to work on a patch soon.

[bill]

LiamC - In the unlikely case that the node has a pre-existing aria-describedby property, maybe we shouldn't change it at all. I see it as a toss-up, so I'd lean towards not worrying about saving and restoring the original value.

I guess you never got around to making a patch?

[bill]

FYI, I tried to patch this myself, see the prototype at ​https://github.com/wkeese/dijit/commit/9c2a70fc5018f87c7c715674f185ac37cbfb45a1, but JAWS isn't announcing anything about the tooltips (tested on FF with both JAWS14 and JAWS15). So I'd definitely appreciate a patch from you.

[bill]

#15742 is a duplicate of this ticket.

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.