This article originally appeared in TidBITS on 2015-01-26 at 10:06 a.m.
The permanent URL for this article is: http://tidbits.com/article/15365
Include images: Off

Computing for the Visually Impaired, Part 3

by Mariva H. Aviram

Learning about the physiology of the eye gave me insight (so to speak) into the causes of visual impairments. In “Computing for the Visually Impaired, Part 2 [1]” (19 January 2015), two eye care practitioners weighed in on the importance of maintaining a healthy tear film, which requires conscientious attention to the mundane task of regular blinking. This is especially important during the intensive computer use that is notorious for engendering poor eye health habits. Now I’ll shift the focus to the myriad obstacles that visually impaired users face with computer operating systems and software interfaces.

My temporary visual impairment exacerbated the everyday frustrations that I experience while using computers and smartphones. Without a visual impairment, I could dismiss these low-level frustrations without thinking. If dealing with the constant annoyances of typical computer use is like waving away a gnat, attempting to navigate the same systems while disabled is akin to negotiating with a swarm of wasps. My list of complaints was (and is) legion:

Bear in mind that these problems arose during light computer use; I wasn’t using complex software (such as graphic design or audio production apps) or attempting to accomplish anything extraordinary. What should have been simple tasks of navigating the Mac OS interface and reading text-centric Web sites were often too difficult and frustrating to justify the effort.

Web Forms -- My brother shared his frustration with poorly designed Web forms. Web forms — like all other interfaces — should be fully keyboard accessible. “A well-designed form,” he said, “should enable me to tab from field to field, and press Shift-Tab to navigate backward through previous fields. Unfortunately, the default behavior of Safari and some other browsers is to tab only through text fields, [skipping] checkboxes, drop-down menus, radio buttons, etc., forcing me to use the mouse.” (Luckily, you can control browser tabbing behavior in each browser’s Advanced preferences.)

He continued:

Very often, after submitting a form, I find that the application rejects it on a first try because I am missing some item. This generally happens when the form is not so well organized as to make the location of each successive field predictable. Then, the worst situation is when I cannot find the error message, or the error message just says something like “You must complete all the fields” — and then I have to pore over the form, over and over, looking for the field with the missing entry, perhaps annotated with some tiny red text. It would be much more helpful if the error message were in bold text at the top, perhaps on some special background to set it off, and if it specified exactly which field lacked the necessary data.

With such Web form problems, browsers might be able to provide the solution. Just as Safari provides a simplified Reader view of text-heavy Web pages, perhaps browser developers could also provide a simplified Web Form view that would lay out all of the fields of a form in a vertical row, enlarge the Submit button at the bottom, bold error text as described above, and highlight the problematic fields.

Lack of Options — As many Accessibility options as there are, we can always use more. For example, if the operating system and app designers provided the option of color-inverting just text — or text and dialog boxes, or everything (text, dialog boxes, images, menu, Dock, and background) — that would change the adaptive experience enormously. And how about offering users colorblind-friendly palettes?

Also, if a “reducing glass” isn’t in high demand, as I suggested in “Computing for the Visually Impaired, Part 1 [3]” (9 January 2015), then the capability to reduce text size well below the currently smallest setting could be effective. For example, the smallest size of text that Safari allows is 9-point type.

Why this arbitrary lower limit? There’s no good reason that Safari can’t allow 8-point, 6-point, or, for those with Retina displays, 4-point text. Better yet, make it a field so that a user could enter any text size.

Still other users need greater contrast controls, different text sizes and fonts, and a full spectrum of colors adjustments (not just simple inversion).

iOS Annoyances -- Mobile devices present their own challenges. For example, iOS apps continually interrupt me with obnoxiously timed requests to rate and review them. This should be a toggle setting in the General preferences. I’ll rate iOS apps when I want to, not when I’m “reminded.”

More commonly, composing text without a tactile keyboard isn’t easy for anyone, although many of us are used to it by now. (The keyboard and magnifying loupe on the iPhone was so problematic for the illustrious Andy Ihnatko that he switched to Android [4].) For visually impaired users, though, flipping back and forth between the keyboard and the text field without losing one’s place is an exercise in not losing one’s mind. (A physical keyboard case might help, especially with the problem of navigating through text.)

