[Draft] Module 6: Custom Widgets

• Prerequisites for Students
• Developer Modules
  • Module 1: Structure and Semantics
  • Module 2: Navigational Menus
  • Module 3: Images and Graphics
  • Module 4: Tabular Information
  • Module 5: Forms and Input Elements
• 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 Authoring Practices 1.1
  • WAI-ARIA specification
• In-depth knowledge of:
  • Prerequisites for Students
  • Prior Developer Modules

Refer back to previous modules and demonstrate how standard HTML elements that convey semantic information implicitly convey roles by default. Demonstrate the use of different roles and how to code them using WAI-ARIA roles.

Learning Outcomes for Topic

Students should be able to:

• determine how to use standard and custom widgets based on accessibility semantics
• explain what element roles mean in the context of Web accessibility
• explain how WAI-ARIA attributes override semantics of the elements they are applied to
• explain how roles allow people using assistive technologies to get information about widget types
• code widgets using standard HTML elements that convey semantic information to the extent possible
• code necessary roles when standard HTML elements do not provide the necessary semantic information

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Show examples of standard and custom widgets such as buttons, checkboxes, and lists. Emphasize that widgets created with standard HTML elements that convey semantic information inherit roles by default. However, custom widgets need to have these roles expressed explicitly, especially when using HTML elements with not enough semantic information.
• Compare use of standard and custom widgets with assistive technologies. Explain that accessibility support for WAI-ARIA properties may vary, so checking its current accessibility support is recommended. Mention that ARIA roles override the implicit roles of native HTML elements where it is used. For an explanation of how WAI-ARIA can provide both powerful and dangerous experiences see the WAI-ARIA Authoring Practices Read me first.
• Explain that accessibility properties allow people using assistive technologies to get semantic information about a widget. Mention that widgets requiring extended keyboard interaction put assistive technologies into application mode, where all keyboard and focus interactions are controlled by the author of the widget. Mention that some assistive technologies provide custom hints based on these properties so that people can interact with those widgets more efficiently.
• Show examples of WAI-ARIA roles applied to different types of custom widgets where native HTML elements do not convey enough semantic information. Explain that these roles help assistive technologies determine its type. For a list of roles, see the WAI-ARIA specification roles.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Practical — Students are presented with a set of HTML elements and are asked about the semantics they convey. Assess students’ knowledge of HTML elements and their associated semantic properties.
• Practical — Students are presented with different custom widgets that do not contain accessibility properties and are asked to code them using standard HTML elements to the extent possible. Assess students’ understanding of when to use standard and custom widgets.
• Practical — Students are presented with custom widgets that do not convey roles by default and are asked to assign their roles. Assess how students code roles for custom widgets.
• Short Answer Questions — Students are asked about the different roles that exist in the WAI-ARIA specification. Assess students’ knowledge of the different roles in the WAI-ARIA specification.

Demonstrate the use of appropriate coding patterns to provide accessible names and descriptions when standard HTML elements do not provide them by default.

Learning Outcomes for Topic

Students should be able to:

