Making accessibility part of your developer DNA<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p><a href='
http://www.imore.com/making-accessibility-part-your-developer-dna' title="Making accessibility part of your developer DNA"><img src='
http://www.imore.com/sites/imore.com/files/styles/large_wm_brw/public/field/image/2014/07/speak_selection_iphone_5s_hero_fixed.jpg?itok=9FjWXDLb' />[/url]</p> <p class="intro">Making accessibility a priority.</p> <p>AltConf 2015 I gave a talk entitled, "
Accessibility Is a Moral Imperative". It was a high-level talk about why it is so important for developers to keep accessibility in view while developing for the Mac, for iOS, and for the web. What the speech lacked was any technical details on how that can be accomplished. With this follow-up, my goal is to provide a non-technical guide to making accessibility a part of your developer DNA, whatever your app or website happens to be.</p> <h2>Don't get in the way of what's already there</h2> <p>The biggest challenge to accessibility in iOS is not coming up with new and interesting ways to make your app more accessible. Rather it is simply not getting in the way of the accessibility features that already come free with iOS. By now, all developers know that iOS is highly accessible by the blind and physically challenged. What you may not know is that every accessibility feature can be defeated by developers, and often is.</p> <blockquote class="big right pull"> <p>What you may not know is that every accessibility feature can be defeated by developers.</p> <p>VoiceOver can be defeated by including hidden, junk text in your app. Flipboard is a prime culprit. When you read a Flipboard article, all you see is the text of the article. But when a blind person tries to use VoiceOver to read that same article, the text is garbled and loaded with intentional misspellings. The result is that the text is rendered unreadable by the blind.</p> <p>Read Screen is a little known feature that allows you to swipe down from the top of the screen with two fingers and have your iPhone or iPad start reading from whatever is visible at the top of the open window. In Safari, if you are reading a long article, you can scroll to a particular section, flick down with two fingers, and have the article read aloud from that point.</p> <p>But that feature is easily defeated by the way web page elements are prioritized. Instead of reading what is visible at the top of the windows, this feature can be forced to read all the invisible menus, then the ads, and then the dozens of article listings scattered about the page. You could have ten minutes of reading before getting to the main article. Furthermore, rather than starting where you want to start, the reader is forced to the top of the page to read the developer's priority instead of yours. This amazing feature is rendered useless on many pages.</p> <h2>Barriers to accessibility</h2> <p>With so much free accessibility available to developers, you might wonder why so many apps defeat the built-in features. I don't believe for a moment that any developers are twirling their mustache, intentionally crippling accessibility features critical to those who need them. Instead, here is what I think may be going on behind the scenes:</p> <h3>1. The Path of least resistance</h3> <p>It is not that any developer is evil or lazy, it's that they're human. Humans tend to take the path of least resistance. If a developer can accomplish their goal in three steps, they will do it. But including an accessibility feature might require an additional five steps. Implementing dynamic type is a good example. Even if they think about the feature, they may deem the extra effort or time not to be worth it.</p> <h3>2. DRM</h3> <p>Developers who are trying to make a living with their content do not want to allow their work to be easily copyable, or easy to read without the surrounding ads on which their monetization is based. They protect their work by employing schemes that defeat copy/paste and ad-stripping. Unfortunately, I can't think of any ways to implement DRM that do not also adversely effect accessibility. Apparently, neither can they.</p> <h3>3. Highly stylized features</h3> <p>
The Verge is one of the most heavily designed sites on the web. They do award-winning work that makes their content come to life in a modern, visual context. However, almost every design choice they make clashes with accessibility. This is common for design-centric sites and apps—magazine apps in particular.</p> <p>In magazine apps, layout is king. It comes in ahead of all other considerations. Developers are so focused on how they want every line to look on the page, they never consider how the reader might like to see it.</p> <p>Design-heavy apps do not tend to allow for easily resizable fonts, for example, or arrangeable page elements. It is the developer's way or the highway. There is no evil intent. They have a beautiful idea in mind. They just never considered its effect on accessibility.</p> <h2>Accessibility is NOT a technical issue</h2> <p>The lack of accessibility in apps is not because developers don't know how to implement the technical details. Developers do not need anyone to tell them how to include larger fonts, for example. They already know how to implement Text-to-Speech (TTS) and other accessibility options. If it were just a matter of technical details, accessibility would be easy. The challenge is getting developers to make accessibility a priority.</p> <p>Does a media company want their content to be accessible, or want it protected from theft? If that is the choice before them, accessibility is going to lose almost every time. And it does.</p> <p>If some accessibility features are difficult to implement and take time away from money-making aspects of a project, what is the pitch for getting devs to put the time and energy into dynamic type? As a former salesman, and a fan of dynamic type, I can't think of such a pitch.</p> <blockquote class="big right pull"> <p>It took the force of law to make businesses start adding wheelchair access, parking, and restrooms.</p> <p>For designers, making their apps more accessible would mean giving up part of their app's identity. They are reluctant to provide anyone with the opportunity to break their format. To them, it is like pouring catsup on a fine steak.</p> <p>These are not technical issues. At least, they are not solvable by current technology.</p> <p>I am reminded of accessibility issues in physical spaces. It took the force of law to make businesses start adding wheelchair access, parking, and restrooms. For the most part, they did the least they legally had to do. To this day, braille or large print menus in restaurants are rare. They are not technically difficult to do. Every eating establishment, regardless of size, could have at least one Braille and large print menu tomorrow. They would rather spend $100,000 on design and layout than $100 to make a plain, easy to read list.</p> <p>It is not about technology. It is, and always has been about incentive. That is why I focused my talk on accessibility being a moral imperative. At the end of the day, that is the only incentive that will move the needle in the right direction.</p> <h2>The path to accessibility</h2> <p>If you want to know how to better serve those with accessibility needs, I offer this general advice:</p> <ul><li>Don't get in the way of what is already there</li> <li>Make all fonts user adjustable. </li> <li>Make as many items speakable as possible</li> <li>Test your app on people with special needs</li> </ul><p>Having already discussed the first one, let's take a brief look at the other three:</p> <h3>Fonts</h3> <p>Sometimes, in content-heavy apps, developers will provide a few text sizes such as small, medium, and large. But those sizes are all relative. A person who does not see very well does not see those sizes as small, medium, and large. They see way too small, still too small, and nice try, but I'm still going to have to move on to another app. If you are not going to use dynamic type, at least make the fonts user adjustable. Regardless of how big you think the font is, if it is not big enough for the reader, it is not accessible.</p> <h3>Text-to-Speech (TTS)</h3> <p>I look forward to the day when everything on a screen is speakable. Text-to-Speech (TTS) is already here, and more than good enough. Imagine a lightweight script that could automatically select the text in a given section, and then read it aloud with one of the built-in voices just by tapping a Play button. Some websites already do this. There is no reason text-heavy apps can't do this as well. My understanding from developer friends is that all the APIs are freely available to devs if they wanted to go this route.</p> <p>This type of solution would be ideal on the Apple Watch, as it has a small screen, necessitating small text. Having those snippets of text speakable would answer most accessibility prayers on that device.</p> <h3>Inclusive testing</h3> <p>Finally, test your apps on people with special needs. There are schools for the blind, and rehabilitation programs for the blind all over the country. Even if you do not know anyone personally, willing, blind and partially sighted testers are easy to find. (You can email me for more specifics.) The point is, unless you have tested your accessibility on someone that actually uses accessibility features, you have not actually tested your accessibility.</p> <h2>Accessibility for all</h2> <p>The good news is if you are asking how you can make your apps even more accessible, then you are already most of the way there. The special needs community is a rather forgiving lot. We reward effort, even those that are spectacular failures. Put forth the effort, and we will help you refine it.</p> <p>In some ways, access is like justice: It has to be for all if it is to be fully realized.</p> </div></div></div><br clear='all'/>
<a href="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/1/rc.htm" rel="nofollow"><img src="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/1/rc.img" border="0"/>[/url]
<a href="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/2/rc.htm" rel="nofollow"><img src="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/2/rc.img" border="0"/>[/url]
<a href="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/3/rc.htm" rel="nofollow"><img src="
http://rc.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/rc/3/rc.img" border="0"/>[/url]
<img src="[url]http://da.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/a2.img" border="0"/>[/url]<img width="1" height="1" src="
http://pi.feedsportal.com/r/234566343017/u/49/f/616881/c/33998/s/48909a0e/sc/28/a2t.img" border="0"/><img width='1' height='1' src='
' border='0'/><img src="
http://feeds.feedburner.com/~r/TheIphoneBlog/~4/H1NUQRKyhQA" height="1" width="1" alt=""/>
Source:
Making accessibility part of your developer DNA
