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:
Here are some large companies’ accessibility Twitter accounts, and other important related links. Follow for great information. Most of the descriptions are taken from the Twitter bio.
@PayPalinclusive – An official feed from the PayPal Accessibility Team and related initiatives. For account-related issues, contact @AskPayPal. San Jose, California. No longer active.
@IBMaccess – Official IBM Accessibility Twitter account. Managed by @timjpowers & @Mac690 and follows the IBM Social Computing Guidelines. San Jose, CA · ibm.com/able
@w3c_wai – not really a “company” but the owner of WCAG. Nuff said.
@STCaccess – [Society for Technical Communication] Tweets from the SIG (Karen and Cyn) about accessibility issues for technical communicators, spiced with dashes of usability and other goodies. stc-access.org
@BBCOuch – blog and radio talk show on the BBC with a focus on disabled people and diverse stories. London · bbc.co.uk/ouch/
Unbelievable and embarrassing. Is this a new low for CAPTCHA and also for the White House? Let me explain.
In order to sign an online petition by the White House to make books globally accessible to the blind, one must register an account. The fail point is that to register, one must complete a Captcha and the audio version is indecipherable. Therefore, blind folks cannot sign a petition advocating equality for the blind!
A very sad irony.
Here’s an example of the audio Captcha required to decipher in order to register to complete the petition. Because it’s impossible to decipher, the website does not meet Section 508 requirements as the White House claims.
Unfortunately there is still no clear solution to the Captcha accessibility and usability issues. For now it seems a combination of other techniques (see links below) is the best way to go.
