Link Roundup – Feb 2015

Some excellent recent resources on web accessibility:

Layout Tables Tip

It’s 2015, so hopefully web developers know that table elements should not be used for layout. There are many reasons why CSS for layout is better but at the core, HTML tables are data tables; they’ve always been meant for data.

But even today, sometimes a table is used for layout, for whatever reason—time constraints, lack of CSS skills, legacy code, etc.

If a table is used for layout, add ARIA role of presentation to the table element. This will remove the table elements from the Accessibility API which provides for a better user experience for users of assistive technology, particularly screen readers.

Other elements such as caption, summary, and thead should be removed. See the Microsoft resource ARIA Presentation Table Error.

Here’s a code example derived from a W3C example for the use of role=presentation. The following code in the HTML tree:

<table role="presentation">
<tr><td>Foo bar</td><tr>
</table>

Becomes this in the accessibility tree:

<>
<><>Foo bar</></>
</>

Further reading:

Apple’s Inaccessibility

Apple has traditionally been a great advocate and model for accessibility and technology. Unfortunately this hasn’t been the case lately. One could even argue that default settings and recent designs are even counterproductive to accessibility progress. This includes VoiceOver, keyboard access, and design decisions.

Bug Infested

To begin, let’s reference a recent article by Marco Zehe where he explains major VoiceOver bugs in OS X 10.10 (Yosemite) and iOS 8. The two major examples he cites are:

  • When VoiceOver is running on the iPhone, using the Back button (or Scrub gesture to return to the previous page) will freeze VoiceOver.
  • When VoiceOver is running on the iPad, using Safari and the use of WebView components trigger app crashes and OS restarts.

In addition to bugs, I’ve noticed the following blatant accessibility problems pop up in Apple’s products. Each of these alone may not be a showstopper but collectively it shows a pattern of a company that doesn’t care, or pay much attention any longer; a company that’s losing its edge.

VoiceOver Hints

By default, VoiceOver places a large delay when announcing “hints”; this creates a huge lag for the reading of text defined by the aria-describedby attribute. And we all know that the support of aria-describedby is becoming more and more prevalent and essential in today’s world of modern web development. The delay is so long that it creates confusion; developers and testers very often think something is broken.

To “fix” the setting, you must find the deeply buried option and modify the delay time; in System Preferences, go to Accessibility / VoiceOver / VoiceOver Utility / Verbosity / Announcements (in OSX 10.9, it’s the the last setting).

Keyboard Access

A great example of Apple’s inaccessibility is the setting for keyboard focus; by default it doesn’t allow for typical keyboard navigation! A user cannot use the tab key to access all controls in an interface. In order to fix, one must again, search for the appropriate settings and modify. Again, this can be confusing and frustrating for developers and testers, let alone regular users.

To fix, the first step is to go to System Preferences / Keyboard / Shortcuts, and in the last section “Full Keyboard Access”, ensure the radio options “All Controls” is selected.

Let’s refer to the follow articles for more details on how to resolve which includes specific browser settings:

Design Problems

There are two major design issues by Apple recently which hinders accessibility: animations and parallax effects, and flat design.

There are many vestibular-related issues in Apple’s design, most notably during the release of iOS7. The issue continues to iOS8 although iOS settings are now available to help resolve the issue. To reduce parallax-type effects in iOS, go to Settings / General / Accessibility / Reduce Motion.

Also, iOS flat design (and the trend in general) is bad for usability and accessibility. Mostly because flat design creates ambiguity between elements; as the Nielsen Norman Group report states, “flat design hides calls to action“. And by implementing flat design, Apple indirectly encouraged others to do the same.

In addition to Nielsen Norman Group’s finding, another usability expert Steve Krug agrees that flat design is a detrimental practice. Here’s a quote from his book which was tweeted last May:

Hope and Warning

Let’s hope Apple returns to the practice of releasing quality products: everything just works and accessibility is continually improving. And fair warning, after the mobile wars a few years ago, Google tops Apple in mobile operating systems; will accessibility be next?

Related Reading

2014 Year in Review

2014 was surely a much busier year than expected. It started a bit slow, but sure got busy!

In the most recent blog post, the hot topic of Google’s new version of reCaptcha dubbed “No Captcha” was addressed. Although there are remaining challenges, Google’s No Captcha Shows Some Progress.

In a guest post by Jennison Asuncion, a new date for Global Accessibility Awareness Day (GAAD) was announced. It’s now the third Thursday of May.

In the post Floated Labels Still Suck, problems and fixes are discussed for the terrible design pattern of putting input labels inside input fields.

Great progress for accessibility continues in WordPress; a podcast with two WordPress contributors, Joe Dolson (@JoeDolson) and Joseph O’Connor (@accessibleJoe), was published in September.

Web Axe author Dennis Lembree read Steve Krug’s excellent book, “Don’t Make Me Think, Revisited” and Twittered a series of accessibility-related points. The series was published in the post Tweets quoting “Don’t Make Me Think, Revisited”.

In May, I announced that Easy Chirp now provides accessible images for Tweets. This feature is badly needed and isn’t available on any other Twitter app. Unfortunately, and surprisingly, the feature is grossly underused.

In March, we posted a summary of CSUN14, the 29th Annual International Technology and Persons with Disabilities Conference. It was another great event; thanks again to California State University, Northridge. (Look for Dennis at CSUN15!)

On a more personal note, Web Axe author Dennis Lembree released an open-source Accessible HTML5 Video Player in September via his day job at PayPal. He recently changed jobs and is now Product Manager, Accessibility at eBay.

More from 2014:

Google’s No Captcha Shows Some Progress

It sure was exciting when Google’s new reCaptcha was announced last week. Dubbed “No Captcha”, the goal of course is to provide a service that determines a human from a bot in order to prevent spam and abuse of online forms.

Derek Feathersone (@feather) from Simply Accessible was one of the first to report its accessibility impact in the blog post On the Accessibility of Google’s No CAPTCHA. The tone of the post is very positive, but the testing cited excludes JAWS with IE (still the most popular screen reader combination) where I found the No Captcha failed miserably. On the bright side, it passes with keyboard-only, Dragon Naturally Speaking, NVDA and the latest VoiceOver.

Two fundamental problems with No Captcha is that it requires JavaScript and it doesn’t work with touch devices.

You can try the No Captcha yourself on a test page hosted by Alastair Campbell (@alastc).

checkbox with label "I am not a robot"
Google’s “No Captcha” reCaptcha

At best, No Captcha simplifies the Captcha experience. At worst, it excludes some users even more than the previous version. Hopefully Google will fix the current issues, especially support for JAWS.

My recommendation is to continue using non-Captcha security techniques; two great articles on how to do so are Spam-free accessible forms by WebAIM and 10 Things to Check Before Using a CAPTCHA by SitePoint.

Related: