Differences between revisions 18 and 19
Revision 18 as of 2013-09-17 13:22:15
Size: 6576
Editor: shoobe01
Comment:
Revision 19 as of 2013-09-19 20:40:17
Size: 6583
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
When Eric and I originally conceived of the outline for this book, I think we both had this same concept in mind. That good design covers it. But especially for apps of late, with the rise of hybrid development, and with new needs for touch accessibility, this is not true. Here in late 2012, on the devices that support full spoken-guidance accessibility, a lot of apps are marginal to useless for the low-vision population, and almost all could use improvement. When Eric and I originally conceived of the outline for this book, I think we both had this same concept in mind. That good design covers it. But especially for apps of late, with the rise of hybrid development, and with new needs for touch accessibility, this is not true enough. Here in late 2013, on the devices that support full spoken-guidance accessibility, a lot of apps are marginal to useless for the low-vision population, and almost all could use improvement.

I have traditionally said that good design is also design for accessibility. And there are many cases where mobiles are used by anyone in an environment where some input our output may be obscured, so every design should assume accessibility.

When Eric and I originally conceived of the outline for this book, I think we both had this same concept in mind. That good design covers it. But especially for apps of late, with the rise of hybrid development, and with new needs for touch accessibility, this is not true enough. Here in late 2013, on the devices that support full spoken-guidance accessibility, a lot of apps are marginal to useless for the low-vision population, and almost all could use improvement.

Accessibility is more important for mobile than possibly any other class of systems, for two reasons:

  1. Everyone has a mobile. Everyone. Not just the blind but young and old, of various literacy levels and more. Your product probably has to work with everyone.
  2. Due to the way mobiles are used (everywhere, for everything) many users will be "temporarily disabled." That means even literate, sighted 20-somethings will sometimes use their device in difficult circumstances. They might not be able to, for a little while, see or touch their device effectively.

Planning for accessibility means you are better positioned to address the needs of every user, all the time.

Semantic Presentation

You have, I hope, heard of the term semantic markup. It's a Web term that's been around a long time, and is rooted in all sorts of goodness.

Semantics is the relationship between marks (like elements of a page) and what they are supposed to mean. In this case, semantics means using the right element for the meaning; if you use a paragraph element and style it to look like a page title, instead of an h1, that's wrong.

Mobile Web

For the mobile web, it's easy. Search and you will find lots of guidelines. Mobile has no different needs from desktop, except the problems are more severe. That improperly-coded title will be read improperly not just by search engine bots, but by the built-in screen reader and the user will be left confused. It gets worse, but I won't harp on it.

Mobile Applications

But you might say "I build apps. What's that got to do with me?" Well, everything displayed as part of a software product is an element that is rendered onto the display. These all have their own structure, organization and tagging. And for mobile apps, these work in a way very similar to a Website. Use the right type of element for the piece of content, and be sure to label them correctly.

Testing Mobile Accessibility

Most major, current mobile OSs have a built-in accessibility mode. It's very much worth trying out periodically, and as a part of reviewing every one of your apps before it launches.

  • Android - At first launch there is a clever gesture to get into the right mode, but assuming you didn't do that, go into Settings > Accessibility and turn on TalkBack and Explore by Touch. This changes the entire way touch works. Drag or tap around to find out what is on the screen. Two finger gestures scroll windows. The last item read remains in focus, so you can double tap anywhere on the screen to select it. Unusual interactions are usually described so just wait for the read description.

  • iOS - Supposedly you can tap the Home button three times to turn on VoiceOver. Doesn't work for me, so just go to Settings > General > Accessibility. When you turn it on, be aware the whole touch interaction mode will change. Drag your finger around, or tap, to hear what's under it. It remembers what you last touched, so double tap anywhere to select the last item read. Try it with your eyes closed (and on headset to not annoy everyone else) and it makes more sense than trying read and listen.

When you try these, you'll notice the problem with some apps or sites immediately. The voice description will read back things like:

Ideally, I'd come up with a phrase like the old semantic-web was for, well, the Web. To emphasize the natural-goodness of well-designed code. If you use the right component, label it well, and arrange it properly, it's almost automatically an accessible app. If not... well, you aren't doing anyone any favors.

This article seems pretty comprehensive, and narrows to a series of steps. Try it out.

I'll eventually put some effort into specific guidelines, or at least a series of links. Here's some to start with:

Shay Howe had a GREAT presentation on semantics and html 5 at the 2012 Float Mobile eLearning Symposium. When the video comes out, at least, find and watch that.

More notes from recent work and pondering: Accessibility modes for non-sighted users are VERY different interfaces and interactions. Try it, and see what I mean. Labels and types of interfaces matter.

Design for Accessibility (last edited 2015-02-03 16:56:12 by shoobe01)