Category: webaim

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:

About WebAIM Screen Reader Survey 4

As you may have heard, the results of the fourth WebAIM screen reader survey are now available. The survey provides valuable information on about screen reader users such as primary screen readers used, browsers used, and reasons for use.

WebAIM reports that problematic items have changed little over the last 2 years. The top ten are:

  1. The presence of inaccessible Flash content.
  2. CAPTCHA – images presenting text used to verify that you are a human user.
  3. Links or buttons that do not make sense.
  4. Images with missing or improper descriptions (alt text).
  5. Screens or parts of screens that change unexpectedly.
  6. Complex or difficult forms.
  7. Lack of keyboard accessibility.
  8. Missing or improper headings.
  9. Too many links or navigation items.
  10. 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. 

Here are a few great analyses of the survey:

WCAG Improvements

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.

Learning How to Test with Screen Readers

Although accessibility checklists are important, testing for web accessibility requires more than that. Some testing requires tasks which can only be done by a human including testing with a screen reader. It’s best for a regular screen reader user to do the testing, but it’s also good for a developer or designer to do at least the basics (there was a big discussion on this last fall in Should Sighted Developers Use Screenreaders To Test Accessibility?).

Here are some good articles to help learn how to use a screen reader to test for web accessibility:

More from comments:

Podcast #89: CSUN 2011 Preview

Dennis and special guests Jennison Asuncion (@Jennison) and Jared Smith (@jared_w_smith) discuss the upcoming CSUN conference in San Diego, California, at the Manchester Grand Hyatt Hotel, March 14-19, 2011. The official title and website is: 26th Annual International Technology & Persons with Disabilities Conference.

NOTE: Apologies for the poor quality. (But the content is outstanding!)

Download Web Axe Episode 89 (CSUN 2011 Preview)

Transcript of podcast 89

Sponsor:
Project:Possibility is a nonprofit organization dedicated to creating open source software that benefits the disabilities community, and educating students on accessibility and universal design concepts. This is accomplished with the SS12 Code for a Cause: an opportunity for students to make a profound difference by developing innovative, empowering projects for persons with disabilities, as well as the chance to work with industry professionals.

Jennison presenting:

  • Building IT Accessibility Awareness and Community Using the Barcamp/Unconference Format. Wednesday, 9:20.
  • Do We Need to Change the Web Accessibility Game Plan? Panel with John Foliot, Sandi Wassmer, and Jennison. Thursday, 3:10.

Jared presenting:

  • HTML5/ARIA pre-conference workshop w/ Steven Faulkner and Hans Hillen of TPG. All day Tuesday.
  • Screen Reader Web Accessibility Face-off. Wednesday, 3:10.
  • Do We Need to Change the Web Accessibility Game Plan? Panel with John Foliot, Sandi Wassmer, and Jennison. Thursday, 3:10.
  • WebAIM’s Screen Reader User Surveys: Data and Trends. Friday, 8am.
  • Preview of WAVE 5 on Friday, 10:40.

More info: