Content Copyright © 2015 Bloor. All Rights Reserved.
In the final analysis the accessibility of any information or communication technology (ICT) is determined by the experience of the end-user. If the end-user finds it difficult to complete a task then the technology is not accessible.
The probability that the end-user will enjoy the experience will be increased by following industry guidelines, the use of good development practices and testing at all stages in the development.
Up until now the testing of mobile applications has been a manual process. Develop the app and then test it for accessibility:
By the developer using:
VoiceOver on iOS or TalkBack on Android to hear if it makes sense.
Single switch input to see if the app can be navigated and used.
Eyeball the application to estimate if: colour contrast is sufficent or buttons big enough etc.
By end-users with a variety of disabilities and assistive technologies and none trying to use the app.
This process is problematic because: it happens late in the process, it is slow and expensive and still will not pick up all issues because it is difficult to find a wide enough group of end-user testers.
The most obvious way to reduce the number of issues identified by the testing is to have good development guidelines. The BBC have produced ‘Mobile Accessibility Guidelines’ at www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile and the UK Government has produced ‘Government Services Design Manual’ at www.gov.uk/service-manual both are publicly available and highly recommended.
For website development there have been automated testing tools available for several years, such as WAVE see wave.webaim.org/toolbar/ and the Accessibility Management Platform from SSB BART www.ssbbartgroup.com/amp/. These tools analyse the HTML and identify a range of accessibility issues. They are an essential part of the development process and will reduce the number of problems found during user testing.
It is important to recognise that automated tests do not remove the need for end-user testing as there are many issues they cannot identify. However the end-user testing will be able to concentrate on these more complex issues and hence reduce the time and cost of testing.
Up until now there has not been an equivalent tool for testing mobile apps. IBM announced the ‘Mobile Accessibility Checker’ at the Mobile World Congress in Barcelona earlier this month (March 2015).
Mobile Accessibility Checker helps developers identify and correct usability issues early in development to deliver an optimised mobile user experience. The tool automatically alerts developers to accessibility breaches, such as colour contrasting and keyboard navigation and focus, and recommends corrections to help developers adhere to industry standards and government regulations. Current accessibility tools can only check for one breach element at a time and do not account for individuals with poor vision, so the contrast is not adjusted. In addition, control spacing, button size and font size are not accounted for in current tools.
As a part of the Mobile Accessibility Checker rollout, IBM is collaborating with SSB BART Group, an accessibility software and services organisation, to create a new mobile accessibility management platform utilising Mobile Accessibility Checker. The SSB BART Accessibility Management Platform for Mobile integrates IBM’s Mobile Accessibility Checker to produce an automated testing engine for native mobile applications and mobile web content, designed to increase the user experience on both iOS and Android devices.
IBM Mobile Accessibility Checker is also available as a service or software component from IBM.
The Checker is designed to be integrated into the development process so many issues can be discovered and resolved at the coding rather than the testing phase.
This integration into the coding, or creation, phase is something I would like to see in more tools. Website development tools, content management systems, document creation tools, video production tools etc should all have the option to check for accessibility, prompt for accessibility extras, advise the creator of errors and suggest solutions. If this was all integrated into the creation process then there would be much more accessible ICT at a minimal extra cost.
The IBM Mobile Accessibility Checker is a large step forward towards this goal.