To circumvent the cursor-and-loupe rigamarole, Apple added right- and left-arrow keys (though not up- and down-arrow keys) to iOS 8, but only in landscape mode on the iPhone 6 and 6 Plus. In addition, arrow keys are also available in some third-party keyboards [5] — and some text editors [6] provide their own custom cursor keys.

Having said that, I do appreciate the improved QuickType keyboard [7] in iOS 8 and the option to install alternative keyboards (see “iOS 8 Third-Party Keyboards Explained and Reviewed [8],” 2 October 2014). (By the way, Yosemite has a new QuickType-like feature [9] that can help when composing text on a Mac.)

Blind Users Study -- According to the Towson University study “What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users [10],” the top causes of frustration among visually impaired users are:

  1. Page layout causing confusing screen reader feedback

  2. Conflict between the screen reader and application

  3. Poorly designed or an unlabeled form

  4. No alternate (“alt”) text for pictures

  5. A three-way tie between misleading links, inaccessible PDF, and screen reader crashes

The study also calls out confusing labels and instructions, vague alternate text for images, and general frustration over wasted time. It advises Web designers to use clearer wording in Web site infrastructure, limit the use of plug-ins and pop-ups, and conduct user experience (UX) testing of Web pages in a linear format, the way visually disabled users experience them. Given the ubiquity of poor design, I thought, “Good luck with that!” as I read their recommendations.

UX Testing -- There is some technological challenge, owing to the wide range of conditions and disabilities, and the spectrum of users’ various stages within them. But surely the collective capability of developers, along with modern computing technology, could address poor design, lack of options, missing preferences and utilities, and other easily preventable problems. (“If we can put a man on the moon…” and all that.)

The root of the issue is not technological but economic and perhaps even cultural. There simply isn’t the public will — yet — to fix this. Much of it comes down to a lack of thorough usability testing with regard to accessibility preferences and features. This problem reminds me of ambulatory-disabled people who point out that just because an architectural element looks wheelchair-accessible — and may have even passed the Americans with Disabilities Act building code requirements — doesn’t mean that it actually is. Architects and designers often don’t bother to ask someone who gets around in a wheelchair to test their designs.

Interactive usability testing takes time and money in a development cycle, which is why most developers don’t do it at all. My brother spells out the economic conundrum: “[Product] development is labor-intensive and expensive, but it accretes value over time: the tool I develop today will be the automated basis for some tool that I develop next month. By contrast, interactive usability testers are not accumulating value in that sense.”

In addition, app developers generally consider accessibility to be a problem for operating systems and Web browsers to solve — and so it’s really Apple, Microsoft, and Google that users with impairments need to lobby.

It’s important to inventory a comprehensive list of technical inadequacies, as I’ve done here, but it’s only the first small step to increasing accessibility for all users. While it may feel gratifying to vent our frustrations about problematic computer interfaces, what low vision users really need is personalized assistance and effective solutions. In the next installment of this series, I’ll investigate what’s available in the marketplace.

Articles in this series:

[1]: http://tidbits.com/article/15351
[2]: https://www.ghostery.com/
[3]: http://tidbits.com/article/15330
[4]: http://www.techhive.com/article/2030042/why-i-switched-from-iphone-to-android.html
[5]: http://www.digitaltrends.com/mobile/ios8-keyboards-confirmed/
[6]: http://brettterpstra.com/ios-text-editors/
[7]: https://www.apple.com/ios/whats-new/quicktype/
[8]: http://tidbits.com/article/15121
[9]: http://www.idownloadblog.com/2014/09/04/new-quicktype-like-feature-found-in-os-x-yosemite/
[10]: http://triton.towson.edu/~jlazar/IJHCI_blind_user_frustration.pdf
[11]: http://tidbits.com/article/15330
[12]: http://tidbits.com/article/15351
[13]: http://tidbits.com/article/15365
[14]: http://tidbits.com/article/15374
[15]: http://tidbits.com/article/15402