It’s scary to think, but around 7 years ago (I think!) I use to do a fair amount of web accessibility testing work. It was still an evolving and much discussed topic. The discussions seemed to have died down now, probably because there is not much new to talk about.
If you are new to the topic and are looking into web accessibility, these are some resources I come across and use again and again:
- The Web Accessibility Guidelines I Vowed I’d Never Write – NorthTemple
- Accessibility MindMap by moi over at Ministry of Testing
What About Accessibility For iOS Mobiles Apps?
I became curious about accessibility for iOS apps after some recent adventures into the world of iOS testing. I was really and truly pleasantly surprised at how accessible iOS devices can be, specifically with the VoiceOver feature.
Of course it doesn’t mean that accessibility happens by default, consideration for accessibility needs to be made during the design and development process of any app, just like you would for any web or software project, right?
On the downside, accessibility for mobiles still seems to be an area that hasn’t been researched or written about in huge amounts. These are signs that it is still an evolving area.
iOS Accessibility Features
To get an idea of what features are available, you can get a good idea by reading the accessibility blurb from the developer section on Apple’s website, which lists features such as:
- White on Black
- Speak Selection
- Tactile Buttons
- Large Text
- iPhone Stereo Headset
- Hands Free Speaker Phone
- Audible, Visible and Vibrating Alerts
- Downloadable, Assignable Ringtones
VoiceOver Almost Blew My Mind (Well It Brought A Smile To My Face)
VoiceOver is pretty awesome – it is what allows users to navigate and interact with iOS app elements. I had initially kind of dreaded seeing what was involved in testing accessibility for an iOS app. I kept having this horrible vision of my previous experience in testing web sites for (lack of) accessibility. There’s no doubt that iOS devices come out top with regards to accessibility.
VoiceOver essentially interacts with iOS elements, for example:
- an app
- a folder
- an image
- audio control
VoiceOver once set up (within General Settings >; Accessibility) has some pretty usable features which can apparently make iOS devices completely accessible for blind people. (Of course, any iOS app isn’t accessible my magic. And accessibility isn’t only about accommodating and designing for blind people.)
I was really impressed when I first discovered VoiceOver, please give it a try on any app, perhaps your own app and with your eyes shut!
- Double tap – Activates the selected item
- Double tap and hold – Drags the item
- Triple tap – Double tap the selected item
- Flick left – Move to previous item
- Flick right – Move to next item
- Hold/drag one finger around to navigate around the screen. When you find what you want put a second finger down to activate it.
- Two finger single tap – Pause or continue speech
- Two finger double tap – starts and stops current action
- Two finger double tap and hold – Set custom label
- Two finger triple tap – Item Chooser
- Two finger flick down – Read page starting at selected item
- Two finger flick up – Read page starting at the top
- Pinch close – Unselect Text
- Pinch open – Select Text
- Hold and twist left or right – Rotate (counter) clockwise – select next/previous rotor setting
- Three finger single tap – Speak page number or rows being displayed
- Three finger double tap – Toggle speech on and off
- Three finger triple tap – Toggle screen curtain on and off
- Three finger flick right – scroll left one page
- Three finger flick left – scroll right one page
- Three finger flick down – Scroll up one page
- Three finger flick up – Scroll down on page
- Four finger single tap near top of screen – Move to first element
- Four finger single tap near bottom of screen – Move to the last element
Take A Photo
Honestly, try taking a photo when in VoiceOver mode. It is pretty cool how it recognises and communicates what is in the picture being taken.
iOS Accessibility Testing Checklist
Testing an iOS app for accessibility is a case of understanding good design, standards and accessibility good practice. Here are some steps (or areas) that I believe should be considered when testing for iOS accessibility.
Step 1 – W3C Guidelines
I believe taking the W3C guidelines and applying them to iOS apps is a very relevant activity. I am sure there is plenty of room for someone to develop the equivalent for mobile, but until that happens we might as well use what has already been created…as a loose guide.
Take this list for example, many of these areas can be applied, checked and tested on many mobile apps, not just iOS:
- 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
- 1.2 Time-based Media: Provide alternatives for time-based media.
- 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
- 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
- 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
- 2.2 Enough Time: Provide users enough time to read and use content.
- 2.3 Seizures: Do not design content in a way that is known to cause seizures.
- 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
- 3.1 Readable: Make text content readable and understandable.
- 3.2 Predictable: Make Web pages appear and operate in predictable ways.
- 3.3 Input Assistance: Help users avoid and correct mistakes.
- 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
Step 2 – Good Practice iOS Consideration
Testing for good practice iOS guidelines is essential. For this you should really become familiar with the iOS environment and the accessibility features. I feel this is a constantly changing area.
Following I’ve highlighted some considerations and questions. The purpose being that the more we are aware of these areas, then the more we can actively test against them.
Accessibility Enabled – This determines whether an element is accessible or not. Testing should watch out for elements that should or should not be made accessible.
Accessibility Labels – This is a short text name or title of a button or control. VoiceOver will default to the control’s regular label if this is not specified. I like to compare this to ‘alt text’ for the web. If buttons contain a plus ‘+’, an image, thumbs up, etc – the label shouldn’t describe the visual representation, they should describe the actions of what will happen, for example: ‘New folder’. It is recommended this starts with a capital letter and full stops are not used.
Accessibility Hints – This is a short description of what the element does. Consider it like an expansion of Accessibility Labels, a slightly more indepth description. For example ‘Creates new folder.’ It is recommended this begins with a capital letter, ends with a full stop and should not include ‘traits’.
Accessibility Traits – Traits can be customised, however thought should be put into this as to whether or not it is appropriate.
Traits come in two forms:
Control Types Traits: Button, Link, Search Field, Keyboard Key.
State Elements Traits: Static Text, Image, Sound, Summary, Selected, Frequently Updated, Not Enabled
Questions In Testing
Accessibility testing related questions to ask:
- If the interface changes, does the visually impaired user get informed? Do messages appear? Or a custom VoiceOver? Does the notification add value?
- Have you created a new type of view or control? Is it accessible?
- Does accessibility information need to change depending on the state of the app? Is information constantly changing?
- Are appropriate elements accessible?
- Are elements perhaps being too accessible? Therefore turning it into a over engineered (and therefore less usable) app?
Step 3 – Get It Tested:
Make sure you test the app yourself. Run through the variety of accessibility features, try it with your eyes shut! Then get someone else to test the app – perhaps a frequent iOS VoiceOver user or, of course a tester 🙂
I honestly still feel quite new to this, it is something I would like to expand on in the future. Interest and time allowing.
Please correct me if I am wrong or missing something obvious somewhere! 🙂
- TouchTalk App
- Web Content Accessibility and Mobile Web:Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices
- Web Content Accessibility Guidelines (WCAG) Overview
- Mobile Web Best Practices 1.0 (2008!)
- Accessibility for iPhone and iPad apps
- The Blind Shooting The Blind
- Make Your iOS App Accessible With VoiceOver