Digital accessibility experts are often asked about the usage of screen readers and assistive technologies. For example, one will often ask “What’s the most popular screen reader?” This is difficult (if not impossible) to determine technically, but also has privacy implications and other problems.
The following two surveys provide great data and are provided by very reputable organizations. Keep in mind though that the respondents were not controlled and the sample sizes are relatively low.
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:
WebAIM reports that problematic items have changed little over the last 2 years. The top ten are:
The presence of inaccessible Flash content.
CAPTCHA – images presenting text used to verify that you are a human user.
Links or buttons that do not make sense.
Images with missing or improper descriptions (alt text).
Screens or parts of screens that change unexpectedly.
Complex or difficult forms.
Lack of keyboard accessibility.
Missing or improper headings.
Too many links or navigation items.
Complex data tables.
Conclusions from the survey include:
JAWS is still the primary screen reader, but usage continues to decrease as usage of NVDA and VoiceOver increases.
The perception of accessibility of web content is decreasing.
72% of the respondents use a screen reader on a mobile device, up from only 12% three years ago.
iOS device usage is significantly increasing and well above that of the standard population. Screen reader users represent a notable portion of the iOS device user market. Usage of Android devices is well below that of non-disabled users.
The use of properly structured headings remains of great importance.
It was such a relief when WCAG 2.0 became a W3C Recommendation back in December of 2008. But in the fast paced world of the web, nothing stays the same for very long. Even WCAG could use many improvements, especially after over three years. (Time sure flies!)
Jared Smith (@Jared_W_Smith) of WebAIM recently wrote an excellent article WCAG Next which explains some of the top issues and suggests how they can be improved. I pretty much agree with all. Here is a summary:
Remove the CAPTCHA Exception – should prohibit all CAPTCHA at Level AA.
Media Guidelines – a few suggestions here plus a recommendation for restructuring.
Contrast at Level A -minimal contrast requirement needed for Level A.
Decrease the 200% Text Resizing Requirement -biggest burden of Level AA.
Clarify Images of Text -this is subjective.
Specify Mechanisms to Bypass Blocks – add techniques such as skip-to, headings, landmark roles, and others.
“Can Be Programmatically Determined” -a confusing aspect of page conformance.
Require Keyboard Focus Indicators at Level A – “There is no reason why this should not be a Level A requirement.” Totally!
Remove Parsing Requirement – no direct benefit and difficult to test for accessibility; possibly move code validation requirement to Level AAA.