seleniumhq.org/projects/webdriver/

several books about mobile web programming, provides up-to-date news in his dedicated mobile blog): mobilexweb.com

— Mobi Thinking (DotMobi's resource for marketers with insights, analysis and opinions from mobile marketing experts): mobithinking.com

— Testing (Mobile) Web Apps:

docs.webplatform.org/wiki/tutorials/Testing_web_apps — Investigate what features work across all areas of the

web: caniuse.com and beta.theexpressiveweb.com — WHATWG (The HTML community's homepage):

whatwg.org

— Word Wide Web Consortium (The organization that defines web standards): w3.org

Books

— Mobile First by Luke Wroblewski

— Adaptive Web Design: Crafting Rich Experiences with Progessive Enhancement by Aaron Gustafson and Jeffrey Zeldman

— Responsive Web Design by Ethan Marcotte — Programming the Mobile Web by Max Firtman — jQuery Mobile: Up and Running by Max Firtman

Accessibility 130

Accessibility

Nearly 20% of the world's population have some form of disability. Accessibility has to do with creating a stellar user experience for all of your users and enabling your app to be used by as many people as possible.

Reasons you will want to make your apps accessible include but are not limited to:

— Implementing accessibility can often improve overall us-

ability. For instance, including speech in your app can help blind people and also enable in-car use for drivers.

— Your app may be able to tap into government funded

market sectors such as education where legislation, such as section 508 of the Rehabilitation Act in the US, may mandate an accessible solution.

— Mobile platforms from Apple, Google and Microsoft leverage

their accessibility APIs for UI automation testing; so mak- ing your app accessible can make automated testing easier. Many of your potential users may have a disability which makes it more difficult for them to use mobile technology. These disabilities include, but are not limited to, various levels of sight or hearing impairment, cognitive disabilities, dexterity issues, technophobia and the like. Many of these users rely on third-party utility software to assist them in using their device. This software is sometimes called Assistive Technology, and includes such utilities as screen reading and magnification

apps. iOS includes VoiceOver1 _{which is the front-runner in terms}

of providing an accessible interface on mobile phones. Android has a plug-in approach for Accessibility Software, the most

1 apple.com/accessibility/iphone/vision.html BY Gary Readfern-Gr ay & Juli an H arty

Accessibility 131

common plug-in is TalkBack. Several mobile platforms include screen magnification and other settings to make the user interface more accessible.

For these users, their overall experience is affected by how well an app works with the assistive technology.

The Accessibility APIs look for text in specific attributes of standard UI elements. Screenreaders such as VoiceOver and TalkBack transform the text into spoken audio which the user listens to. The screenreader software may also determine the type of control and related attributes to help provide the user with more contextual information, particularly if no text is available.

Gestures may be affected when screenreaders are enabled. Several screenreaders, including VoiceOver and Android's Explore-By-Touch, enable the user to explore the screen to find what an element is by touching it, before they decide to interact with it. The changes may adversely affect how users

App Assistive Technologies + + User Settings =

UI

Accessibility 132

can interact with your app. By testing your app with these screenreaders you can catch these problems early, before they affect end users. Also, you may be able to redesign the app and pick suitable gestures that work well with and without screenreaders being enabled.

To make your software accessible for users with disabilities, you should follow some general guidelines. If you stick to them, you will also give your app the best chance of interoper- ating with assistive technology that the user may be running in conjunction with your software:

— Find out what accessibility features and APIs your platform has and follow best practice in leveraging those APIs if they exist.

— Use standard rather than custom UI elements where possible. This will ensure that if your platform has an ac- cessibility infrastructure or acquires one in the future, your app is likely to be rendered accessibly to your users — Follow the standard UI guidelines on your platform.

This enhances consistency and may mean a more accessible design by default

— Label all images with a short description of what the image is, such as “Play” for a play button.

— Avoid using colour as the only means of differentiating an action. For example a colour-blind user will not be able to identify errors if they are asked to correct the fields which are highlighted in red.

— Ensure good colour contrast throughout your app. — Use the Accessibility API for your platform, if there is

one. This will enable you to make custom UI elements more accessible and will mean less work on your part across your whole app.

— Support programmatic navigation of your UI. This will not only enable your apps to be used with an external

Accessibility 133

keyboard but will enhance the accessibility of your app on platforms such as Android where navigation may be performed by a trackball or virtual d-pad.

— Test your app on the target device with assistive technol- ogy such as VoiceOver on the iPhone.

You can find a more comprehensive list of guidelines online2_.

The BBC has also published a detailed set of guidelines3 _for

developing accessible mobile apps.

Apple and more recently Google and Microsoft, have increased the importance of their respective Accessibility sup- port by using the Accessibility interface to underpin their GUI test automation frameworks. This provides another incentive for developers to consider designing their apps to be more accessible, which is 'a good thing'.

Looking at the different mobile platforms more closely, it becomes obvious that they differ largely regarding their acces- sibility features and APIs.