Category: tab

About Carousels and ARIA Tabs

Jared Smith (@jared_w_smith) of WebAIM recently launched a clever web page on why carousels are not good practice called Should I Use A Carousel? (which totally went viral on its launch day!) There is a slide deck Keyboard and Interaction Accessibility Techniques (on Slideshare) for which this website was made. I was fortunate enough to see Jared present this at Open Web Camp 5 July 13 at PayPal.

Jared presenting at OWC5

I don’t think that a carousel itself is super terrible. But in my experience, carousels are hardly ever coded with accessibility in mind and hardly ever designed with decent usability. In addition, supporting smaller devices is an issue and coupled with the poor usability data, carousels are overall a bad idea. If you absolutely must implement a carousel, here are some design/interaction tips:

  • Let the user start the carousel animation.
  • Give the user the ability to pause the carousel.
  • Ensure the controls have textual labels.
  • Ensure the control of the currently displayed panel is indicated visually and programmatically.
  • Ensure the controls have ample hit areas (for mobile, fine motor disability).

On the development side, a carousel can be challenging to make screen reader accessible. It seems that the most straight forward approach is to use the ARIA tab model which is pretty straight forward and fun to do! Here’s a summary of what to do in the markup:

  • Each carousel content container has a role of tabpanel.
  • Each control, typical designed as dots, has a role of tab.
  • The container of the controls/tabs has a role of  tablist.
  • Add aria-labelledby to the tabpanels which point to the id of the associated control/tab.
  • To each control/tab, add aria-controls (which points to the id of the associated tabpanel) and aria-selected (boolean) attributes.

Here are some code resources to help make sense of this. This first by Marco may be most relevant:

More:

Keyboard Accessibility from Lauke

Patrick Lauke’s keyboard accessibility presentation at Future of Web Design Tour 2009 in Glasgow. September 14. Keyboard accessibility – basic steps towards a more usable and accessible site. Keyboard Access for Google Map

  • If you style :hover, also :focus and :active.
  • Don’t suppress outline completely (reintroduce :focus and suppress :active).
  • Leave tabindex alone – source order.
  • JavaScript on hover (mouseover/mouseout) also on focus/blur (if focusable element).
  • Lightboxes have issues.
  • Only attach behaviour to focusable elements.

MORE:
Keyboard-accessible Google Maps
http://dev.opera.com/articles/view/keyboard-accessible-google-maps/

Enhanced Keyboard-accessible Google Maps
http://learningtheworld.eu/2009/keyboard-accessible-google-maps/

Tab Index – why and why not

WCAG Guidelines 9.4 (Priority 3) says to create a logical tab order through links, form controls, and objects. The “tabindex” attribute is great because it does exactly that — it specifies the position of the current element in the tabbing order for the current document. But are they needed?

Download Web Axe Episode 24 (Tab Index — Why)

[Transcript]

The basic code:


Links: