[Draft] Module 6: Custom Widgets

• Prerequisites for Students
• Developing Accessible Content – modules 1-5
• Basic knowledge of HTML5 living standard

• Applied expertise in teaching:
  • WCAG 2 Success Criterion 1.4.13 Content on Hover or Focus
  • WCAG 2 Success Criteria 2.2.2 Pause, Stop, Hide
  • WCAG 2 Success Criterion 2.5.1 Pointer Gestures
  • WCAG 2 Success Criterion 3.2.1 On Focus
  • WCAG 2 Success Criterion 4.1.1 Parsing
  • WCAG 2 Success Criterion 4.1.2 Name, Role, Value
  • HTML5 living standard
  • WAI-ARIA specification
  • WAI-ARIA Authoring Practices 1.1
• In-depth knowledge of:
  • Prerequisites for Students
  • Developing Accessible Content – modules 1-5

Explain how accessibility properties can be added or removed using the appropriate DOM methods. Show examples of accessibility properties such as accessible name and description and explain how they are rendered in the accessibility tree.

Learning Outcomes for Topic

Students should be able to:

• explain how the accessibility tree can be modified using HTML, CSS, WAI-ARIA, and JavaScript
• code additions or removals from the accessibility properties of a given object using the appropriate DOM methods
• code accessibility roles of custom widgets using WAI-ARIA roles
• code additional semantics for DOM nodes using WAI-ARIA states and properties when HTML elements cannot convey enough semantic information

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Show examples of DOM methods to modify properties of DOM objects. Show the accessibility tree generated based on that DOM. Explain that the accessibility tree is a representation of all the accessibility properties based on a particular DOM.
• Show how WAI-ARIA can be used to complement the semantics of the host language where it is applied. Explain that the WAI-ARIA roles, states, and properties override the semantics expressed by the native elements. Emphasize that WAI-ARIA does not substitute existing semantics of host languages where it is used, but it complements and expands them. Explain that accessibility support for WAI-ARIA properties may vary, so checking its current accessibility support is recommended. For examples of common uses of WAI-ARIA in custom widgets, see WAI-ARIA Authoring Practices.
• Show examples of WAI-ARIA roles applied to different types of custom widgets. For example, button, list, listitem, and checkbox. Explain how these roles help assistive technologies interpret the purpose of the widget. Examples of different design patterns and widgets are provided in the Design Patterns and widgets.
• Explain use of supported states and properties of WAI-ARIA in different applications, such as pressed, level, haspopup. Mention that state values are more likely to change due to user interaction, whereas property values are meant to last through the widget’s life-cycle. For reference on the WAI-ARIA states and properties, see the WAI-ARIA specification, Supported states and properties.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment.

• Short Answer Questions — Students are asked how they can access the accessibility tree and how its properties can be added or removed. Assess students’ knowledge of accessibility properties as well as methods to ad or remove them.
• Short Answer Questions — Students are asked about the difference between accessible names, descriptions, roles, and states. Assess students’ knowledge of the different types of accessibility properties.
• Short Answer Questions — Students are asked about the different categories of roles that exist in the WAI-ARIA specification. Assess students’ knowledge of the different types of roles in the WAI-ARIA specification.
• Practical — Students are presented with different custom widgets and are asked to determine which accessibility properties they should have. Assess how students relate accessibility properties with real examples of custom widgets.

Show examples of accessible custom buttons and explain how to code them so that they are operable with the keyboard and perceived by people using assistive technologies.

Learning Outcomes for Topic

Students should be able to:

• code custom buttons so that they are keyboard focusable using tabindex="0"
• code functionality of custom buttons so that they are operable by keyboard interfaces using event listeners that respond to keyboard presses
• code accessible names for buttons using the widget’s text or the WAI-ARIA attributes aria-label or aria-labelledby
• code custom buttons that are interpreted correctly by assistive technologies using the WAI-ARIA role="button”

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Demonstrate use of tabindex="0" to make the button focusable. Show examples of custom buttons with or without tabindex="0" and demonstrate how keyboard users need the presence of that attribute to interact with the button. An example of how to code and accessible custom button is provided in the WAI-ARIA design patterns and widgets, Button.
• Demonstrate use of the enter and space keys to perform the button’s functionality. Explain that event listeners need to be used to prevent those keys from performing their default actions and to make them work as expected while the widget is focused. Show examples of buttons with and without the appropriate keyboard functionality and emphasize how keyboard users rely on them to use the button.
• Explain use of the widgets’ text or the WAI-ARIA attributes aria-label or aria-labelledby to convey accessible names. Show examples of buttons with and without accessible names and demonstrate how assistive technologies interpret each of them.
• Explain use of role="button" to make assistive technologies aware of the widget’s role. Show examples of custom buttons with and without role="button" and emphasize how assistive technologies miss that information if the role is not present.

