Apple Leads in Accessibility, But Can Third-Party Developers Follow? Editor's note: Steven Aquino is a freelance tech writer and iOS accessibility expert, based in the San Francisco Bay Area. His work has appeared in The Magazine, Macworld, TidBITS, and more. He also writes for his personal website, Steven's Blog , and co-hosts a weekly podcast, Accessible. Third-party apps on the App Store need to be much better at being inclusively designed <http://www.imore.com/power-and-promise-accessibility-and-inclusive-design> . The tendency - albeit naturally - is for Apple and other developers to make iOS, and apps designed for iOS, for the majority of users. While users with disabilities, such as myself, are not a majority, we are an important niche. We use iOS devices, too, and we surely appreciate Apple and developers making us a priority <http://apple.com/accessibility/ios> . Figuring out how to best address the issue of improving third-party app accessibility is not a trivial matter; rather, it's a complex problem with some potential pitfalls. It makes sense to first consider Apple's responsibility here. From a developer perspective, the company encourages accessibility by providing documentation <https://developer.apple.com/technologies/ios/accessibility.html> for best practices for coding accessibility, as well as devoting much time during WWDC <https://developer.apple.com/videos/wwdc/2014/> sessions talking about accessibility on iOS and the Mac. Of course accessibility isn't a challenge for only Apple; indeed, others such as Google and Amazon must think about these issues and follow <http://chrishofstader.com/android-ios-and-accessibility/> Apple's lead in serving disabled users the best they can. The most reasonable and practical solution comes from Marco Arment. He proposes that Apple should make accessibility testing part of the app-vetting <http://www.marco.org/2014/07/10/app-review-should-test-accessibility> process. Arment writes: My proposed fix: 1. Allow developers to opt into accessibility testing for each submission in iTunes Connect. Put it on the screen that asks about cryptography so all developers must answer it and are made aware of it. 2. Show a small badge on each app's page in the Store that passes accessibility testing. This helps customers make buying decisions for their needs. 3. Passing requires all advertised functionality to be accessible, all accessible controls to have accurate labels, and no navigational traps such as inescapable screens or stuck states. 4. If a user has VoiceOver enabled while downloading an app that has not been tested for accessibility, or while updating a previously tested app to to an untested version, show a warning dialog and ask them to confirm whether they still want to proceed. This helps them and gives developers a good reason to opt into accessibility testing. The specifics of Arment's ideas notwithstanding, his proposal underscores the big picture: third-party apps should have a basic level of support for accessibility. While I don't pretend to fully understand iOS development, it seems to me that accessibility is important <https://www.youtube.com/watch?v=dNEafGCf-kw> enough to Apple that the company could (and should) adopt such a policy. Their enforcement of such hypothetical rules needn't be so iron-fisted, but just knowing that they are checking for accessibility compliance would, in theory, be a great show of goodwill to those in the accessibility community. (Another example of Apple's acknowledgment of this: their nods in widely aired iPhone ads <http://stevensblog.org/facetime-every-day/> .) Moreover, the incentives that Apple could provide developers - badges, even an "Editors' Choice for Accessibility" - would go a long way in terms of developer relations and promotion. All Accessible All The Time? Arment's proposed solution is rooted in the concept that all iOS apps be accessible, so that people with disabilities aren't left out. Yet for as noble an idea as "all apps, all accessible" is, the reality is that it isn't tenable beyond the bare minimum. For one thing, the notion of "accessibility" and "inclusiveness" is abstract and far-reaching. How are developers to choose which accessibility tools to use? Do they have experience with accessibility, if only brief? More to the point, who are developers targeting? Cognitive and/or physical impairments run the gamut in terms of severity and corresponding needs; how are developers supposed to know which to focus on and understand how, say, Switch Control support <http://support.apple.com/kb/HT5886> will benefit someone? All of this is to say that expectations need to be tempered when touting universal accessibility because it's like opening up a can of worms; it's not as simple as Here, now everyone can use X app. Or consider the reverse: Just because Apple or a developer may label an app as "accessible" doesn't mean necessarily that the app will work well. What if the implementation is poorly done, or if the app tries to be all things to all people, cramming every possible accessibility tool in the software development kit just to meet the "accessible" quota? Accessibility in and of itself is like the users who rely on it insofar that it's a very abstract concept. Developers have to know exactly what they want to achieve and who they want to serve, because users' needs vary. Because of this, it's also important that developers be proactive in educating themselves about Apple's Accessibility tools, and about their target audience. Accessibility Input So how does a developer know what he or she is doing right (or wrong)? I've been fortunate to have numerous opportunities to help beta-test apps from some prominent <http://stevensblog.org/overcast-review/> developers <http://stevensblog.org/unread-review/> . This type of information is invaluable for the obvious reason that accessibility may be out of the realm of knowledge of many developers. To be clear, this isn't about ignorance - it's about outsourcing experts to QA an aspect of their app which they deem important to get right. A problem, however, in QAing accessibility is actually finding people who are willing and able to provide guidance and feedback regarding accessibility. Tech companies such as LinkedIn are becoming increasingly aggressive in hiring people for the express purpose of helping guide their <http://ramyasethu.tumblr.com/post/69155473557/making-accessibility-mainstre am> accessibility efforts. Of course, these are full-time, salaried positions - most, if not all, indie developers can't do this - but the basic principle is the same: recruiting people to lend a voice to accessibility. It's imperative that developers find people who are well versed in this area in order to give disabled users the best experience possible, but it isn't easy. The fact is that, again, accessibility is a relatively small segment of the total user base, and there aren't many of us experts out there. Put another way, we're a special breed attuned to special use cases. Universal Accessibility? Another stumbling block towards achieving accessibility for all is the fact that there are many categories of apps that unfortunately aren't conducive to accessibility enhancements. Examples include medical apps and audio/video editors - apps like these fit a very specific group of people doing very specific tasks, and it's unreasonable to assume that such apps can or should be accessed by all. Even games are a no-man's land of accessibility, although that's a problem that's slowly being rectified <http://foralltoplay.com/> . I don't mean to imply that developers be exclusionary in their vision and design; I'm simply pointing out that, realistically, there are certain types of apps for which accessibility is unfeasible. Apple is leaps and bounds better than the <http://chrishofstader.com/android-ios-and-accessibility/> competition here. It makes sense that, at the very least, VoiceOver <https://www.apple.com/accessibility/osx/voiceover/> or Large Dynamic Type be supported. It's the right thing to do, and as I stated before, will do much to make disabled users happy. The moral of this story is that accessibility is hard. The blanket statement that all apps be accessible is well-meaning and not without merit, but isn't as easy as it sounds. Verification by the app review team is a great start - assuming Apple ever implements it - but there's a long way to go. The more talk, the better consideration and advocation for the issues and the community. In the end, it means a lot that so many people care to stand up for users with disabilities, myself included. _____ http://techcrunch.com/2014/08/02/reuters-rebuttal/?ncid=rss http://techcrunch.com/2014/08/02/reuters-rebuttal/?ncid=rss -- The following information is important for all members of the viphone list. All new members to the this list are moderated by default. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. The archives for this list can be searched at http://www.mail-archive.com/[email protected]/. --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/viphone. For more options, visit https://groups.google.com/d/optout.
