Carousels, Dropdowns, & Modal Dialogs:
Accessibility and common web widgets

Terrill Thompson
University of Washington
These slides:

Take the #nomouse challenge!

#nomouse logo, a computer mouse with a slash through it

Spot the Barrier!

Accessible University 3.0

Screen shot of Accessible University Demo site

Key W3C Resources

Key UW Resources


Screen shot of a carousel

Basic structure:
You have slides...


And you have controls...

And you have a progress indicator...


Most carousels today are inaccessible

  • Evaluated carousels on home pages of 65 departments at a major research university
  • 62 played automatically (95%)
  • 60 offered no accessible means of stopping or pausing (92%)
  • 52 were not operable at all by keyboard (80%)
  • 54 had missing or inadequate alt text on images (83%)
  • Many had color contrast problems

Playing Automatically

  • People who are easily distracted can find it difficult to access other content on the page.
  • People who need more time to read can find it frustrating if the slide advances before they're finished.
  • Option #1 (recommended): Provide a prominent play button. Users can choose whether to explore this feature.
  • Option #2 (minimum requirement): Provide a prominent, accessible pause button.

All images need alt text

Image from slide, needs alt text


And those buttons should be <button>s

And those progress indicators aren't readable, focusable, or actionable


Revised focus indicators

Add aria-live to each slide, so it's announced when it becomes visible


Dropdown Menus

Screen shot of dropdown menu with four items

Basic menu structure


Approach #1: Make it a menu


Approach #2: Make it a nav


Add support for standard keystrokes

The standard: W3C Recommended Design Pattern for Menu

  • Tab gives menu focus
  • Left and right arrows move through top-level menu item
  • Enter, space, or down arrow expand submenu; first item receives focus
  • Up and down arrow moves through submenu; wraps to top or bottom
  • Escape closes the submenu; focus returns to top-level item
  • First character of any submenu item jumps to that item


Screen readers intercept keystrokes for other functions. So our elaborate keyboard model isn't necessarily accessible to screen reader users.

One possible solution: role="application"


Choices and Tradeoffs

  • With role="menu", links are treated as menu items, not links. But screen readers support role="menu" pretty well.
  • Without role="menu", screen readers are less reliable. NVDA in Firefox works well.
  • With role="application", your elaborate keyboard model is fully supported. But other screen reader keystrokes stop working. Can be confusing for users.

My Conclusion Today (which may change tomorrow)

  • Use role="menu"
  • Provide keyboard help
  • Redundantly provide navigation links in the footer

Modal Windows

Screen shot of a modal window

Basic modal structure


Basic CSS

#modalMask { 
  position: fixed;
  top: 0;
  left: 0;
  margin: 0;
  padding: 0; 
  width: 100%;
  height: 100%;
  background-color: black;
  opacity: 0.75;
  z-index: 10; 
#modalContent { 
  position: fixed;
  background-color: #FFC;
  width: 50%;
  top: 25%;
  left: 25%;
  margin: 0 auto;
  opacity: 1;
  z-index: 100;

Show modal and mask, and hide everything else


Add ARIA and other accessibility features to modal div


Manage keystrokes

  • When the window opens, place focus on the first focusable element
  • Trap tab key so it cycles through focusable elements in the modal window only (all other elements are inaccessible)
  • Escape closes the window

On Frameworks and CMSs

Five Action Items

  • Take the #nomouse challenge!
  • Never stop learning about #a11y
  • Always ask "Is this accessible?"
  • Only choose accessible tools, widgets, and products
  • If it's not accessible, fix it! Contribute to a better world.

Done! Back to start

Terrill Thompson
These slides: