[Draft] Module 6: 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

Present and discuss some accessibility properties. Explain how they can be altered, modified, or removed using HTML elements, CSS, WAI-ARIA and JavaScript, or modifying the DOM structure using the appropriate methods.

Learning Outcomes for Topic

Students should be able to:

• explain how the DOM methods allow to modify the properties of a given object
• explain how the accessibility tree can be altered using HTML, CSS, WAI-ARIA, and JavaScript
• code additional semantics for DOM nodes using WAI-ARIA roles 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 trees. Explain that their properties can be modified using JavaScript. Compare it with the accessibility tree and explain that the accessibility tree is a representation of all the accessibility properties based on a given 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 in the accessibility tree. Emphasize that WAI-ARIA does not substitute existing semantics of host languages where it is used, but it complements and expands them. Explain that these properties may not be well supported by assistive technologies, 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 widgets. For example, landmark, widget, document structure, or window roles. Explain how these roles help assistive technologies to interpret the purpose of the widget. 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, such as aria-checked, aria-atomic, or aria-activedescendant. 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 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.
• Short Answer Questions — Students are asked how they can access the accessibility tree and how its properties can be modified or enhanced. 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 WAI-ARIA states and properties. Assess students’ knowledge of the differences between states and properties of the WAI-ARIA specification.
• Practical — Students are presented with different widgets and are asked to decide if WAI-ARIA needs to be used. For those where WAI-ARIA needs to be used, they are asked which WAI-ARIA roles and properties they should have. Assess students’ understanding of the purpose and scope of the WAI-ARIA specification.

Explain commonly used keyboard conventions, such as tabbing, using the arrow keys to move through elements in a list, or using keyboard shortcuts.

Learning Outcomes for Topic

Students should be able to:

• Code focus management within the widget so that it follows a sequential order
• code focus management so that it allows to enter an exit widgets using the keyboard
• add focus to interactive elements that are not focusable by default using the HTML attribute tabindex="0"
• remove focus from interactive elements that lose focus using the HTML attribute tabindex="-1"
• add event listeners to a component that is not focusable by default to allow for keyboard interaction
• explain how keyboard users rely on keyboard conventions to interact with widgets, such as use of the tab, arrow, or shortcut keys
• list requirements for designers to mark up focus indicators, such as adding distinctive CSS styles attached to the focused state

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes.

• 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.
• 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 functionality needs to be added to a custom widget to allow keyboard functionality, see A role is a promise.
• Demonstrate use of the tabindex attribute to indicate if an element can or cannot be focusable. Explain use of the value -1 to mark up 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. An example of how to use the tabindex attribute is provided in the WAI-ARIA Authoring Practices, Managing focus within components using a roving tabindex.
• Explain different keyboard conventions that people use to interact with widgets. Explain that the tab key moves through the focusable elements of a widget. Explain that the arrow keys move through elements in a list.
• Explain different keyboard modes that some assistive technologies include, such as virtual or application. Explain that in the virtual mode most of the keyboard presses are captured by the assistive technology, whereas in the application mode all keystrokes pass directly to the application, and it is the responsibility of the application maker to provide all keyboard interaction.

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 states that a widget can have, such as selected, pressed, expanded, or collapsed. Explain how to make them distinguishable from the focus 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 aria-selected
• code the pressed state using aria-pressed
• list requirements for designers to style states in a way they are distinguishable

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 focus 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 focus 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 how to notify users about dynamic changes on a page, such as using live regions.

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-ARIA attribute 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 region 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.