This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

Module 7: Rich Applications  in Developer Modules, Curricula on Web Accessibility

Introduction

Courses based on this module should:

Learning Outcomes for Module

Students should be able to:

Competencies

Skills required for this module:

Students

Instructors

Topics to Teach

Topics to achieve the learning outcomes:

Topic: Structure and Relationships

Refer back to Module 1: Page Structure and explain the importance of proper structures and semantics within applications just as within less dynamic web pages. Demonstrate how assistive technologies rely on clearly identifiable sections and regions. Explain how content that is dynamically generated, for example through JavaScript, needs to be properly reflected in the DOM.

Learning Outcomes for Topic

Students should be able to:

  • explain how structures and semantics enable people with disabilities to orient themselves and navigate within applications
  • ensure that applications and dynamically generated content have appropriate markup structures and semantics, including:
    • sections, regions, and corresponding identifiers for these
    • sections of content, such as lists, paragraphs, and tables
    • widgets, including menu bars, form controls, and custom widgets
  • identify and write code for any relationships between different sections of content within the application, for example groups of widgets that share the same purpose
  • ensure that the order of content within the application follows a meaningful sequence in the DOM and visually, including when content is added, removed, hidden, and displayed
  • ensure recognizable and consistent naming of widgets, including widget states, in particular when they appear multiple times within an application
  • describe the impact of large amounts of client side code on assistive technologies and older computer technologies that some people with disabilities may be using
  • describe related requirements for content authors and designers to provide clear layout and designs that support different viewport sizes

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

  • Demonstrate navigation between several widgets in an application using assistive technologies, such as text-to-speech and voice interaction. Explain how these components show and hide depending on user action. For example, when the user goes to the menu bar, the main text area, or a toolbar, another application widget may be hidden or greyed out. Emphasize that these states need to be programmatically marked up by updating, adding, and removing the corresponding elements from the DOM.
  • Demonstrate the use of voice commands, keystrokes, and gestures provided by assistive technologies and adaptive strategies to query for applications titles, headings, and regions. Explain that such elements need to be updated using DOM management techniques to reflect the current state of the application, such as when a new view has been selected.
  • Demonstrate overall interaction with rich applications using assistive technologies. Compare examples where assistive technologies communicate the elements that are displayed with other examples where assistive technologies may access information that is not currently on screen. Emphasize that document object model layers should be added and removed depending on the application view, so that assistive technologies only access the ones that are visible.
  • Discuss different mechanisms to hide content from view, from the accessibility tree, and from both, such as the WAI-ARIA attribute aria-hidden, the HTML attribute hidden, and the CSS property display:none. Explain that code needs to reflect the current state of each of the application widgets.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

  • Practical — Give students a rich application containing different views and ask students to code mechanisms to update titles, headings, and regions depending on the currently visible section. Assess students’ knowledge of how to code updates for application structural components.
  • Practical — Give students a rich application containing different views that show and hide based on user interaction and ask students to update the DOM structure accordingly. Assess students’ knowledge of how to provide a coherent DOM structure depending on the displayed application widgets.
  • Practical — Give students an application with content that can be shown to and hidden from the user; for example, an application to create presentation slides. Ask students to ensure that the code reflects the shown and hidden states of the content; for example, by using the WAI-ARIA attribute aria-hidden, the HTML attribute hidden, and the CSS property display: none. Assess students’ knowledge of how to code displayed and hidden states of application views.

Topic: Keyboard and Focus Interactions

Build on the Topic Keyboard and Focus Management in Module 6 to extend the concept to entire applications with multiple widgets. Demonstrate the importance of consistent keyboard commands and predictable behavior across the entire application. Explain how change of screens in Single Page Applications (SPA) and modal dialogs require particular focus management.

Learning Outcomes for Topic

