Category: screenreader

Categories
apple design ipad keyboard screenreader

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

Categories
screenreader

Detecting Screen Readers – No

There has been much discussion about the idea of detecting a screen reader from a website and optimizing the code. In the W3C editor’s draft IndieUI 1.0: User Context, screen reader detection is proposed. This scares me and many others in the web accessibility community.

In the recent publishing of the WebAIM screen reader survey, one of the questions is “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?”. Surprisingly 54% of respondents replied “Very comfortable”. This sure sparked some discussion on Twitter and on blogs.

For the most part, detecting a screen reader has been ill-received from the accessibility community. I am also strongly opposed to this idea.

The reasoning boils down to two issues: development and privacy. And it’s bad for both. Here are some reasons why it’d be bad for development:

  • Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
  • Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
  • Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
  • Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just a bad idea.

Let’s hope screen reader detection is removed from the W3C draft of IndieUI 1.0: User Context.

PS: Interestingly, @LFLegal recently announced that Safeway is (finally) removing a text-only version of its website in the blog Separate is Not Equal: Good News for Grocery Delivery.

Further reading:

Updated August 2023

Categories
aria screenreader

Easy ARIA from Marco

Here’s a great blog series on ARIA techniques from Marco Zehe (@MarcoInEnglish) of Mozilla. The content is well over a couple years old now, but still very relevant and useful. Goes to show how leading edge Marco and Mozilla are!

Categories
screenreader survey webaim

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:

Categories
google screenreader visual

Response to Accessibility in Google Docs

Read Write Web recently published the article Google Announces Sweeping Accessibility Improvements for Visually Challenged Users. On one hand, this is great news. But on the other hand, Google’s accessibility efforts have been inconsistent, and mostly within their own technologies; as we’ll discover below, not implemented for universal use.

The Google Docs updates have been tested by a screen reader user, Kevin Chao. With permission, the following is taken (and slightly edited) from his web post Google announced and took the wraps off what’s been dubbed “enhanced Accessibility in Google Docs”.

Google announced and took the wraps off what’s been dubbed “enhanced accessibility in Google Docs”

Applaud, Thank, and Appreciate

I certainly applaud, appreciate, and praise Google in their accessibility efforts, but there seems to be this level of accessibility, which includes efficiency, effectiveness, and equal access that Google is far from with all attempts, which Docs is no exception.

Dumbed Down Accesssibility limited UI/Look

Visiting Docs.Google.Com using Firefox and NVDA, either classic or new Look/UI, latter is much worse from an accessibility point, but all is relative, including “enhanced accessibility”. Google is always in in a race with itself, changing elements, such as looks/UI. Often there are different views to pick from, and it’s often the one that is “basic” or “classic” that is more accessible, which leaves screen readers with a dumb-downed experience than an equal experience Compared to the full “standard” or “new” UI/look that everyone else who does not need to use a screen has the luxury of using. There should not be more than one view, if there has to be an experimental/enhanced view, it should be accessible, and it’s very degrading that Google by only putting accessibility resources into the dumbed UI/Look implies that all blind screen reader users are unable to perceive, understand, and work with advance, complex, and rich UI/Looks.

Now, let’s move onto the main focus, which is the enhanced Accessibility in Google docs.

Using Firefox, NVDA, and looking at Docs.Google.com in classic view.

Main UI/Look
  • Navigating by form fields or line will reveal lots of unlabeled Controls, such as “button”, clickable, expanded, checkboxes, and clickable list. It’s bad enough from a user interface, experience, and accessibility standpoint that all these controls do not have proper labels, making them accessible, but there’s more.
  • Instructions indicate to get started, activate create new or upload button, but these are identified as clickable, which do not do anything when pressing ENTER. However, with enough attempts of everything under the sun such as NVDA+CTRL+SPACE, SPACE, mouse click, etc.; it will be possible to activate these buttons. It should not be this difficult, frustrating, and require all these work-around to activate buttons (no, no, they are not buttons, but clickable).
  • When navigating to the expand button, pressing ENTER, NVDA is silent. The new status, which is collapsed, is not conveyed from Docs via ARIA or any accessibility event. In addition, arrowing down does not show any additional content. ARIA Live-regions should be used to alert user of updated dynamic content.
  • Navigating to unlabeled button, pressing ENTER, reviewing contents on screen does not show that anything changed.
  • Lots of items are identified as menus and submenus, which when activated do not work as ARIA jQuery menus, but instead do not do anything, cannot track focus/read, and/or it’s not possible to exit menu/submenu.
  • Effective and efficient navigation is lacking greatly, which could Be improved by use of ARIA Landmarks and headings.
Creating/Editing Docs
  • Browse/upload process does not work by simply using arrows/TAB and ENTER/SPACE, but requires the same level of fighting, frustration, and work-around that was required to get into the upload page.
  • Creating a new doc/opening an uploaded one will open it in a new Tab, which is identified with: document title, app, JavaScript, file type, and editable”. While all this is great, arrowing in document reads absolutely nothing and same goes for tabbing around.

Conclusion

Google has optimized Google Chrome, ChromeVox, and Docs to work very well together. This locked-in and non-universal design towards accessibility should be avoided at all possible cause, which results in not as many people using it due to the need to use a different environment for particular task. One of the many benefits to a cloud solution, such as Docs is the anywhere access on anything, which ranges from desktops to mobiles, which Docs accessibility is far from.

Please, Google, there really needs to be real accessibility present, which includes effectiveness, efficiency, and equal level of access. No more of this Google accessibility, which is half-baked at best.