• explain what accessible names and descriptions mean in the context of web accessibility
• code accessible names that convey the purpose and intent of all focusable and interactive elements
• code accessible descriptions to convey additional information or instructions for elements when necessary
• identify mechanisms that browsers use to calculate accessible names and descriptions based on markup and precedence
• explain how accessible names and descriptions are used by assistive technologies to inform users about the purpose and intent of custom widgets and to provide additional information

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Explain what accessible names mean in the context of Web accessibility. Mention that accessible names are short strings that provide information about the purpose and intent of an element. Mention that descriptions are strings that associate additional information such as instructions or format requirements. For explanations on what accessible names and descriptions mean in the context of Web accessibility, see the WAI-ARIA authoring practices, What are accessible names and descriptions.
• Demonstrate different ways to code accessible names and descriptions, such as naming with child content, using strings in labels or the attribute aria-label, referencing other content in the attribute aria-labelledby or aria-describedby, or using other methods such as legends, captions, or titles. For an explanation about how to code accessible names and descriptions, see the WAI-ARIA authoring practices, Providing accessible names and descriptions. For examples of good practices when providing accessible names an descriptions, see the WAI-ARIA authoring tools Accessible names and Accessible descriptions.
• Mention that browsers use different algorithms to calculate accessible names and descriptions due to the multiple combinations that exist based on the coding patterns mentioned above. Show several browsers and examples of how they may render different accessible names from the same coding pattern. For a set of rules that help avoid mistakes when providing accessible names and descriptions, see the WAI-ARIA Authoring Practices How are name and description strings derived.
• Show how different assistive technologies present the contents of accessible names and descriptions. Explain that some present both types of contents consecutively, but others leave a pause between the accessible name and the accessible description. Mention that sometimes accessible descriptions require additional user input to be revealed by assistive technologies.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Short Answer Questions — Students are asked about the different ways in which accessible names and descriptions can be provided and the precedence of each. Assess students’ knowledge of the different coding mechanisms to provide accessible names and descriptions.
• Short Answer Questions — Students are asked about the different ways in which assistive technologies can present the contents of accessible names and descriptions. Assess students’ knowledge of the different ways in which assistive technologies present the contents of accessible names and descriptions.
• Practical — Students are presented with custom widgets that do not convey their accessible names and descriptions and are asked to provide these properties. Assess how students code accessible names and descriptions for custom widgets.

Show examples of widget states, properties, and values defined in the WAI-ARIA specification, Supported states and properties. Demonstrate the use of such attributes for custom widgets that require additional semantic information.

Learning Outcomes for Topic

Students should be able to:

• identify WAI-ARIA attributes that convey properties, states, and values
• code global states and properties for all host language elements regardless of their role when necessary
• code widget states for user interface components
• mark up properties for draggable elements using WAI-ARIA drag-and-drop attributes
• mark up the relationships or associations between different elements of a widget using WAI-ARIA relationship attributes
• summarize related requirements for designers to style states so that they are distinguishable from each other and from focus indicators

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Provide examples of different WAI-ARIA states and properties. Explain that some convey information about the current widget state, and others provide different types of information such as a particular widget value or characteristic.
• Demonstrate the use of WAI-ARIA global states and properties. Explain that they may be applied to any host language element as they are meant to extend the semantics provided by native elements. For examples of global attributes, see the WAI-ARIA specification Global state and properties.
• Demonstrate the use of states and properties for widget roles. Explain that they serve to communicate information about states, user input, and user actions. For reference on widget attributes, see the WAI-ARIA specification Widget attributes.
• Demonstrate the use of properties and values to communicate drag and drop capabilities of a widget. For reference on drag-and-drop attributes, see the WAI-ARIA specification Drag-and-drop attributes.
• Show examples of widgets where the relationships or associations between its components cannot be established via DOM order. Explain the use of WAI-ARIA properties to convey such relationship or associations. For examples of WAI-ARIA attributes that express relationships or associations between widget components, see the WAI-ARIA specification Relationship attributes.
• Demonstrate the use of styling conventions to distinguish widget states from each other. Mention that styling different widget states is a shared responsibility among different team members: designers and developers. For tips on when (or when not) to make states distinguishable, see the WAI-ARIA authoring practices Focus vs selection and the perception of visual focus.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Short Answer Questions — Students are asked about the differences between WAI-ARIA states, properties, and values. Assess students’ knowledge of the WAI-ARIA attributes to convey states, properties, and values.
• Practical — Students are presented with a widget that reveals content based on user action and are asked to code it using aria-haspopup when necessary. Assess students’ knowledge of the WAI-ARIA attribute aria-haspopup.
• Practical — Students are presented with custom widgets that have different states based on user action and are asked to code them accessibly. Assess students’ capacity to code different states and its corresponding values.
• Practical — Students are presented with a widget that allows for drag-and-drop functionality and are asked to code it using WAI-ARIA attributes that convey such functionality. Assess students’ knowledge of WAI-ARIA drag-and-drop attributes.

