I have a very special first-world problem. It’s not the kind that revolvers around money, or stuff, or even the temperature of my latte. It’s a social media first-world problem.
I joined Twitter early. Like, in February or March 2007. I was actually invited in late 2006, but there’s no need to gild this particular lille. Because I could, I claimed the Twitter name @shelly for my own. Had I not joined Twitter for professional reasons, I would have been @shellyspodcast, which is how I rolled in those days, producing my own weekly eponymous podcast for the enjoyment of hundreds of people. But in 2007, I was also managing editor at the late lamented Blogger & Podcaster, and was writing my first feature article for the magazine. The B&P publisher was eager for me to put Robert Scoble, noted tech gadfly and early adopter of trendy things, on the cover of our first issue. Robert was evangelizing Twitter, just then. Fortunately for me, this made him eminently stalkable, once I had also signed up and followed him. When Robert came to SXSW in March, I tracked him to a meetup at Salt Lick BBQ. I never actually got to speak to him there, due to an abundance of panting fanboys who surrounded him at all times. (I did talk to him later, having observed that people who pronounce how open and transparent they are usually have their own rules about what that means). In the end, Twitter did provide a nice lede for my Scoble story.
The trouble with having a Twitter name that is also your first name is that folks use it in @mentions that are addressed to people who are not you. Some don’t realize that typing a space after @shelly will direct the mention to my timeline (as in @shelly kramer). Others have a friend named Shelly, and don’t bother to look up that person’s actual Twitter name. Finally, Internet sharing tools will sometimes introduce a space where there shouldn’t be one. That’s how I get lots of mentions intended for a woman who shares dessert recipes on Pinterest.
The long and the short of all this is that my morning rituals now include blocking Twitter mentions that belong to others. Tweetdeck on the desktop, by the way is great for this. Sometimes, there are a couple of notes (often in a language I don’t speak) addressed to random Shellys around the world. There’s also a Shelly who has adopted the persona of a white teenaged girl who is a virulent racist. Perhaps that’s actually who she is, but I sincerely hope it’s a fake identity. Apparently, there are a couple of reality TV “stars” named Shelly, too. People don’t like them very much. Occasionally, one of the other Shellys, usually the one who is both a dude and a “social media expert”, gets retweeted heavily. On those mornings, I hit Block quite a bit.
So whadaya think? Should I tweet this post out to all the Shellys of the Internet? Will they @mention and retweet me back, or is @shelly destined for a thousand block lists?
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.