Demonstrate use of appropriate focus management techniques to make a custom listbox operable through keyboard interfaces. Explain use of WAI-ARIA roles and properties to mark up custom listboxes so that they are interpreted appropriately by assistive technologies.

Learning Outcomes for Topic

Students should be able to:

• code focus management within the items of the listbox using adequate keyboard interaction conventions
• mark up the list widget using the WAI-ARIA role="list"
• code accessible names for list boxes using the WAI-ARIA attribute aria-labelledby
• mark up options within the listbox using the WAI-ARIA role="option"
• mark up currently selected list items using the WAI-ARIA properties aria-selected for each of the selected options and aria-multiselectable="true" when the widget allows to select multiple list items at a time

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Explain use of the keyboard to navigate and select elements of a list. Up and down arrows move up or down through the list items respectively. Space selects the currently focused element. Examples of keyboard interactions for a list widget are provided in the WAI-ARIA listbox widget, Keyboard interaction.
• Demonstrate use of aria-labelledby to label listboxes. Explain that these labels help people using assistive technologies to identify the widget and distinguish it from other user interface components. Examples of how to add labels to custom listboxes are provided in the roles and properties for the WAI-ARIA listbox widget.
• Explain use of role="listbox" and role='option' to make assistive technologies aware of the widget’s role of list and of the options it contains. Show examples of custom lists with and without role="listbox" and emphasize how assistive technologies miss that information if the role is not present.
• Explain use of the aria-multiselectable="true' to mark up a list which allows to select several items. Explain that these type of widgets may imply more keyboard interaction that allows to select several items as people move through the list, and use of additional keystrokes and/or functionality may be required.

Demonstrate use of proper structural markup, as well as coding for notifications and keyboard operability for a carousel.

Learning Outcomes for Topic

Students should be able to:

• code meaningful structures for carousels using headings, lists, labels
• code functionality to move to previous and next slide, as well as to navigate between each of the slides so that it can be operated using different input methods
• code notifications to warn users about the currently selected slide
  • code focus movement to the selected slide to help people orient within the carousel

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Show examples of carousels that have a meaningful structure. Refer back to Structure and Semantics and explain sue of headings, lists, and navigation to make people using assistive technologies aware of the carousel structure. An example of how to structure a carousel is provided in the WAI tutorials on Carousel structure.
• Show examples of functionality that allows to move to next or previous slide. Explain that this functionality needs to be operable through keyboard interfaces, to allow people using keyboard only or assistive technologies to navigate sequentially between the slides. An example of how to code these navigational mechanisms is provided in the WAI tutorials on carousels, Add previous and next buttons.
• Refer back to topic Notifications and explain proper use of live regions to code additional notifications to indicate the currently selected slide. Explain that this is useful for people using assistive technologies as it helps them orient within the carousel. An example of how to code these additional notifications is provided in the WAI website tutorials on carousels, Announce the currently selected item.
• Show examples of how to code proper tab order within the carousel structure. Show how navigation needs to be implemented so that when a slide is selected, focus moves to the content of that slide. An example of how to code proper navigation within carousels is provided in the WAI tutorials on carousels, Add navigation buttons.

Demonstrate use of proper markup, structure, focus management, keyboard conventions, and notifications for an accessible modal dialog.

Learning Outcomes for Topic

Students should be able to:

• code modal dialog containers using the WAI-ARIA properties role="dialog' and aria-modal="true'
• code labels and descriptions for modal dialogs using aria-label or aria-labelledby for the label, and aria-describedby for the descriptions
• code focus management so that it remains within the boundaries of a modal dialog while it is open
• code tab order sequentially for each of the focusable elements within the modal dialog
• code additional keyboard interaction to close the modal dialog

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Show examples of properly coded modal dialog containers, such as div elements with role="dialog" and aria-modal="true". Explain that they help assistive technologies interpret modal dialogs adequately. Mention that all the components of the modal dialog need to be descendants of the container. Examples of how to code modal dialogs are provided in the WAI-ARIA modal dialog design pattern, Examples.
• Show examples of properly coded labels and descriptions for modal dialogs. Explain that the label needs to be a concise phrase indicating the purpose and function of the dialog, whereas the description (if needed), may explain the structure of the dialog and the different functions present.
• Show examples of modal dialogs where focus remains within the boundaries of the dialog. Explain that functionality needs to be added so that when focus reaches the last element and the tab key is pressed, it gets back to the first element and vice versa.
• Show examples of people using the tab key to navigate within the modal dialog. Explain that tabindex needs to be used with values greater or equal to 0, although it is not recommended to use positive integers as they are difficult to maintain and can affect the tab order in unpredictable ways.
• Show examples of functionality that allows to close the modal dialog such as closing button or custom programmatic functionality added to the escape key. Explain that, when the modal dialog is closed, focus should get back to the component that invoked it or, if it is no longer available, to a component that stands for a subsequent step in the workflow.