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:
- 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.
- 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.
You Have To
Sometimes, you have to make things accessible. This is US-centric, but there are similar regs elsewhere.
- Section 508 of the rehabilitation act §1194.22. Not ADA compliance, and what it includes and what it does not...
- 21st Century Communications and Video Accessibility Act (CVAA)
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.
Overview of semantic markup https://en.wikipedia.org/wiki/Semantic_HTML
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.
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.
The Mobile Developer's Guide To The Galaxy has a decent sized chapter on accessibility, including a section on the Mobile Web.
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.
Android - Guidelines for mobile accessibility including proper markup
All platforms - The Mobile Developer's Guide To The Galaxy has a decent sized chapter on accessibility for Android, Blackberr, iOS, Symbian/Qt, Windows and more.
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: Title, Element, Element, Element, Element, Image, Button
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.
Alastair Somerville (@Acuity_Design) creates tactile maps for blind and low-vision users to navigate public spaces. These are neat, but he really thinks about this stuff, and that reveals really neat stuff about not just how to design for accessibility, but how design really works for anyone. Good thinking. Read and watch all this stuff.
This article seems pretty comprehensive, and narrows to a series of steps. Try it out. Why mobile Web accessibility matters - best practices to make your mobile site accessible
* Ignore the part where, as always, they say Web. Applies to everything. Reframing Accessibility for the Web
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.