Category: keyboard

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

Accessible YouTube & HTML5 Video

YouTube is obviously a great site for video, but not for everyone as it contains various accessibility challenges, particularly keyboard access. The use of Flash itself to play the video can be problematic, not be mention requiring support of the Flash plugin. HTML5 is a pending solution (HTML5 video is available on YouTube as a “trial”), but in its infancy, HTML5 video has accessibility issues that still need to be resolved, as does HTML5 itself.

In the meantime, here are a few alternatives to the YouTube website which provide more accessible controls and a much cleaner interface.

If you still don’t have what you need or want, why not build your own interface?! The following are tools and resources for building more accessible YouTube videos including captioning:

Further reading:

If you developed an accessible YouTube solution, or know of another not listed, please leave a comment.

YouTube logo

Response to Twitter Keyboard Shortcuts

A few nights ago, I submitted a comment to a recent article on Lifehacker, Navigate the New Twitter Like a Pro with Keyboard Shortcuts. My comment wasn’t approved. I also tweeted a reply about the article to @Scobleizer and Twitter employee @rsarver. Received no response there either.

The article to which I was responding glamorizes New Twitter’s keyboard shortcuts. I take offense to this so-called “feature” because the Twitter.com website itself is not accessible to users of keyboard-only input devices (which includes many types of assistive technology). And like all websites, Twitter.com should be accessible to anyone, not just to those who are able to use a mouse (device independence, see WCAG 2.0 Guideline 2.1). Does everyone see the irony here?!

So what my argument boils down to is this: if a website offers special keyboard shortcuts, it should first ensure that the it is fully keyboard accessible.

Here is my comment and Tweet below. Did I overreact?

Unapproved article comment:

This sickens me. Twitter isn’t keyboard accessible, period. Users of assistive technology can’t access the website. People who use a screenreader (visually impaired) or another type of keyboard-only input device (mobility impairments) are nearly completely blocked and makes Twitter.com useless. New Twitter is even worse than the old Twitter site. The so-called keyboard enhancements are an insult to those with disabilities. Fortunately, there is a web-based Twitter app that pays attention to everyone (and web standards, too). It’s called AccessibleTwitter.com.

My tweet reply:

.@Scobleizer Not valuable to users of keyboard-only devices; Twitter.com isn’t accessible to assistive tech. /cc @lifehacker @rsarver #a11y

Colorblind, Law, and Lightboxes

Color Sensitive

I usually shy away from About.com, but I recently came across a piece worth mentioning. In the article Are Your Web Pages Color Sensitive? from the HTML/Web Design section, Jennifer Kyrnin provides some good information and techniques for web development with color blindness in mind. Here are some good tips from Jennifer:

  • Don’t use only color to indicate something specific on your page.
  • Desaturate your images to see if they still have impact.
  • Avoid placing red and green together.
  • If you can, find a color blind friend or relative to look at your site.

Did you know that color blindness is an issue with 8 to 12% of males of European origin?

Law Needed

In his blog Yes, we need accessibility laws, Eric Eggert gives an argument for why we need better laws for web accessibility. He states that a good accessibility law should do:

  • Create awareness.
  • Do not create a climate of fear.
  • Create mediations.
  • Reference international standard.
  • Be inclusive.

Lightboxes

In the article Lightboxes and keyboard accessibility from 456 Berea Street, Roger Johansson describes how a lightbox should function with a keyboard. He states:

  • Let me use the left and right arrow keys to step through images in a slideshow.
  • When I press Esc, close the lightbox.
  • Do one of the following:
    • Either add focusable elements (links or buttons) for close/next/previous, put keyboard focus on the first focusable object in the lightbox, make sure I can’t tab to something behind the lightbox, and make it visually obvious which object has keyboard focus.
    • or close the lightbox when I press Tab.
  • When the lightbox closes, return keyboard focus to where it was when I opened it.

In addition, Roger cites the following two articles:

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/