19. Natively Focusable Elements
<a href="#">Label</a>
<button type="button">Label</button>
<input type="button" value="Label">
Convey interactivity
In the default tab flow
Fire click event in response to the mouse
and keyboard
20. Using tabIndex
<li tabindex="0" />
Convey interactivity
Focusable
Can be in placed in the tab flow
Fire click event in response to the mouse
BUT NOT the keyboard
23. tabIndex=0 Use Case
<span class="btn" tabindex="0">OK</span>
$(".btn").on("keydown", function (e) {
var keyCode = e.keyCode;
if (keyCode === 13 || keyCode === 32) {
$(this).trigger($.Event("click"));
}
});
24. tabIndex=0 Review
Places the element in the default tab flow
Focusable via keyboard, mouse or JavaScript
Default browser focus outline onFocus
Click not fired via Enter or Spacebar
26. tabIndex=-1
Removes the element from the tab flow
Focusable via the mouse or JavaScript
No browser focus outline in IE
Click not fired via Enter or Spacebar
41. toolbar.on("keydown", "button", function (e) {
var keyCode = e.keyCode,
button = $(this),
next;
if (keyCode === 37) { // Left
next = "prev";
}
else if (keyCode === 39) { // Right
next = "next";
}
if (next) {
button[next]().focus();
}
});
61. Initial Focus
function showMenu() {
menu.find(".selected").removeClass("selected");
menu.removeClass("hidden");
var position = button.position();
menu.css({
top: (position.top + button.outerHeight()),
left: position.left
});
menu.focus();
}
62. Initial Up/Down Arrow
if (target === menu[0]) {
if ((selected = menu.find(".selected")) && selected[0]) {
event = $.Event("keydown", { keyCode: keyCode });
selected.trigger(event);
}
else {
if (keyCode === 38) { // UP
selector = "li:last-child";
}
else if (keyCode === 40) { // DOWN
selector = "li:first-child";
}
menu.find(selector).addClass("selected").focus();
}
}
63. Up/Down Arrows
switch (e.keyCode) {
case 38: // UP
next = "prev";
break;
case 40: // Down
next = "next";
break;
case 13: // Enter
case 32: // Space
selected.trigger($.Event("click"));
selected.blur();
break;
}
if (next && (nextItem = li[next]()) && nextItem[0]) {
li.removeClass("selected");
nextItem.addClass("selected").focus();
}
84. :focus Limitations in IE
Not supported in IE < 8
IE < 8 does provide :active, but only for links
IE doesn't render default outline when
tabIndex is set to -1
Cannot remove default outline using CSS in
IE < 8
85. Supplementing :focus In IE
if (browser.msie && browser.version < 8) {
toolbar.on("focus", "button", function () {
$(this).addClass("focus");
});
toolbar.on("blur", "button", function () {
$(this).removeClass("focus");
});
}
96. Initial Up/Down Arrow
if (target === menu[0]) {
if ((selected = menu.find(".selected")) && selected[0]) {
event = $.Event("keydown", { keyCode: keyCode });
selected.trigger(event);
}
else {
if (keyCode === 38) { // UP
selector = "li:last-child";
}
else if (keyCode === 40) { // DOWN
selector = "li:first-child";
}
menu.find(selector).addClass("selected").focus();
}
}
97. Up/Down Arrows
switch (e.keyCode) {
case 38: // UP
next = "prev";
break;
case 40: // Down
next = "next";
break;
case 13: // Enter
case 32: // Space
selected.trigger($.Event("click"));
selected.blur();
break;
}
if (next && (nextItem = li[next]()) && nextItem[0]) {
li.removeClass("selected");
nextItem.addClass("selected").focus();
}
99. listbox.on("keydown", "li", function (e) {
var keyCode = e.keyCode,
li = $(this),
next,
nextItem;
if (keyCode === 38) { // UP
next = "prev";
}
else if (keyCode === 40) { // DOWN
next = "next";
}
if (next) {
// On initial arrow key press, don't advance focus,
// just synchronize focus and selection
if (!li.hasClass('aria-selected')) {
li.addClass("selected");
}
else if ((nextItem = li[next]()) && nextItem[0]) {
makeSelection(nextItem);
nextItem.focus();
}
}
});
100. function makeSelection(li) {
listbox.find("li.selected").attr('tabIndex', -1).removeClass("selected");
li.attr('tabIndex', 0).addClass("selected");
}
101. listbox.on("focusin", function (e) {
if (!listbox.hasClass("focus")) {
listbox.addClass("focus");
}
});
listbox.on("focusout", function (e) {
setTimeout(function () {
if (!$.contains(listbox[0], document.activeElement)) {
listbox.removeClass("focus");
}
}, 0);
});
First things first. If you are on a Mac, you&#x2019;ll want to configure it for full keyboard access.\n
Use Ctrl + F7 to enable keyboard access for all controls across OS X. This will also enable full keyboard access for Firefox on the Mac.\n
Personally, I also like my function keys to operate as standard function keys. To set this go to System Preferences > Keyboard\n
In Safari go to Preferences > Advanced and check &#x201C;Press Tab to highlight each item on a webpage&#x201D;\n
Chrome has a similar preference in &#x201C;Under the Hood&#x201D;\n
Before we talk about providing keyboard access, let&#x2019;s begin by understanding who benefits from good keyboard access.\n
Users who prefer the keyboard. One example would be software engineers, but many users realize that keyboard shortcuts can greatly improve their efficiency.\n
Users who are blind completely rely on the keyboard both to navigate as well as to enter information.\n
Users with physical disabilities may not be able to type with a physical keyboard, but can use voice recognition software to speak keyboard shortcuts.\n
Similarly, users with physical disabilities can use software keyboards to press keyboard shortcuts.\n
\n
The more I have studied keyboard shortcuts for widgets, I find widgets fall into three categories. Throughout this presentation we&#x2019;ll talk about these patterns and how to implement them.\n
The first API essential to keyboard access is the tabIndex attribute. tabIndex can be used to make any element in the DOM focusable, and controls how it can be focused. If an element isn&#x2019;t focusable it can&#x2019;t fire key-related events.\n
Another reason focusability is important for widgets: Screen readers read the currently focused element. So, if a widget isn&#x2019;t focusable, it will be less discoverable and very likely inoperable to users of screen readers.\n
HTML provides a limited set of natively focusable elements&#x2014;mostly form controls, buttons and links.\n
Using tabIndex, any element in the DOM can be focusable and fire key events. tabIndex can be set to one of three values: -1, 0 and an explicit positive index.\n\nA tabIndex of -1 enables an element to be focusable via JavaScript or the mouse. Elements with a tabIndex of -1 are not in the tab flow.\n\nA tabIndex of 0 places the element in the default tab flow; the element is also focusable via JavaScript or the mouse.\n\nLastly, tabIndex can be set to an explicit value.\n
\n
\n
tabIndex can be set declaratively in the markup, or programmatically using JavaScript.\n
\n
One simple use case for tabIndex 0 is to make custom buttons focusable via the keyboard. JavaScript can be used to enable users to click the button by pressing either the Spacebar or Enter key.\n
\n
\n
\n
\n
Popup menus are a good use case for tabIndex=-1 because they aren&#x2019;t in the tab flow but need to be focusable.\n\nHere&#x2019;s how to set tabIndex on the various elements that compose a popup menu.\n
One use for explicitly declaring tabIndex would be to balance visual and functional requirements. For example, in GMail the &#x201C;Send&#x201D; button appears before the To, Subject and message body fields. However, when composing an email you&#x2019;d likely want to tab first to the To field, then Subject, then the message body, and then finally the Send button.\n
\n
The second piece of API are the focus() and blur() methods.\n
\n
Stateless containers: widgets like menubars and toolbars. Both manage a collection of like descendant controls, and both maintain a visual focus/selection as the user is navigating. However that selection is not maintained after the control loses focus.\n
On the desktop menubar and toolbars are often not in the tab flow; the user moves focus to them via a keyboard shortcut.\n\nOn the web, these controls ARE generally in the tab flow for two reasons:\n\n1) Discoverability&#x2014;expectation would be that you can use Tab or Shift + Tab to move focus to a control\n\n2) Implementing a keyboard shortcut to move focus to a toolbar might use up a shortcut you need for another user action\n
\n
Consider a toolbar. When you first move focus to it, the first button is selected.\n
As you navigate through the toolbar the currently focused button is highlighted.\n
When the toolbar loses focus, the visualization of focus is cleared.\n
When the toolbar is re-focused, the user does not resume where they left off, but rather starts back at the beginning.\n
To implement this functionality, use tabIndex to remove all but the first button from the tab flow. This will allow the user to use the Tab key to move focus to/from the toolbar in a single keystroke.\n
Then, bind a delegated keydown event listener that moves focus to the next or previous button in the toolbar as the user presses the left or right arrow keys.\n
\n
\n
Stateful containers: these are widgets like treeviews, tablists, or listboxes. These widgets manage a collection of like descendant controls, and maintain selection even when they have lost focus.\n
Consider a listbox control. The initial state is no selection.\n
When a stateful container control initially receives focus, it has no selection, but focus is often indicated by an outline or change of color on the root element. Sometimes an outline around the first item, indicating it is focused but not selected.\n
When the user presses the up and down arrow keys, the selection is advanced.\n
When the control loses focus, the current selection is maintained, but often grayed out to indicate that it is not active.\n
If the control regains focus, the up and down arrow keys should allow the user to pickup where they last left off.\n
To implement this pattern, begin by setting the tabIndex of the first element to 0, the rest to -1.\n
As the user presses the arrow keys to make a selection, update the tabIndex of the currently selected item to 0 and set the tabIndex of the previously selected item to -1. This will allow there to be a functional representation of the selection; if the control regains focus, the focused item will be the last selected item&#x2014;allowing the user to pickup where they left off.\n
This technique is referred to as the &#x201C;Roving TabIndex Technique&#x201D; in the W3C&#x2019;s ARIA Authoring Practices specification.\n
\n
\n
\n
\n
When a menu opens, focus should be moved to the menu. It has no initial selection.\n
On initial press of the up or down arrow keys, focus is moved into the menu. If the user pressed the down arrow, the first menuitem is selected. If the user pressed the up arrow, the last menuitem is selected.\n
On subsequent key press, selection follows the arrow keys.\n
Implementing this behavior is easy. The menu container and all of the elements used to create menuitems are given a tabIndex of -1 to make them focusable.\n
Focus is set to the menu&#x2019;s container when the menu is made visible.\n
On initial up/down arrow key press, use the :last-child and :first-child selectors are used to select either the first or last menuitem, depending on the key that was pressed.\n
On subsequent arrow key presses, just advance the selection using a class name, and then focus the next menuitem.\n
\n
When a dialog is made visible, focus should be moved into the dialog&#x2014;to control that represents the next action the user is likely to want to take. This saves keyboard users the work of having to use the Tab key to move focus into the dialog.\n
For modal dialogs, modality should be enforced for both the keyboard and the mouse; the user shouldn&#x2019;t be able to move focus outside of the dialog using Tab or Shift + Tab.\n
If the user cancels the dialog (by pressing the Esc key, the close, or Cancel button), focus should be sent back to the element in the DOM that had focus prior to the dialog&#x2019;s display. This helps keyboard users pickup where they left off.\n
Implementing this behavior is easy. When the dialog is made visible, use focus() to move focus to the desired control inside the dialog.\n
What about the other behaviors? Like enforcing modality for the keyboard? And, if the dialog is cancelled, moving focus back to the element in the DOM that had focus prior to the dialog&#x2019;s display?\n\nFor these behaviors we&#x2019;ll use three other APIs: document.activeElement, the contains() method and the focus and blur events.\n
\n
\n
\n
activeElement returns a reference to the currently focused DOM element.\n
Use activeElement to capture a reference to the element that had focus prior to a dialog&#x2019;s display. In this example, the showDialog() function passes the activeElement as a reference to the event listener used to hide the dialog.\n
\n
This makes it really easy for the event listener to return focus back to the element that had focus prior to the dialog&#x2019;s display.\n
Both jQuery and YUI provide a contains() method&#x2014;an easy means of determining if one DOM element contains another. This is useful for enforcing modality.\n
jQuery and YUI also provide ways to listen for delegated focus and blur events. These are useful as standard DOM focus and blur events do not bubble.\n\nIn jQuery you can use event delegation with the &#x201C;focus&#x201D; and &#x201C;blur&#x201D; events either by specifying &#x201C;focusin&#x201D; and &#x201C;focusout&#x201D;, or by using on() with either &#x201C;focus&#x201D; and &#x201C;blur&#x201D; and providing a delegation selector.\n
Putting the two together: To enforce modality, simply bind a document-level, delegated focus event listener. That listener will then use contains() to determine if focus has left the dialog, and restore focus to the dialog if it does lose focus.\n
A similar technique can be used to hide popup menus if focus is moved outside of the menu.\n
The final API essential for keyboard access is the :focus pseudo class.\n
\n
Unfortunately IE 6 and 7 do not support the :focus pseudo class.\n
\n
It easy to supplement the lack of support for the :focus pseudo class in IE using JavaScript.\n
Setting the CSS "outline" property to "none" is the primary reason that focus isn't visible in many web sites and applications.\n
As it turns out, there is actually a website dedicated being mindful of not setting the CSS "outline" property to "none".\n
If you are looking to provide custom focus styles for your site or application, I would recommend not globally removing the browser&#x2019;s default outline because it is likely there are going to be instances now, and especially later, where you might forget to define a focus style&#x2014;leaving the user without a visualization of focus.\n\nRather than globally removing the browser&#x2019;s focus outline, selectively remove it for instances where you are providing custom styles. This will help ensure you have some visualization of focus.\n
All of these CSS properties are useful for styling focus as they don't affect box size and therefore the content around the focused element won't reflow.\n
Custom focus styling is not possible in IE < 8. But IE does provide a default focus style. In Yahoo! Mail, custom focus styles are considered a Progressive Enhancement.\n
In addition to the :focus pseudo class, there is also :active.\n
\n
Practically speaking the :focus pseudo class is most useful when it comes to styling focus for atomic controls like buttons or links. For all other widgets, :focus isn&#x2019;t enough as we&#x2019;ll see in the follow examples.\n
For example, consider popup menus and listboxes.\n
A popup menu needs to be able to move selection in response to both the keyboard and the mouse. As the user switches between either input mechanism, the selection needs to be able to stay in sync.\n\nThere are two reasons we cannot rely on :focus and :hover:\n\n1) Lack of reliable support in older IE versions.\n\n2) Even if old IE support isn&#x2019;t an issue, if we were to rely on :focus and :hover alone the user might see two menuitems selected simultaneously if they start with one device (mouse), then move to anounce (keyboard).\n
For this reason, using a class is more robust than relying on :focus and :hover. As the user switches between the keyboard and the mouse, the corresponding event listener can stay in sync with the selection made via the previous input method.\n
\n
Another example: being able to persist selection when a control has lost focus. For example, the selected item in a listbox should still be rendered even when the control has lost focus.\n
The currently selected item is marked with a class of &#x201C;selected&#x201D; as the user presses the up and down arrow keys.\n
\n
contains() is used to determine if the listbox has focus. When the listbox has focus, a class of &#x201C;focus&#x201D; is added to the root element.\n
With a class of &#x201C;focus&#x201D; on the root element, the CSS can be structured so that the selected item in the list is rendered blue when the widget has focus, and gray when it does not.\n
\n
\n
As we&#x2019;ve seen, implementing keyboard navigation across all of the various widget types involves handling a very few number of keys. \n
Working examples of all of the widgets from this presentation are available on github.\n