Last week’s kerfuffle about the National Federation of the Blind’s (NFB) resolution asking Apple to make a more vigorous effort to ensure the accessibility of third-party apps accomplished several things: it got lots of mainstream attention for the NFB, and united the Apple-centric press in righteous indignation over perceived defamation of the Cupertino company. What it didn’t do, in mainstream journalism, at least, was facilitate a discussion of what the NFB resolution seeks, or whether it’s reasonable. The controversy has also not demonstrated that the Apple defenders in the press actually know much about the relationship between accessibility support in the OS, and the need for implementation by app developers.
So here’s what happened. NFB members passed a resolution (Word doc) asking Apple to strongly encourage, if not require, that app developers make their software accessible, as a condition of availability in the App Store. And by that, the resolution means that developers should take advantage of accessibility hooks provided in Apple operating systems, so that interfaces and content can be read by the VoiceOver screen reader, or viewed by people with low vision. The “whereas” portion of the NFB resolution actually does a thorough job of describing how apps are rendered inaccessible, how blind consumers often inadvertently purchase inaccessible apps, and how updates sometimes break pre-existing access support. The resolution suggests that since Apple already exercises a lot of control over what gets into the App Store, adding an accessibility requirement is consistent with the company’s highly-regulated approach to app approval.
Next came the Reuters article, which stated (incorrectly) that NFB had sued Apple over accessibility in the past. The author then took a famous Tim Cook quote about Apple’s reasons for championing accessibility out of context. Finally, several leading Apple-focused writers rose as one to defend Cook’s good name, eviscerating the Reuters piece, and praising Apple’s commitment to accessibility in the distant past, in the now, and for all time to come. (And Google sucks, by the way.) This Fortune article does a nice job of fleshing out the story, and linking to more Mac press responses.
Here’s the thing: lots of folks in the Apple-centric press have a regrettable tendency to cheerlead. Call it advocacy journalism, homerism, or reality distortion field, but it’s a fact of the way many who cover Apple’s every move ply their trade. Whether Fortune’s assertion that they responded at the behest of Apple PR is true or not, the discussion certainly wasn’t very substantive; beginning with the erros in the Reuters article, and winding up with unreserved praise for Apple’s leadership in accessibility, and their altruistic commitment to it.
A few things were missing:
- No mainstream article I could find included the opinions of people who use Apple’s accessibility tools, whether affiliated with NFB or not. Newsflash: blind folks are not united on this issue, and they know about what makes an app accessible, and whether and when it’s reasonable to take Apple and developers to task. Marco Arment makes a detailed case for including accessibility support in the app review process.
- Apple writers were extremely concerned about getting Tim Cook’s words down completely and correctly, but none bothered to link to the resolution that started this beef, never mind exploring what motivated it, or whether what the resolution asks for is reasonable or possible. For their reference, Jonathan Mosen’s response attempts to explain the issue by taking a historical view of tech accessibility, and Apple’s role in its evolution.
- This isn’t an Apple versus Google story, no matter how much some would like it to be. And if that’s really the story a journalist wants to write, it would be important to address the degree to which Apple controls what goes on in the App Store, and how that makes enforcing access requirements on app developers much more possible in the iOS world than on the Android platform.
Even in the accessibility community, the Tim Cook quote about why Apple makes its products accessible is held up as a reason to venerate the company. But as proven by the manner of the MacPress response to this little dustup, it’s much easier to cut and paste pretty words from the CEO than it is to take on the challenges and successes of accessibility on a substantive level. Whether you’re a fan of the NFB resolution, or think it goes too far, its real value is as a conversation-churner. Apple understands that conversation is happening, probably far better than most of its journalistic cheerleaders do.
I’m thrilled to announce the availability of my book, iOS Access for All: Your Comprehensive Guide to Accessibility on iPad, iPhone, and iPod Touch. The book guides readers through all accessibility features available on Apple’s mobile devices. Whether you’re just getting started with iOS, or want to learn more about apps and accessibility tools you already use, iOS Access for All has all the bases covered. With information of interest to users who are blind, low-vision, hearing-impaired, or have cognitive or motor disabilities, the book is the most extensive iOS accessibility resource available.
I’ve spent more than 25 years writing about technology, with a particular focus on Apple products. I’m also a visually-impaired iPhone user. My full bio is here.
Here’s the Table of Contents for iOS Access for All.
Part 1: Getting Started
Chapter 1: Accessibility the Apple Way
- Apple Revolutionizes Mobile Access
- Today’s iDevices, and iOS
- The Apple Ecosystem
- Meet iOS Accessibility Features
Chapter 2: Orientation and Quickstart
- iDevices 101
- Parts of iOS
- Choose How to Set Up iOS
- Accessibility Quickstart
- Ready to Dive Deeper?
Part 2: The Wide World of iOS Access
Chapter 3: VoiceOver
- Activate VoiceOver
- Learn iOS and VoiceOver
- Do More with the Rotor
- Text and the Virtual Keyboard
- Dictate Text with Siri
- Enter Text with Handwriting Gestures
- Use a Wireless Keyboard
- Use a Refreshable Braille Display
- Manage and Navigate Your Device
Chapter 4: Low-Vision Access
- iOS’ Low-Vision Challenges
- Screen Magnification
- Enlarge and Enhance Text
- Color and Contrast
- Speech As a Low-Vision Tool
- Quickly Enable Low-Vision Features
- Mainstream Features with Low-Vision Uses
- The iOS Camera: Low-Vision Super Weapon
Chapter 5: Siri and Voice Input
- Set Up Siri
- Siri Commands
- Voice Control
- Voice Input Alternatives
Chapter 6: Tools for Hearing Impaired Users
- Convert Alerts to a Flash or Vibration
- Control Audio Output from Calls and Apps
- Hearing Aid Support
- Use a Hearing Aid
- TTY Support
- Closed Caption Support
- More Communication with iOS
Chapter 7: Physical and Learning Access
- Guided Access
- Switch Control
Part 3: All About Apps
Chapter 8: Access to Apple Apps
- Sidebar: Delete, Move, and Share within Apps
- Camera and Photos
- App Store/iTunes Store
- The Rest of the Included Apps
- But Wait, There’s More (Apps)
Chapter 9: The Best of Accessible Apps
- An Accessible App Primer
- Navigation and Travel
- Reading, News, and Information
- Communication & Social Networking
- Accessibility Tools
- Learn More About Apps
Appendix A: VoiceOver Gestures
Appendix B: VoiceOver Keyboard Commands
Appendix C: Braille Commands
You can buy the book for US$20 at the iOS Access for All Web site.
You can buy the ePub (Apple iBooks-friendly) version for $20 at the book’s Web site.
I’m just back from the CSUN International Technology and Persons with Disabilities Conference in San Diego. That moniker is a mouthful. Just think of it as the largest annual gathering of accessibility geeks and experts, and you’ll have some idea what it’s all about. Spent three days promoting the book, larding more about accessible tech, meeting folks I’ve been following on Twitter, and handling a products that either incorporate support for accessibility, or are designed specifically to provide an accessible alternative.
I also spent some time with fellow podcasters Robert Carter and Allison Hartley of The Tech Doctor Podcast, and Allison and Steve Sherridan of NosillaCast. A segment we recorded about iOS 7.1 changes related to accessibility appears on this week’s NosillaCast. It’s near the end, but hopefully worth the wait, especially since Allison also includes interviews with a few vendors from the CSUN exhibit hall.
Finally, I returned to Austin via Amtrak, starting on Friday night in San Diego, and arriving home on Sunday morning. It was a great trip, and seems to have completely mellowed me out, after a hectic few days at CSUN. I recommend long-haul train travel, especially if you’re not a fan of what air travel has become.
Here’s a picture I snapped from the back of the train, somewhere in Arizona. My sleeper room happened to be in the last car, so I just walked a little way down the hall to get it.
Forgive the sensational headline. I did it on purpose. There! I feel better. Confession is good for the soul.
It seems someone has filed a class action lawsuit against Apple on behalf of visually impaired customers who are unable to use the company’s touch-screen point of sale (POS) devices to enter a debit card PIN number. What I’ve seen of the commentary on this subject today leads me to offer some clarifications for those of you who are neither visually impaired, or familiar with the accessibility options in Apple’s iOS devices. I check both of these boxes.
If you make a card-based purchase (debit or credit) at an Apple Store, the transaction will be processed on a modified iPod Touch, carried by an employee. You’ll be asked to enter your PIN on a touch screen, or to use your finger to sign your name, if you’re using a credit card. Now, all iOS devices, including the iPod Touch, have a number of nifty accessibility features, namely the VoiceOver screen reader, and magnification and invert colors options used by visually impaired (sometimes called partially sighted by those who are not) people. You can turn these features on for any iOS device you, yourself control, even the demo iPads in the Apple Store. Using Accessibility Shortcut, you can do it with a quick triple-click of the Home button. So far as I know, it isn’t possible for Apple employees to enable these options on the locked-down devices they carry.
A couple of pieces I read today compare Apple’s POS systems with those in grocery stores or other retail environments, suggesting that “all” such devices offer tactile buttons, because the Americans with Disabilities Act (ADA) requires them, and that these buttons solve the problem for blind people who need to enter a PIN. In fact, I’ve used some POS systems that rely on non-tactile buttons, and many more that require the user to navigate a series of menus to choose the kind of transaction, request cash back, and approve the total purchase amount. Positioning, size, and color of these menus varies widely. For me, they’re just difficult to read, and I have been known to judge chain stores based on their card reader technology. For a blind person, these systems create real barriers, tactile buttons notwithstanding. So let’s be clear that the grocery store is not a happy, accessible fairyland, while the Apple Store is a big, blind-hating meanie. The difference is that though I may need assistance confirming the amount of my food purchases, I am often able to enter my PIN number unassisted, even though the menus suck.
Now, if you’re looking for topics to add to your “all outrage, all the time” talk show, I suppose this suit against Apple would be a fun one. I can hear the lawsuit haters revving up their dialing fingers now, ready to hold forth about how this guy probably wants to be paid for his inconvenience by separating Tim Cook from some of those Apple millions. But my intuition, and that’s all I’m relying on here, tells me that’s not what’s going on. Apple has the ability to solve the problem stated in the lawsuit by 1) making it possible for the employee to enable accessibility features like VoiceOver on the POS terminal, and 2) providing earbuds to a customer who doesn’t want the PIN to be broadcast throughout the store. Since I use Invert Colors on my iOS devices, I would like Apple to expose that option, too. Boom! Apple POS systems turn from cold, unfriendly, pieces of…glass back into highly accessible iPod Touches, making them far easier to for customers (and potential disabled employees) to use than my grocery store card reader.
Another reason to keep an eye on this suit, and whether Apple finds a way to diffuse it with adjustments to software, rather than with a tactile button attachment, or some other significant change to its POS hardware, is that iOS devices are popular in all kinds of retail environments. My favorite little Thai place has one, and I find the screen, as rendered by the POS software they use, impossible to read. And it infuriates me to know that the accessibility tools I use every day are right there, behind the POS screen and not available when I pay for my chicken fried rice.
The best outcome of this suit would be that Apple Store customers acquire the ability to complete transactions in an accessible way, and that the need to expose VoiceOver and other features in retail applications would translate into better accessible systems in any environment where customers buy things with mobile devices. That’s positive for anyone concerned about ADA compliance, and provides a competitive advantage for Apple over devices with less built-in accessibility.
For the past few years, I’ve been posting links to music samplers associated with the extravaganza that is the SXSW Music festival, here in Austin. These samplers come from record companies plugging their showcasing bands, NPR stations, and most awesomely, from the nice folks at The (Unofficial) SXSW Torrents site, who scoop up the tracks made available by SXSW itself, and package them in several juicy torrent files. In fact, downloading these torrents has been my late February ritual since 2005. They’re great fun, especially if you’re planning to attend SXSW Music, and wish to know what Moto Passion Pit sounds like before you queue up outside the frat boy bar where they’ll be playing for 50 minutes, come the middle of March.
Here’s the thing though: each year, the number of samplers that consist of downloadable files decreases, and the number of Spotify playlists and other streams increases, making my little collection of links less about music acquisition than is strictly of interest to me. This is to be expected, and I’ll save you my old person rant about how I like files better than streams.
Be that as it may, I’m honoring my commitment to provide links to downloads where I find them. We start with the unofficial torrent, whose proprietors have already warned that SXSW has moved from downloads to streaming, but that they apparently did so in mid-season, so one or two smaller torrents are available.
Watch this post for updates. I tack them onto the end, with the date of the update above each new set of links.
Streams and Playlists
I have been busy working on my book, iOS Access for All: Your Comprehensive Guide to Accessibility for iPad, iPhone, and iPod Touch. Apple has decided to make my life interesting by releasing a new version of iOS. You may have heard about this. I have spent this week committing my thoughts about the new release into words, both written and spoken. You can read my reaction to the new OS, and its implications for accessibility, and you can listen to the Maccessibility Roundtable #44, where I join in a discussion of similar topics.
What does it mean that an app is “partially” or “mostly” inaccessible? It usually means that VoiceOver reads some of the buttons, menus, or contents of the app, but not all. And not enough so that the a VoiceOver user can work with the app.
I downloaded a recipe app that features some guy’s mug all over it (Strike 1 for the presence of a “celebrity” chef) and discovered that VoiceOver only reads the _amounts_ of ingredients. Not the instructions, not the ingredients themselves, and not even the titles of the individual recipes (strike 2.) The menu buttons, however, are accessible. In many cases, it’s the other way ’round, with buttons unavailable, while content is present.
I’m not grumpin’, just educatin’.
Amazon announced yesterday that its Kindle app for iOS had been updated to provide “more accessibility.” In fact, the update (with the inauspicious version number, 3.7) turns a largely inaccessible app into one that VoiceOver screen reader users can rely upon to read, navigate, and manage the contents of a Kindle library. And they did a great job, not merely making the app usable, but opening all Kindle iOS features up to VO.
The fact that blind people have Kindle libraries, given the limited native accessibility of Amazon’s hardware and mobile apps, is testament to the company’s dominant place in book-selling. So, too, are the aggressive efforts made by advocacy organizations for blind users, who have been lobbying Amazon to make this happen for some time. Sure, iOS users have been able to access iBooks since its inception, and Barnes & Noble’s Nook app was born speaking VoiceOver. But Amazon and Kindle retain big dog status, and those of us who have been nursing mistrust of the company must now work out for ourselves whether the proper reaction is joy and gratitude, or a harumphy “it’s about time.”
And despite the world-weary cynicism you might take from the previous paragraph, you should know that the accessible Kindle app is truly a thrilling thing. I have Kindle on my iOS devices, and quickly downloaded the update. When I opened the app with VoiceOver on, I anticipated something great. When I ran my finger across the screen and heard the iPad read book titles and the Kindle menu options (without the “btw” suffix that often indicates marginal accessibility), I was excited. And when I double-tapped to open a book, then did a two-finger swipe to tell VoiceOver to read a page, I became positively giddy.
Accessibility can be like that. You feel as if you have been given the keys to the locked room you’ve always wondered about. To use a closer metaphor, it’s like putting on your first pair of glasses, and suddenly being able to see the blackboard in school. Though I can and have read Kindle books with my eyes, and can and have used VoiceOver to read iBooks and Nook books, I have a strong urge to find a cozy corner, do a two-finger swipe, and luxuriate in the spoken/written word, brought to me by the accessible Kindle app, which gives me access to a library far larger than the one Apple offers.
Putting my news analyst hat back on for a moment, it’s worth reminding those of you who don’t follow this stuff that Amazon’s own hardware is not yet fully accessible, nor is the Kindle Android app. I take this as evidence of the power of those who fought for Kindle accessibility. You see, the people who use screen readers have invested their mobile device dollars in iOS, not Kindles, and not Android phones. Amazon got its priorities right, even if it took them far longer to make this move than many of us would have liked.
It’s an exciting day in accessible publishing. Amazon has finally released an accessible version of its Kindle app for iOS. Frankly, Kindle’s inaccessibility has made that platform easy to ignore, in the community of VoiceOver users. iBooks, Nook, and plenty of other ebook readers offer access via text-to-speech, but neither the Kindle devices, nor Amazon’s apps have done so. Where to buy books then? Anywhere but Amazon. And where to publish books about accessibility? Anywhere but Amazon. Now, though, the playing field is different.
I continue to work on my book about accessibility in Apple’s mobile devices; iOS Access for All. I’ve been asked many times which publishing formats I intended to use, and I’ve always said that Kindle was a low- or no-priority, mostly because the platform hasn’t been accessible. That is both a practical and a political decision on my part. Besides–and nothing Amazon has done today changes this–the Kindle Store imposes high costs on independent publishers. I will be running numbers and continuing to ask potential readers their opinions and platform preferences.
My next post takes a look at how Kindle accessibility feels from a reader’s perspective.
When Google announced this week that it would be shutting down Reader, I took it as another indignity to be borne. I’ve seen services I like shut down, sold, and screwed up beyond recognition. And that’s just the Google stuff! Reader occupies a default tab in my Web browser. I check it first thing in the morning, and return to it all day. I have created something over 20 folders to sort my reading matter, which includes mainstream news sites, friends’ blogs, niche tech content, and long-tail feeds about things you do not care about at all. In short, RSS generally, and Reader specifically, are foundational to the way I live and work online.
I came late to Reader late. Back when I was running Blogger & Podcaster magazine, I had to keep up with what people like Robert Scoble said. And he was all about Reader and a complex web of shared lists and links. In those days, I was a happy NetNewswire user, not needing to sync my feeds to a mobile device or a second computer. So I ignored Scoble, partly because I found his righteousness about the whole thing aggravating, and partly because I wasn’t fussed about sharing what I was reading.
I changed the way I interacted with RSS about the time I got an iPhone. Or was it when a few friends of mine started sharing news items via Reader? I don’t recall exactly, but at some point I went all in with Reader, syncing to the desktop RSS reader, and eventually making that permanent browser tab and all those folders for News, Politics, Podcasting, Longform Writing, Fluff (I Can Haz Cheezburger?), and so on. For a long time, I devoted this here site to a link blog of items I was sharing with friends. It wasn’t the most original content in the world, but I thought my choices were interesting, and the ability to share in this way gave me a means of commenting on the world in a way that was completely in my control, and fun.
Well, the Goog killed off the Share feature just in time to put a lot of its social eggs in the Google+ basket. Being unwieldy, and not a place many of my former Share buddies spent time, Google+ (which does have a tab in my browser), never became a place I cared much about. And like a lot of people, I got more and more things to read from the social networks. But these have never replaced RSS for me. The Three Cs that explain why I prefer RSS to other methods of information-gathering.
- Completeness: Twitter sits on my desktop as I work during the day. I read it and Facebook (probably too much) when I’m at the computer, but hours sometimes go by when I don’t see Twitter. There’s the phone, of course, but I’m not glued to it. Because of the sheer volume of stuff available (I follow 500+ people, talking about topics ranging from cocktails to iOS; accessibility to Austin food), there’s no chance of scrolling back to catch up on what I’ve missed when I’m not plugged into TweetDeck. Unlike a good RSS reader, Twitter is an asynchonous fire hose, even with lists. I could follow fewer people, but if I have better ways of gathering and storing information until I’m able to consume it, why should I? Twitter’s function is not to tell me everything I need to know about the world, but to offer a running commentary, while I’m available to consume it. Twitter works best if you think of it as a party line, or a live TV channel.
- Customization: I do love my Google Reader folders, and they serve me well. Far better than Twitter lists, they allow me to concentrate on, or ignore a topic, based on what’s going on in my world. If I’m following an election campaign closely, the blogs about classic film can wait awhile. Ditto the stories about podcasting, when I’m hip-deep in a book about accessibility. If I need a break, the Music folder awaits. If I want to substitute someone else’s curation for my own, I can subscribe to Slate writer John Dickerson’s set of public RSS feeds. He’s subscribed to some right-wing sites, and though I don’t want to wade through that stuff every day, I do sometimes take a quick look, mark everything I don’t have time for as read, and move on to the pictures of cats.
- Context: This one qualifies as a pet peeve. A couple of weeks ago, I went to San Diego for a conference. I used Twitter primarily to keep track of goings on within a quarter-mile radius. I needed to find people and learn about events. Politics and cocktails, for once, were not on my radar. When I got home, I re-activated the Twitter fire hose. The people covering politics were all on about “the Woodward thing.” I had no idea what they were talking about, and no one provided context. Could I have Googled it up? Sure, but why? Political sites whose RSS feeds I have stored under that tab would explain it in complete sentences the next time I checked. And frankly, I was put off by the assumption implicit in the Twitter shorthand that everyone was completely up-to-date with whatever temporal kerfuffle was blowing through the political world, even if it was a story that wouldn’t matter, 12 hours after it trended. This happens a lot, and not just when I travel. A story hits at 9 AM, and by noon, Twitter has stopped telling you what the story is, and proceeded to analyze it, hashtag it, shorthand it, and make fun of it. You have to be mighty curious to work up enough interest to find out what the holy heck is going on.
I realize that the thing I am attached to is not Google Reader: it’s RSS, and the ability to organize a large group of feeds so that I can consume them on multiple devices, maintaining update status, and controlling the ability to subscribe and unsubscribe as I like. A few other services exist (Google Reader pointed me to a Lifehacker article about them), and I think we have yet to know what the full RSS landscape will be, post-Reader. For my part, I’ve been pondering the feasibility of maintaining my own synced RSS feed file on a server I control. There’s still research to be done on both the server and client sides of that equation. I have til July, apparently.