Dear Developer,
WWDC 2015 is about to begin and will bring a lot of news regarding iOS, Watch OS, OS X and probably new Apple products and services.
NVApple and Macitynet.it will follow WWDC’s keynote live streaming, talking about every news for their italian readers but we would like to remark about a branch of app development which is frequently not considered as it deserves: desktop and mobile apps accessibility for people with disabilities (especially visual and hearing impairment).
Apple has always developed many technologies which allow Blind, Deaf and Dumb people to work and communicate using its products. However, for these assistive technologies to work properly with your app, it needs to be accessible!
Apple provides different ways to achieve this goal, but the only person who has the power to decide wether his app is accessible or not is only you!
For instance, don’t forget to name the buttons of the nice interface you have designed, explaining the real functions they were designed for.
Also, try to use standard controls as much as possible: screen Readers detect the user interface objects by their semantic role. For example, it’s preferable not to use a clickable skinned element which visually appears as a button but semantically is just static text. If you really need to use custom controls, please take the time to implement support for the accessibility API of the platform you are developing for.
We understand that in the era of cross-platform development it is pretty hard to use native GUI controls, but if you want to leverage the controls provided by any framework please make sure that accessibility is implemented by the framework; if it is not, please consider using another framework or taking the time to make accessible the controls you need to use: if you are using an open-source framework, you could also consider contributing the code you wrote to the community, so that it can be included in the next releases of the framework. It is also possible to make accessible controls implemented using javascript and other related web-technologies.
While producing html contents, please make sure that the html code you produce has a valid doctype and is valid according to it. In complex web applications, use WAI-ARIA – http://www.w3.org/TR/WAI-ARIA – specification as much as possible.
In non-standard skinned controls, if not possible to use a standard alternative, use a dynamic label. Example: if the control is “light” and tapping it toggles light on or off, please label it accordingly: “light on”, and “light off” when pressed once. In othr words, make the value of the label change with the boolean value of the control.
Don’t miss the opportunity to follow the sessions dedicated to accessibility at WWDC15: we are all waiting to see new capabitilies implemented in your applications.
Of course, you’ll get a reward for your efforts:
– Your application will have a larger audience
– You’re application will let you make more money
– You’ll make more people happy
Dear Apple
We appreciate your efforts to improve your great accessible products and your commitment for allowing developers to implement new ways of communication but we’d have a few more humble suggestions for you…
Please give the visibility they deserve, to developers who create Accessible Apps.
Put a special tag in the App description so we can easily recognize not only the Applications dedicated to people with disabilities, but also mainstream apps, which have been created with universal design and accessibility in mind.
Please consider also the suggestion to create a built-in app store tool, available if assistive functionality such as voiceover and/or
zoom are enabled in the device currently browsing the app store, so that a user can:
– rate an app’s accessibility. “5 global stars, 1 accessibility star” for example, based on if the app has been tested by developer for
accessibility or if experience is based on users judgement.
– ask a refund specifically for inaccessibility matters
– know in advance if an app has been tested for accessibility. The user could of course contribute to increase or decrease accessibility rating value with his/her own tests and reviews.
We also have some suggestions concerning:
Braille reading, especially on OSX: Braille output could be improved, as some informations are displayed as extended instead of having a Braille abbreviation; VoiceOver cursor covers all selected text, for example in a web page, and especially if you are reading lines of code it is not so easy to understand.
PDF reading: If you read PDF’s with Preview you cannot listen to their formattings. No links, no headings, no way to mark text, to take notes, and all functions useful to students. Just take this in consideration for the new version of Preview in next OS X version.
