ARIA Tooltip Example

Notes:

• The tooltip never receives focus. Focus stays on the textbox.
• The tooltip widget can shown via keyboard focus or by the onmouse event.
• The tooltip widget can be hidden by removing focus from the text box or by moving the mouse off the textbox.
• The tooltip widget can be hidden by pressing the Escape key
• The tooltip is only hidden via JavaScript and CSS selectors. If JavaScript is not available the tooltip is shown.

For more best practice patterns see making a tooltip.

 

 

Step by Step: How we made the tooltip (tutorial)

In the discussion on ARIA, we discussed 5 steps to making complex things accessible with ARIA.

1. Alert users to what each elements is: Their role (such as checkbox).
2. Alert users to their properties and important relationships (such as disabled, required,and other labels).
3. Alert users to what each element is doing: The state (such as checked).
4. Alert users to changes in their state.
5. Make sure widgets are keyboard accessible and focus works predictably. Events can be triggered though the keyboard, and it should be intuitive to the user. All controls should receive focus via tabbing though the keyboard.

Step 1: Set roles.

Our form uses HTML standard form controls so we do not need form control roles as well. The only thing that needs a role is the tooltip.

<span id="tip1" class="tooltip" role="tooltip" >Also known as User ID</span>


Step 2: Set properties and important relationships

We want to make sure the structure, relationships between elements and groups, properties and labels are all clear in the code. The relationship between the tooltip and the form control is not clear from the DOM. We use aria-describedby to solve this type of problem.

<input class="input-text" id="UserName" name="UserName" type="text" value="" aria-describedby="tip1" />

Note that it is always worth looking at any requirements such as required states, and supported states for your roles before deciding what properties and states you need.

Step 3: Set the initial states

A good rule of thumb is that elements that change how they look often have states that can change at the same time. The tooltip changes from being non-visible to visible. So we are going to use aria-hidden as our state.

We will use CSS selectors to show and hide the tooltip based on the aria-hidden value. Now we will not need to change their CSS class in the code, only the value of aria-hidden.

In the CSS:

span[aria-hidden="true"] {display:none;}
span[aria-hidden="false"] {display:block;}

We are only going to set the initial state when the page loads. This will make the content degrade gracefully, and the tooltip to be open if scripts are not working. We will do this by setting aria-hidden='true'in the document ready function. This way if scripts are working the tooltip will be hidden, but if scripts are not supported the user will still get the content.

$(document).ready(function(){
$("#tip1").attr("aria-hidden","true");....

A word about backward compatibility....

Unfortunately IE 9 does not support the CSS selectors above. (IE 10 does support them.) So to make this work with older browser I added a class hidden:

.hidden {display:none;}

I then added "hidden" to the class attribute in the HTML to hide the hidden items in older browsers.

class = "... hidden"

In the script, whenever I set aria-hidden = "true" in the script, I also added the class hidden to the same selector:

$("%tip1").addClass("hidden");

I also removed it when I set aria-hidden = "false":

$("#tip1").removeClass("hidden");

This makes the script much more robust in older browsers.

Step 4: Set changes in state.

We discussed above that we are using the aria state of aria-hidden and we are using CSS selectors so that whenever aria-hidden='true' the tooltip will be hidden and when aria-hidden='false' the message will be visible.

In the code we have a function to change the values of aria-hidden when the tooltip should be visible.

$("input#UserName").mouseover(function(){
$("#tip1").attr("aria-hidden","false");
});

Similarly we will set aria-hidden='true' when the mouseleave() event is triggered.

For older browsers we also had $("#tip1").addClass("hidden"); (see above)

Step 4: Manage focus and keyboard accessibility.

Managing the focus for the tooltip is easy. The tooltip never receives focus. Focus stays on the textbox. The tooltip role is automatically read to the user and no response is required, there is no need to set focus.

All the other controls are standard HTML controls and so the focus has been taken care of.

Next let's deal with the keyboard accessibility. Firstly, we need to make sure the same functions are triggered by device independent events (such as focus() and blur() ) as for mouse events (such as mouseover(), mouseleave() ). For example.

$("input#UserName").focus(function(){
$("#tip1").attr("aria-hidden","false");
});

For this design pattern, we also want the user to be able to close the tooltip using the esc key.

$("input#UserName").keydown(function(ev){
if (ev.which ==27) {
$("#tip1").attr("aria-hidden","true");
ev.preventDefault();
return false;
}
});