Demonstrate the use of common keyboard interactions for the custom composite widgets defined in the WAI-ARIA specification, Composite widgets. For example, tabbing, using the arrow keys, or using keyboard shortcuts to perform specific actions.

Learning Outcomes for Topic

Students should be able to:

• explain how keyboard interactions such as use of the tab, arrow, or shortcut keys allow people with disabilities to operate widgets
• code DOM order for carousels, grids, listboxes, single page applications, tabs, trees, and other composite widgets so that it allows for a meaningful sequential focus order
• code the main tab stop and mark the currently visible elements for the above composite widgets using native focusable HTML elements or the attribute tabindex in a non-focusable element
• code keyboard events and key assignments to the components of the above composite widgets such as menus and toolbars to handle focus management within the widget
• code additional shortcut keys to perform specific actions that avoid conflicts with operating systems, browsers, and assistive technologies
• summarize related requirements for designers to ensure that interactive elements are easy to identify
• summarize related requirements for designers to provide different choices for users when selecting options in complex widgets, such as refining a set of search results

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Invite students to use the keyboard to navigate accessible widgets such as carousels, tabs, and treeviews. Explain that tabbing moves between widgets and using the arrow keys moves inside components. Emphasize that there should be only one tab stop per widget on a page, and that additional keyboard interactions are made available only when the widget gains focus. An explanation of these keyboard interactions is provided in the WAI-ARIA authoring practices, Fundamental keyboard navigation conventions.
• Show examples of well formed DOM structures for composite widgets. Explain that a sequential DOM order allows for a predictable keyboard navigation.
• Demonstrate the 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 operate it. For a pointer on what functionality needs to be added for a custom widget to allow keyboard functionality, see the WAI-ARIA Authoring Practices A role is a promise.
• Demonstrate the use of the tabindex attribute to add focus to an element that is not focusable by default. Explain the use of the value -1 to mark up an element so that it can be focusable when it becomes visible or available in a single page application. Explain the 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.
• Demonstrate the 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. Tips on how to make navigation predictable within widgets are provided in the WAI-ARIA authoring practices, section Discernible and predictable keyboard focus.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

• Short Answer Questions — Students are asked to provide all the meaningful values for accessibility that the tabindex attribute can have and to explain what each of those values means. Assess students’ knowledge of the attribute tabindex and its values.
• Practical — Students are presented with a custom 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 custom widgets.
• Practical — Students are presented with a custom list and are asked to code a tab stop for its container layer. Assess how students understand sequential focus order and navigation.
• Practical — Students are presented with a treeview and are asked to code focus management and internal keyboard interactions. Assess how students understand internal keyboard interaction conventions.

Demonstrate and explain the use of live regions to notify users about content updates. For a list of live region properties, see the WAI-ARIA specification Live region roles and Live region attributes.

Learning Outcomes for Topic

Students should be able to:

• code alerts using the WAI-ARIA role="alert"
• code regions that contain dynamic changes using the WAI-ARIA attributes aria-live, and aria-atomic
• mark up the type of updates using the values additions, removals, or all in the WAI-ARIA attribute aria-relevant
• mark up the priority for the updates using the values polite, assertive, or off in the WAI-ARIA attribute aria-live

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

• Demonstrate the use of alert widgets 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. Examples of how to code these alerts are provided in the WAI-ARIA authoring practices Alert.
• Show examples of dynamic regions, such as carousels, chat logs, or feeds. Explain that people using screen readers cannot perceive these types of updates by default as they can only be focused at one thing at a time. Examples of how to communicate the changes using aria-live are provided in the WAI-ARIA authoring practices, Auto-rotating image carousel.
• Demonstrate the 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 the 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 an alert widget 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 people using text-to-speech technologies. Assess students’ knowledge of the types of live regions as well as its roles and properties.
• Practical — Students are presented with different types of alerts. They are asked to indicate their priority level and to code them appropriately. Assess students’ understanding of the attribute aria-live and its values polite, assertive, and off.