A few days ago, as I was browsing Twitter feeds of my friends, I came across an item that caught my eye: a resolution on making iOS apps accessible. Specifically, the resolution, known as “NFB resolution 2014-12” (which was passed on July 5th) calls on Apple to make all apps accessible for the blind by implementing accessibility standards and policies in collaboration with National Federation of the Blind (NFB). In describing the current situation, the resolution outlined how VoiceOver, Apple’s screen reader for OS X and iOS, was an integral tool for accessibility, and described how some apps were not accessible (or have become inaccessible in recent releases) with problems such as unlabeled buttons and so on.
At first, I felt uneasy about the resolution for several reasons. First, as a developer, I knew how some programmers would be burdened by implementing accessibility layer on top of their apps (techniques would have been labeling buttons, adding custom hints in addition to proper labels, etc.) and resources to be spent on such projects in an industry where cost is a key consideration in projects. Second, as some users pointed out, not all apps are guaranteed to be accessible (or accessibility would be incomplete), such as popular games like Angry Birds series despite advocacy efforts. Third, I believe in direct negotiations with app developers, as it allows a developer to become aware of the needs of their users, and if a famous developer would announce implementation of accessibility standards in his or her app, chances are that it’ll translate to a domino effect (other developers following the leader). Lastly, I feared that some app authors would leave iOS ecosystem due to accessibility requirement that Apple might impose as a result of passage of the said resolution, saying that some apps will never become accessible.
At the same time, I also thought about possible implications of this resolution in case it passes. First, although there were comments asking why Apple was singled out, some, including myself, also thought about the impact that this resolution might have on other industry giants such as Google, Microsoft, Amazon and so forth (particularly Google due to their mixed reputation of Android among blind users). Second, I worried that the reputation of the blindness community (represented by consumer advocacy groups such as NFB and ACB (American Council of the Blind)) might suffer as a result of demanding accessibility policies to a company such as Apple, seeing that people would misinterpret this as wanting more comfort. Third, NFB’s reputation among blindness community is mixed, with more people having negative views on this organization due to its history and patterns on their advocacy strategies, thus some were concerned by this resolution and its impact in the future.
Personally, I identify myself with those who oppose NFB resolution 2014-12. I’ve opposed the resolution due to the reasons outlined above: implementation resources, incomplete accessibility ecosystem, need for direct negotiations and departure of apps. I also agreed with sentiments raised on various social media (especially Twitter), such as flaws with the resolution, logic used, reputation and so on.
First, not all apps would be accessible in the long term for technical reasons. Some of the popular apps on app distribution channels are video games, and due to their nature, it becomes hard to implement accessibility with current development methods. One practical solution is to provide audio feedback and documentation on how a potential blind gamer would play the game. This becomes difficult when we have games which require fast response time and is CPU/GPU intensive. In this scenario, a phone’s processor would be busy not only servicing routines from the game, but also need to service output and input from blind gamer (this requires good design, even with dual core or quad core processors as they need to work together). Without good communications and accessibility design in place, we’ll never see a day when 100% of the apps (including games and professional apps which are very visual) are guaranteed to be accessible (and I use the word “guaranteed” to mean it’ll work out of the box). And that, folks, is current reality of programming mobile apps (solid design naturally leads to accessible app).
Second, I believe it is better to start from small things and allow others to learn from case studies. I once compared this statement to a waterfall and a boulder. A waterfall, with incredible sight to behold, starts from a small stream deep in the mountains. As other streams join the main stream, it creates massive body of force that cannot be stopped (unless something is blocking its path), culminating in a spectacular show of nature we call waterfall. Now suppose we have a boulder somewhere, blocking path to a stream’s progress. The stream, although struggling at first, eventually forces the boulder out of its way and continues downstream unless the boulder has more than enough force to repel forces from water (as a consequence of one of the famous physics laws). Or consider dominos where pushing a domino forward would cause others to fall.
In connection with app accessibility, I believe in direct negotiations for accessibility as opposed to forced policies. Although it may become necessary for a company to come up with design policies for accessibility, what really makes a difference (in my opinion) is if small steps are taken at first. By ensuring that an app is accessible, an app developer would have gained more customers, which would trigger a domino effect where other app writers in the similar genre would try to make theirs accessible. This would then be noticed by apps in other categories, thereby making them join the stream and creating a “virtual waterfall of accessibility”. In other words, it is far better (in the long term) to let app authors be creative and learn about accessibility when working with their customer base than for a company to institute accessibility policies after recommendations from a consumer organization (I must stress that I do believe in collective action, but for this case, I believe it is far better to go through direct negotiations, sitting with app authors and allowing them to have an intimate learning experience about accessibility needs).
With that said, I’d like to present some suggestions for all parties involved in this event, and offer some thoughts on what we can do next, now that the resolution is in the record books.
First, I’d like to kindly suggest that users approach app developers as friends and partners. App users and software developers (like myself, as I belong in both camps) are all consumers: users consume products made by programmers, and in turn, programmers consume suggestions, bug reports and improvements from users. I believe that better (I should add, ultimate) accessibility of an app comes through solid partnership between users and developers in understanding each other’s needs – accessibility for blind consumers and product feedback for developers. And I do kindly suggest that it be done in a friendly manner in order that reputation of both parties (consumers and developers) would improve.
Second, I’d like to kindly suggest that we look at consequences and long term goals and reputation about our community when we write resolutions and campaigns. I’m sure we don’t want reputation of the blindness community to suffer now and in years to come, particularly for our people to be misinterpreted by mainstream society, right? And since our posterity depends on our actions today, I believe it is important to not only consider our current reputation, but also the reputation of our community a few decades down the road as well, as well as consequences of our campaigns and resolutions so that our posterity can look up to us and learn from us, even if we make mistakes (if we do make mistakes, it’s better to acknowledge it for the benefit of future generations).
Third, I’d like to gently suggest to app authors to become our partners in accessibility to provide rich case studies for others to follow. A well-known Korean proverb says, “better is seeing once than to hear it a hundred times.” That is, a person would retain understanding of a concept once he or she sees it rather than hearing about it many times. By providing ready to use examples of accessibility (even small demos and case studies), an app author can open possibilities for other apps to become accessible for people with disabilities.
Lastly, I’d like to gently suggest that we have reality checks from time to time. We cannot pass through a mountain without knowing which way is the route to a safe camping location for the night, nor we cannot easily say that we can cross a desert without checking our water supplies and thinking about passing through this valley safely. Likewise, it is good to have dreams of an unseen accessible ecosystem down the road (and we do need visionaries in our generation), but we cannot make it there unless we have a sense of what we can and cannot do (a good example is braille system; although we cannot easily communicate with print, we can at least learn about the current affairs and express our opinions through alternates such as braille and related technologies). And we shouldn’t forget that there are talented individuals (I should add, all of us are talented in one way or another) who can bring ideas to reality, and that reality could be another reality check in a few years down the road.
In conclusion, some would say that we’ve spilled our beans of reputation, while others would say that we’ve laid the stepping stone for others to follow. Whatever it might be, I do acknowledge that NFB resolution 2014-12 is now in the record books, to be scrutinized in front of cameras and talked about on blogs and in social networks. Despite my uneasy feeling about its passage, I do realize that it has and will produce impact to be felt in software development and advocacy channels for years to come. At this stage, what we, the blind consumers of iOS (and other mobile operating systems) and their apps can do is to extend our offer of friendship and partnership to app developers, for both users and developers to work together in understanding their needs, be friendly for the sake of our reputation and keep an eye on what can be done. And please don’t forget that app developers are people and users, just like us, as I and other software developers who are blind can testify.
P.S. As I’m one of the young people who’ve debated about the resolution fiercely on social networks, I’m afraid that our “virtual war” could have brought not only our reputation down (I’d say, a lot), but also that of the blindness community. If this is the case, I’d like to formally apologize for our behavior.
No comments:
Post a Comment