Content Recap

Unit 1 Summary

Unit 1 focused on getting started and providing the background information on the WAI-ARIA specification. The jQuery plugin being developed was also introduced, and access to the inaccessible versions of the widgets that make up the plugin, also known as the activity files, was provided on GitHub. You were also introduced to a MooTools WAI-ARIA library and another jQuery library that can also be used to quickly add WAI-ARIA to interactive web elements.

Though the focus here is on jQuery, the application of WAI-ARIA with other JavaScript frameworks will be quite similar. Developers are encouraged to apply what they learn via jQuery to other libraries they may be working with.

In Unit 1, you were also introduced to the ChromeVox screen reader. Though not a screen reader people who are blind would often use, ChromeVox is an ideal tool for developers to test accessibility in their day-to-day development work.

Unit 2 Summary

In Unit 2, a more detailed description of WAI-ARIA was provided, with a discussion of when and when not to use it; understanding WAI-ARIA roles, states, and properties; as well as differences between static and dynamic application of WAI-ARIA. Though some WAI-ARIA can be added directly to HTML as static attributes, in many cases WAI-ARIA is added dynamically as needed using JavaScript. We also looked at support across assistive technologies (AT) and web browsers. Currently (as of Novermber 2019), support is varied across these technologies but improving constantly.

We also introduced graceful degradation and progressive enhancement as development methods that can be employed to ensure that elements that may not yet be supported across all technologies have alternatives available as fallbacks, ensuring features are functional regardless of the technology being used. Despite the variation in support for WAI-ARIA, developers are encouraged to use it now, with the assumption that support for it will continue to improve over the coming years.

We also introduced LightHouse and aXe, two tools that can be used to validate WAI-ARIA to ensure it is being used correctly. These tools can be added to Chrome, along with ChromeVox (introduced in Unit 1), to have a collection of accessibility testing tools at your fingertips when developing for the Web. Finally the WAI-ARIA Taxonomy was introduced to help participants visualize the structure and relationships between WAI-ARIA roles, states, and properties.

Unit 3 Summary

In Unit 3, you built upon your understanding of WAI-ARIA with some practical implementations by looking at landmarks for implementing within page navigation for screen reader users, alerts and messages for providing easy access feedback, the new tabindex values 0 and -1 used to add keyboard access to elements that do not typically have keyboard access, and development of roving tabindexes that add and remove keyboard access as needed as users interact with a widget or application.

We also looked briefly at the WAI-ARIA application and presentation roles. The application role is typically used with embedded web applications where keyboard interaction needs to be intercepted so the application itself is being operated on rather than interacting with the assistive technology (AT) or the web browser. When using the application role, care must be taken to not disable other critical interactions with the web browser or AT and create unintended barriers when standard functionality becomes disabled.

The presentation role is used to hide elements from screen readers. They are typically used to hide table semantics when they are used for layout and to hide away images that are decorative. In the latter case, the presentation role works much like a null alt attribute would. Like the application role, care must be taken when using the presentation role to ensure meaningful information about the content is not being removed inadvertently.

Finally, we introduced live regions as a way to present updating information in web content. Typically, a screen reader processes the HTML of a page when it loads, and when content in the page changes, such as a newsfeed adding a new headline, they may not notice that change. Live regions are a way to make that updated information available to a screen reader, but care must be taken to ensure that information that updates frequently does not interfere with a screen reader’s ability to read content elsewhere on the page.

Unit 4 Summary

In Unit 4 and the two units that follow, the focus moved to the practical implementation of WAI-ARIA, looking at specific interactions and the types of information that need to be available to assistive technologies to ensure these interactions are accessible to users of these AT.

In this unit, we looked specifically at:

• Suggestion Boxes: Instructions were provided on how to use the suggestion box, which provides suggested terms as letters are typed in, based on those letters. A live region was added to announce suggestions, and keyboard access was provided through the arrow keys scripted to navigate the suggestion list.
• Tooltips: When a parent element with a tooltip receives focus, the tooltip appears in a live region and reads out loud. When focus moves away, the tooltip disappears.
• Progress Bars: Instructions were provided on how to operate the progress bar with a keyboard to announce the status of the progress and indicate how far along progress is.

Unit 5 Summary

In Unit 5, the widgets got a little more complex. These included:

• Sliders: A slider bar and a slider thumb were created, minimum and maximum values were set for the slider bar, and an increment was set for the slider thumb, with each movement of the thumb moving a specific distance along the slider bar. Instructions were provided on how to operate the slider, with arrow keys used to move left and right across the slider bar, and Home and End keys used to move the slider thumb between the start and end of the slider bar.
• Accordions: Two types of accordion interactions were introduced: single or multiple accordion panels. They were each opened one at a time and opened or closed by toggling accordion headers with the Enter key or space bar. The Tab key was used to navigate into an accordion, to navigate from one header to another, or to navigate from a header to its associated panel. Arrow keys were also used to navigate between accordion headers but not to their associated panels.
• Tab Panels: Much like accordions are used to conserve space, tab panels provide similar functionality, though typically content is arranged horizontally whereas accordions typically arrange content vertically. The Tab key is used to navigate into the tab panel’s tabs, from tabs to their associated panels, and to exit the tab panel. The Left and Right Arrow keys are used to move between tabs, and when a panel has focus, Shift + Tab is used to return focus to the tab list. The semantics of the list used to create the tab panel are replaced with tab panel semantics.
• Carousels: Again, carousels are used to conserve space, presenting a series of slides or panels that contain images and text. A carousel typically rotates between panels automatically. When the Tab key is used to enter the carousel, automatic rotation stops, allowing users to spend as much time as they need to consume the information on each panel. The Left and Right Arrow keys are used to move between panels in the carousel. When the carousel has focus, a live region is created using the containing <div>, so as each slide comes into view its content is automatically read. When the Tab key is used to exit the carousel, the live region is removed and auto-rotation is restored. Removing the live region ensures the content of the slides does not continue to read out loud while the user is navigating other areas of the page.

Unit 6 Summary

In this final unit, the widgets got more complex yet.

• Menu Bars: Menu bars typically appear as a set of nested lists, with the top level list arranged horizontally across the top of a page and sublists acting as submenus. Specific menu bar and menu WAI-ARIA attributes were used to replace the list semantics with menu semantics, making them easier to understand when operating them with a screen reader. The Tab key is used to enter and exit the menu bar. Arrow keys are used to move between menu items, the space bar is used to open a submenu, and Esc is used to close an active submenu.
• Tree Menu: Tree menus often appear down the side of a page and include top-level topics and related subtopics that expand or contract with a toggle. Subtopics may open several levels deep. The Tab key is used to enter and exit the tree menu, and Up and Down Arrows are used to move between the menu items that are displayed. A roving tabindex is used to prevent focus on menu items that are not being displayed. When a menu item is accessed that has subtopics, the space bar or the Enter key can be used to toggle submenus open or closed. When a menu item with a submenu receives focus, its state — expanded or collapsed — is announced by the screen reader. At any time while in the tree menu, pressing the Tab key exits the menu.
• Sortable List: The sortable list is a type of drag and drop widget. Many of these currently found on the Web are difficult or impossible to use with a keyboard alone, making them inaccessible to many users. The Tab key is used to enter and exit the list. Instructions are provided on how to operate the list using a keyboard. Up and Down Arrows are used to move up and down through the list. As list items receive focus, they announce as movable to indicate that they can be rearranged. Pressing Command, Alt + Ctrl, or just Alt — depending on the browser and operating system — along with the Up or Down Arrows, moves an item to an adjacent location in the list, announcing the new location for that item.