[Draft] Module 6: Widgets

Explain the purpose and scope of the WAI-Aria specification. Describe its different parts and present some scenarios for its usage, such as expanding native semantics of host languages.

Learning Outcomes for Topic

Students should be able to:

• explain the purpose and scope of the WAI-ARIA specification
• explain the purpose of WAI-ARIA roles, as well as categories of roles
• explain the purpose of WAI-ARIA states and properties

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Define WAI-Aria as a set of roles, states, properties, and values to improve the accessibility of web content and applications. Emphasize that it does not substitute existing semantics of host languages where it is used, but complements and expands them. For reference on the WAI-ARIA specification, see WAI-ARIA overview.
• Show examples of WAI-ARIA roles applied to different types of widgets. For example, landmark, widget, document structure, or window roles. For reference on the different categories of WAI-ARIA roles, see the WAI-ARIA specification, Categorization of roles.
• Explain use of supported states and properties of WAI-ARIA in different applications. Mention that state values are more likely to change due to user interaction, whereas property values are meant to last through the application 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

• Short Answer Questions — Students are asked about the different categories of roles that exist in the WAI-ARIA specification. Assess students’ knowledge of the available roles in the WAI-ARIA specification.
• Short Answer Questions — Students are asked about the difference between WAI-ARIA states and properties. Assess students’ knowledge of the differences between states and properties.
• Practical — Students are presented with different widgets and are asked to decide which WAI-ARIA roles and properties they should have. Assess students’ understanding of the purpose and scope of the WAI-ARIA specification.

Explain how to add or remove focus to widgets that are not focusable by default. Emphasize that focus management is essential for keyboard, screen reader, and voice recognition software users to interact with non-standard widgets.

Learning Outcomes for Topic

Students should be able to:

• add focus to an element that is not focusable by default using the HTML attribute tabindex="0"
• remove focus from an element that is not focusable by default using the HTML attribute tabindex="-1"
• add event listeners to a component that is not focusable by default to allow for keyboard interaction
• add focus indicators using CSS styles attached to the focused state

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Demonstrate use of the tabindex attribute to indicate if an element can or cannot be focusable. Explain use of the value -1 to mark an element so that it can be focusable when it becomes visible or available via scripts. Explain use of the value 0 to make an element focusable and put it in the relative order of the navigation according to the DOM structure. For reference on how to use the tabindex attribute, see the WAI-ARIA Authoring Practices, Managing focus within components using a roving tabindex.
• Demonstrate use of event listeners that allow for several ways of interaction. For example, keyboard, mouse, and tactile gestures. Emphasize that, in addition to making an element focusable, it is also necessary to take care of all additional functionality, such as which keys need to be pressed to activate it. For a pointer on what additional functionality needs to be added to a custom widget to allow keyboard functionality, see A role is a promise.
• Demonstrate use of focus indicators for users to keep track of where they are as they are interacting with the widget. Mention that providing the specific styles is a shared responsibility among different team members: designers, and developers. For reference on how to make navigation predictable within widgets, see Discernible and predictable keyboard focus.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment.

• Short Answer Questions — Students are asked what the values of the tabindex element can be and what each of them means. Assess students’ knowledge of the tabindex element and its values.
• Practical — Students are presented with a non-standard button and are asked to code it using WAI-ARIA roles, tabindex attribute, and event listeners for keyboard, mouse, and tactile devices. Assess students understanding of the different ways in which users can interact with non-standard widgets.

Describe additional states of a widget such as selected, pressed, expanded, or collapsed. Explain how to make them distinguishable from the focused state.

Learning Outcomes for Topic

Students should be able to:

• code the expanded or collapsed states using the aria-expanded attribute
• code the checked state using the aria-checked attribute
• code the selected state using the aria-selected attribute and styles different than those of the \focused\ state
• code the pressed state using the aria-pressed attribute

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• Demonstrate use of the WAI-ARIA attribute aria-expanded to convey if associated sections of a widget are visible or hidden. Mention examples of widgets where this attribute can be used, such as menus or accordions. For reference on how to use the WAI-ARIA attribute aria-expanded, see the WAI-ARIA authoring practices, Accordion (sections with show/hide functionality).
• Show examples of non-standard checkboxes. Mention use of the WAI-ARIA attribute aria-checked to communicate the state of the checkbox. For reference on how to use the WAI-ARIA attribute aria-checked, see the WAI-ARIA authoring practices, Checkbox.
• Demonstrate differences between focused and selected states, such as those in listboxes or menus. Indicate that a clear distinction should be made between these two states, such as using the WAI-ARIA attribute aria-selected to convey the state of the selection and applying different styles for each. Mention that providing the specific styles is a shared responsibility among different team members: designers, and developers. For reference on how to communicate the selected state, see the WAI-ARIA authoring practices, Listbox.
• Show examples of toolbars where the pressed state is visually conveyed. Indicate that it is necessary to communicate that information using the WAI-ARIA attribute aria-pressed. For reference on how to code the pressed state, see the WAI-ARIA authoring practices, Toolbar.

Ideas to Assess Knowledge for Topic

• Practical — Students are asked to make an accordion accessible using aria-expanded where applicable. Assess students’ understanding of how to code the expand and collapsed states.
• Practical — Students are asked to make a non-standard check box accessible using aria-checked and role="checkbox". Assess students' understanding of how to code the checked and ` unchecked` states.
• Practical — Students are asked to code an accessible non-standard list box using the focused and selected states where appropriate. Assess students’ understanding of how to code the difference between focused and selected states.
• Practical — Students are asked to code an accessible toolbar using \aria-pressed\ when necessary. Assess students’ knowledge of how to code the pressed state.

Explain mechanisms to notify users about dynamic changes on a page.

Learning Outcomes for Topic

Students should be able to:

• code alerts and warnings on the page using the WAI-ARIA role="alert"
• code the regions of the page that contain the dynamic changes using the WAI-ARIA attribute aria-live
• mark up the level of priority for the updates using the values polite, assertive, or off in the WAI-ARIA attribute aria-live
• mark up the region to be announced as a whole or only parts using the WAI-ARIA attribute aria-atomic
• mark up additions, removals, or all changes in the node to be announced using the attribute aria-relevant

Teaching Ideas for Topic

Optional ideas to achieve the learning outcomes.

• Show examples of alerts and warnings on a page, such as a time warning or an error. Explain that these alerts may not be noticed while using assistive technologies, so additional markup is required. For reference on how to code these alerts, see the WAI-ARIA authoring practices Alert.
• Show examples of dynamic regions of a web page, such as carousels, chat logs, or feeds. Explain that screen reader users cannot perceive these types of updates by default as they can only be focused at one thing at a time. For reference on how to communicate the changes using aria-live, see the WAI-ARIA authoring practices, Auto-rotating image carousel.
• Explain use of the role="alert" to mark up a region as dynamic. Show examples of messages that can be included in those regions, such as information about new loaded contents on a page, or about the item that is currently visible within a set of slides.
• Demonstrate use of the WAI-ARIAattribute aria-live together with its values to indicate the priority with which updates are announced. For reference on the meaning of the different values of the WAI-ARIA attribute aria-live, see the WAI-ARIA specification, aria-atomic.
• Explain use of the WAI-ARIA attribute aria-relevant to communicate which changes of the node should be announced: additions, removals, or all. For reference on how to use aria-relevant, see the WAI-ARIA specification, aria-relevant.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment.

• Practical, — Students are presented with a widget containing an alert and are asked to code it appropriately. Assess students’ knowledge of role="alert".
• Practical — Students are presented with a chat log and are asked to code it appropriately so that it can be understood by users of text-to-speech. Assess students’ knowledge of the types of live regions as well as its roles and properties.