I’ve had several projects lately where I needed to check that a particular resource was accessible on a mobile device for people with disabilities, particularly those who use built-in screen reader software. Given that it has been possible to create accessible mobile-friendly webpages and apps for several years now, it’s surprising how little has been written about assessing mobile accessibility.
Mobile Web
In theory, a standard inspection of the code on a desktop browser should confirm accessibility for mobile devices. As long as a webpage is accessible on the desktop, it should automatically be accessible on a mobile device.
In practice, however, with a responsive design, meaning that the same page shows up in different ways on devices with different browser resolutions, the full-sized rendering of the browser may be accessible, but when things get smaller, what was accessible may not remain so. Ideally, a simple resize of the desktop browser should render the mobile version, although someone doing the evaluation would need to confirm that this is completely true.
Further, people doing the evaluation should be comfortable with the use (and various modes) of the built-in accessibility features of both iOS and Android, enabling these features, and trying to use the website on both types of devices. I’ve recently seen situations where JavaScript validation of form elements worked one way in Windows (using the JAWS screen reader) and a different way on iOS devices where use was by touch instead of a keyboard.
Once this expert review is completed, as discussed in The Value of User Research for Accessibility Evaluations, I’d recommend bringing in representative users who require the accessibility options on iOS or Android and also meet the profile of actual users of the site. Aim to get a variety of representative technologies – perhaps different screen resolutions and a mix of iPhone and Android users. Doing this research in person would be important, as would the use of their devices with whatever custom configurations on the devices they have enabled. Even if you’ve been doing web-based code inspections for desktop, you may be surprised at what you see when representative users using screen readers use the same pages on a mobile device. If possible, record these sessions as well. In the recent study I did, I had to go over these recordings a few times before I fully understood what had happened and what triggered the problem that I had observed. Further, the visual provides great value in helping stakeholders to understand the importance of the issues.
Mobile Apps
Standard methods of web-based code evaluation simply don’t work when dealing with mobile apps. I also don’t know of any tools that will make visible what is not visible once the app is compiled (for example, all the alternative text on a given screen or form labels). For now, the only way that I know how to evaluate mobile apps for accessibility is to enable the accessibility options on the given platform (whether iOS or Android) and then try to use them in the app. Becoming familiar with the various gestures beforehand would certainly be important for this task.
Beyond blindness: User research to assess for other kinds of disabilities?
In addition to having a built-in screen reader, there are a number of other features that would be worthwhile to enable in order to assess for accessibility. With these additional features, however, I don’t know that having real participants would add any significant value over checking with your own devices. These features include screen magnification, larger text (particularly with the new OS 7 feature), contrast, and audio information available in other ways.
Android and iPhone, but what about Blackberry?
At this point, the current Blackberry devices have such limited options for accessibility that I consider evaluation of mobile websites and apps in iOS and Android to be sufficient. That said, hopefully Blackberry will make future releases of the operating system as accessible as the other two mobile operating systems.