Students should be able to:

  • explain how people with different types of disabilities interact with widgets, including keyboard only and voice interaction users, and how keyboard commands, including tab, arrow, and shortcut keys, are used to operate widgets
  • explain how people with different types of disabilities rely on focus indicators that are provided in the code and visually
  • write code to enable applications to be operated using the keyboard only and other input devices, such as voice interaction
  • ensure consistent use of keyboard commands, including tab, arrow, and shortcut keys, across the entire application
  • ensure that navigating through different parts of the application does not initiate change of context without prior notice
  • ensure that the focus is placed appropriately when new screens are generated in Single Page Applications (SPA); for example, at the beginning of the content to replicate the behavior of page reloads for assistive technologies
  • ensure that the focus is placed appropriately when inline error messages are generated for application form controls
  • write code to place focus in modal dialogs at the beginning of the dialog, to confine focus to the dialog until it is closed, and to return the focus to the appropriate place in the main content after the dialog is closed
  • identify when changes in applications, such as adding, removing, and updating content, impact the current focus and sequence of content, and write code to restore appropriate focus and meaningful sequence when such changes occur
  • describe related requirements for content authors and designers to provide distinguishable styles for focus indicators

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

  • Explain that the tab sequence needs to be preserved so that keyboard users can navigate across the different widgets and content areas of applications, such as different toolbars and menus. Emphasize that native HTML elements are recommended regardless of the nature of the application in use, as they inherit all the necessary semantic properties that make them usable with the keyboard.
  • Demonstrate use of common shortcut keys for rich applications, such as to create a new message in a web-based email client or to move to the menu bar in a web-based word processor. Explain that these shortcut keys should avoid any conflict with key combinations of both browsers and assistive technologies. Emphasize that application functionality should rely as much as possible on standard keyboard conventions and on expected navigational mechanisms, as non-standard keyboard shortcuts may sometimes be difficult to remember for some users or impossible to use due to their specific configurations.
  • Demonstrate assistive technology interaction with rich applications such as Single Page Applications (SPA). Explain that assistive technologies may not perceive content changes by default unless there is a page reload. Emphasize that each time the view changes, a message indicating the currently selected view should be provided to assistive technologies via a live region.
  • Explain techniques to set focus to the most relevant place in an application, such as a newly loaded screen, a form control containing input errors, the default button in a dialog, and the control that originated a modal dialog. Mention that coding keyboard and focus interactions is a developer’s responsibility, whereas defining such interactions is a responsibility shared with the designer.
  • Demonstrate the use of mechanisms to communicate information about the available keyboard shortcuts in rich applications, such as web-based email clients, spreadsheets, and word processors. Explain that when an application makes extensive use of non-standard keyboard shortcuts, a mechanism that provides users with information about these shortcuts is necessary. Mention that coding these messages is a developer’s responsibility, whereas providing them is a responsibility shared with the designer.
  • Demonstrate accessible and inaccessible modal dialogs. Emphasize how focus remains within the boundaries of the dialogs when they have been coded appropriately. Explain that content that is not part of the modal dialog should not be focusable as long as the modal dialog is displayed.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

  • Practical — Give students a Single Page Application (SPA) with several screens that show and hide based on user interaction. Ask students to set focus to the specific displayed widget. Assess students’ knowledge of how to place focus on a specific application widget based on its state or relevance.
  • Practical — Give students an application that makes extensive use of non-standard keyboard shortcuts and ask students to code a help widget that explains such keyboard shortcuts. Assess students’ knowledge of how to provide specific help based on the implemented application keyboard shortcuts.
  • Practical — Give students an application containing modal dialogs and ask students to set focus to the most relevant place based on user interaction. Assess students’ knowledge of how to set focus to the dialog when it appears and to the element that originated it when it disappears.

Topic: Concurrent Notifications

Build on the Topic: Notifications in Module 5 to extend the concept to entire applications with multiple widgets. Explain how notifications from different parts of the application need to be queued and prioritized to avoid overloading and confusing users. Demonstrate how unobtrusive and coordinated notifications benefit people using different types of assistive technologies.

Learning Outcomes for Topic

Students should be able to:

  • explain how multiple concurrent notifications could occur in applications and describe ways to prioritize such notifications
  • identify and write code for the appropriate values polite, assertive, and off for WAI-ARIA aria-live regions across entire applications
  • identify and write code for relevant updates using the WAI-ARIA attribute aria-relevant with the values additions, removals, and all
  • identify and write code for status messages that may originate from any particular widget or part of the application using the WAI-ARIA role="status"
  • write code for alerts using WAI-ARIA role="alert" and identify situations in which it is appropriate to interrupt users
  • write code for messages containing non-essential information using the WAI-ARIA role="log", and role="marquee",
  • write code for numerical counters using the WAI-ARIA role="timer"
  • write code to switch notifications on and off to avoid conflicts with assistive technologies presenting several notifications at the same time
  • describe related requirements for content authors and designers to provide clear and concise notifications

Teaching Ideas for Topic

Optional ideas to teach the learning outcomes:

  • Demonstrate interaction to request data from applications, such as making a data request for new emails and operating an address lookup. Explain that these data exchanges could be skipped by users of assistive technologies if they are not marked up correctly. Emphasize that live regions to indicate that new data is being loaded and that there is a waiting time should be provided so that users are aware of what is going on.
  • Compare accessible and inaccessible examples of applications confirmation messages warning about critical errors that can cause data loss, and progress bars indicating timeouts. Explain that, when these messages are populated, these should be given high priority in the list of the live regions so that users can take action to avoid data loss and to solve the problem.

Ideas to Assess Knowledge for Topic

Optional ideas to support assessment:

  • Practical — Ask students to code an alert to prevent users from quitting a word processor without saving changes. Assess students’ knowledge of how to use assertive live regions to provide such alerts.
  • Practical — Give students a Single Page Application (SPA) with several views and ask students to code the messages for assistive technologies to indicate what is the currently loaded view. Assess students’ knowledge of how to use polite live regions to provide individual notifications based on the currently selected application view

Ideas to Assess Knowledge for Module

Optional ideas to support assessment:

Teaching Resources

Suggested resources to support your teaching:

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.