The remainder of the course is hands-on, taking inaccessible widgets, like the example of toggle buttons described here, and making them accessible by adding appropriate WAI-ARIA and keyboard operability. The toggle buttons widget demonstrated here is provided as an example for the ten widgets you will be working on over the next three units, describing the Activity Elements you will find in each exercise.
Roles, states, and properties for toggle buttons
Activity Element: Following the short introduction to the widget above, a list of the WAI-ARIA roles, states, and properties used with the widget are listed.
role = "button"
tabindex = "0"
aria-label = "[button name]"
aria-pressed = "[true | false]"
Activity Element: Where available, a Suggested Reading is included that provides additional information about accessibility features for the widget being discussed, often linking to the W3C WAI-ARIA 1.1 Authoring Practice documentation, or to a similar resource. These readings are optional but recommended.
At the top right, you may choose to "Edit in JSFiddle" and test the code snippets that will be provided below, to understand how they add accessibility to the widget. You can start by uncommenting the accessibility elements for the toggle buttons, and testing the resulting version with ChromeVox.
Activity Element: Following the JSFiddle will be a collection of code snippets hosted in PasteBin that can be applied to the code presented in the JSFiddle and applied to the code in the course files you will be submitting for marking.
Add a tabindex to each button to make them keyboard focusable, define the role="button" and add a label with aria-label="[button name]" and set the default state to “not pressed” with aria-pressed="false".
Add in equivalent keyboard access where mouse access is provided, referencing the onActivate() function, described below, with jQuery .on('keydown').
Set aria-pressed = "[true | false]" for buttons when activated or deactivated to announce the button’s state to screen readers.
Adding Keyboard Operability
Keyboard access for the buttons is fairly simple, with no special key press events needing to be defined.
Activity Element: When the WAI-ARIA 1.1 Authoring Practices has a set of recommended keyboard interactions, they will be reproduced here. Widgets will typically follow the recommended practice, though in some cases keyboard interaction may vary.
Keyboard Interaction for Toggle Buttons
When the button has focus:
Space: Activates the button.
Enter: Activates the button.
Following button activation, focus is set depending on the type of action the button performs. For example:
If activating the button closes a dialog, focus typically returns to the button that opened the dialog unless the function performed in the dialog context logically leads to a different element. For example, activating a cancel button in a dialog returns focus to the button that opened the dialog. However, if the dialog were confirming the action of deleting the page from which it was opened, the focus would logically move to a new context.
If activating the button does not dismiss the current context, then focus typically remains on the button after activation, e.g., an Apply or Recalculate button.
If the button action indicates a context change, such as move to next step in a wizard or add another search criteria, then it is often appropriate to move focus to the starting point for that action.
If the button is activated with a shortcut key, the focus usually remains in the context from which the shortcut key was activated. For example, if Alt + U were assigned to an "Up" button that moves the currently focused item in a list one position higher in the list, pressing Alt + U when the focus is in the list would not move the focus from the list.
No added keyboard interaction is required for the toggle buttons beyond the standard space bar and Enter key defined in the ik_utils.js file. Reference to these key events is added to the onActivate() function.
Accessible Toggle Buttons in Action
Activity Element: Each widget will have a short video of it interacting with ChromeVox. When completing the activities, aim to have your activity submission function as presented in the video.
The buttons are accessed initially with the Tab key, and the Tab key is used to move between buttons. The space bar or Enter keys are used to activate and deactivate buttons. Aim to have the widget you edit in the associated activity function like that presented in the video (there is no associated activity for this example).
Suggestion Boxes (Updated)
A suggestion box (aka combo box, autocomplete box) is a type of selection menu that helps users enter a correct choice. They are typically made up of a text entry field and a list of choices based on a number of characters entered into the text field. In the example provided here, entering a few characters brings up a list of countries that contain those characters.
Because the text entry field is a standard form text input field, it will be accessible by default. No additional coding is required to make it accessible. What needs the most attention is the list of choices, which needs to announce itself when it appears and needs to be keyboard navigable.
WAI-ARIA roles, states, and properties used in a suggestion box
Define some instructions to make it clear there will be suggestions appearing when text is entered into the text input field.
When the suggestion box receives focus, generate the instruction for it by adding the notify() function to the onFocus() function to produce a live region with the instruction text, that reads automatically when a screen reader encounters suggestion box text field.
Within the init() function, create a <div> to use as a live region, adding aria-live="polite" to announce the list usage instructions defined above when the text field receives focus. Also give it a role="region" so it can be found in the landmarks list.
Provide additional instructions when the suggestion box is populated, adding to the getSuggestions() function.
Adding Keyboard Operability
WAI-ARIA best practices defines all recommended suggestion box keyboard functionality, listed below. In our example, only the required keyboard events are included.
Suggestion Box Keyboard Interaction
When focus is in the textbox:
Down Arrow: If the popup is available, moves focus into the popup:
If the autocomplete behavior automatically selected a suggestion before Down Arrow was pressed, focus is placed on the suggestion following the automatically selected suggestion.
Otherwise, places focus on the first focusable element in the popup.
Up Arrow (Optional): If the popup is available, places focus on the last focusable element in the popup.
Esc: Dismisses the popup if it is visible. Optionally, clears the textbox.
Enter: If an autocomplete suggestion is automatically selected, accepts the suggestion either by placing the input cursor at the end of the accepted value in the textbox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the textbox so the user can add another recipient.
Printable Characters: Type characters in the textbox. Note that some implementations may regard certain characters as invalid and prevent their input.
Standard single line text editing keys appropriate for the device platform (see note below).
Alt+Down Arrow (Optional): If the popup is available but not displayed, displays the popup without moving focus.
Alt+Up Arrow (Optional): If the popup is displayed:
If the popup contains focus, returns focus to the textbox.
Closes the popup.
Note: Standard single line text editing keys appropriate for the device platform:
include keys for input, cursor movement, selection, and text manipulation.
Standard key assignments for editing functions depend on the device operating system.
The most robust approach for providing text editing functions is to rely on browsers, which supply them for HTML inputs with type text and for elements with the contenteditable HTML attribute.
The most significant effort in making the suggestion box accessible is adding keyboard operability. In our case, we’ll add Up and Down Arrow operability to the list box. Create a switch that captures the keypress event. If it’s a Down Arrow, select the next item down in the list. If it’s an Up Arrow, select the previous item. If it’s any character key, enter the value in the text field. Add this to the onKeyUp() function, while integrating the existing functionality in the function into the default for the switch statement.
Accessible Suggestion Box in Action
Watch the following video to see how ChromeVox interacts with a suggestion box. When the suggestion box receives focus, instructions are read. When the second letter is typed into the text field a list of suggestions appears below. Additional instructions are provided on how to make a selection from the list. Arrow keys are used to navigate through the suggestions, and the Enter key is used to select one of them. Aim to have the suggestion box you update in Activity 5 on the following page operate and announce like the one in the video.
Monday, October 8, 2018 - 10:56 Submitted 3 months 3 weeks ago by Visitor (not verified).