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.
Another thing that all the media on this issue did, which I think you’ve done as well here, is conflate “accessibility for VoiceOver (and maybe low vision) users” with “accessibility for disabled users”.
As you are well aware, there are other accessibility needs not covered by the category of “VoiceOver + low vision users”. Switch users may have different accessibility needs which are clearly affected by choices app programmers make and they don’t always line up with the needs of VO users. Users with neurological disabilities such as dyslexia are different again – and often directly conflict with the needs of low vision users as dyslexic users frequently have difficulty dealing with very high contrast text whereas many low vision users need very high contrast text. Other groups I won’t go into include users with impaired dexterity (who may or may not use Assistive Touch), users with cognitive accessibility needs (who may or may not use Guided Access), users with fatigue issues, and many many many more.
Perhaps now I’ve typed out this perennial frustration I’ll finally turn it into an ATMac article 🙂 I’ve been dealing with my own disability this week so I haven’t blogged as much as I’d like to have done.
Despite this niggle, your article is excellent and raises all of the other things that were bothering me about this week!
Hi Ricky,
Since the NFB resolution and aftermath specifically addressed accessibility for blind and low-vision folks, that was the peg for my response. Switch Control is another area where app accessibility becomes very important, and, given its relative newness in the Apple access suite, it’s likely that developers need even more education about how to ensure that switch users can work within their apps.