W3C homepageWeb Accessibility initiative homepage

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

25 June 2012

WAI R&D Symposia » Mobile Home » Proceedings » This paper.

This paper is a contribution to the Mobile Accessibility Online Symposium. It was not developed by the W3C Web Accessibility Initiative (WAI) and does not necessarily represent the consensus view of W3C staff, participants, or members.

Accessible Security for Mobile

  • Elizabeth Woodward. IBM Research Human Ability and Accessibility Center, evwoodwa@us.ibm.com
  • Brian Cragun. IBM Research Human Ability and Accessibility Center, cragun@us.ibm.com

1. Problem Description

The proliferation of mobile devices is showing gaps between security and accessibility. Kevin Mitnick, the most wanted computer criminal in the United States in the late 1990’s, once stated that “Companies spend millions of dollars on firewalls, encryption and secure access devices, and it’s money wasted, because none of these measures address the weakest link in the security chain” [1]. That weakest link is people who are unwilling or unable to use the security safeguards as intended. Although there has been focus on the impact of usability on security, there has been less focus on the impact of accessibility on security [2]. With the increasing use of mobile devices, more people are experiencing situational disabilities and a growing number of people are impacted by inaccessible security. The risks inherent in inaccessible mobile solutions require adoption of a new ecosystem to build accessible security into mobile solutions. This paper provides background, describes the issues to consider, suggests solutions where known and indicates areas of future research.

2. Background

The pervasive presence of mobile computing is exposing a need for accessibility that impacts both persons with disabilities (PwDs) and people who experience situational disabilities due to challenging environments. For example, someone trying to listen to a teleconference call from a mobile device in a noisy airport may experience a temporary hearing impairment. Someone who is driving may be unable to use their hands or eyes to interact with their mobile device, creating a temporary mobility and vision impairment. Today, assistive technologies that were previously used by persons with disabilities are being used by many more users experiencing situational disabilities. People who using their smartphones in their cars, for example, are using speech recognition technology to convert their spoken words to commands. They are also using text-to-speech technology to convert text to speech so that they can listen to their email messages while driving. Given that there are an estimated 6 billion cell phone subscriptions worldwide, the need for accessible security is growing [3]. At the same time, enterprises and other institutions are looking for ways to increase productivity of the work force and reduce costs by allowing employees to use their own devices, sometimes called a BYOD (“bring your own device”) model. A recent survey by The Aberdeen Group indicated that 72 percent of responding companies allowed BYOD and a Cisco survey reported that 95 percent of respondents allowed employees to use their own smartphones and tablets in the workplace [4,5]. This raises the need for enterprises to have and provide accessible and secure mobile platforms, applications, and assistive technologies that function as expected in conjunction with emerging mobile security technologies.

While all applications should be scrutinized for accessibility, accessibility and security aspects of mobile platforms and applications deserve special attention. Like the lock on a door, security is often a key to the entire application or platform. When a security test fails accessibility compliance the user is locked out of all function; alternatives and workarounds are often limited or not equal. For example, when a leading antivirus software failed to be accessible, employees with disabilities were required to use a less effective but accessible alternative. As another example, an early version of PDF encryption locked out users of assistive technologies, despite them being displayed to screen. Persons who were blind were unaware that they were displaying confidential information.

Locking customers out of function creates another problem. Consider the well-documented challenges with CAPTCHA, the system that requests that a user type in the characters that they see on the screen in an attempt to ensure that the response is generated by a person. Some visual systems having success rates as low as 71% and some aural systems having success rates as low as 31% and provided alternatives are often ineffective, according to a Stanford University Study [6].

Sometimes the only alternative to an inaccessible security test is for the user to behave in an insecure way – for example employees with disabilities may ask family members, who are not authorized employees, to enter security codes to inaccessible encryption security tests. For non-secure content, workarounds are merely inconvenient; for secure content, workarounds circumvent the entire purpose of security.

Further, mobile security must be effective in public situations, further limiting the options for tests and secure output modalities. Because mobile creates situational disabilities, many more users are affected and the risk for exposure is greatly increased.

Accessible mobile security seeks to address the needs of a secure ecosystem that provides the user full access, while limiting the risks of exposure due to insecure work. In a secure ecosystem, any risk becomes a point of exposure, and incorrectly addressed accessibility issues can create risks. For an enterprise, accessible mobile security must identify and plug all the holes in the ecosystem. Because secure accessible mobile case-studies and solutions are currently limited for enterprises, this paper takes a broad, from the ground-up approach to investigation and deployment.

3. Strategy

There are several key areas that enterprises or other entities supporting employee use of mobile devices need to address in order to create an accessible mobile security strategy and ecosystem. Activities include the following:

  • Determining the appropriate standards, both security and accessibility, with which mobile applications and solutions should comply. These include international, industry, governmental standards as well as corporate requirements. Standards provide both design criteria and metrics for acceptance.
  • Updating any local instructions, guidance and education related to accessible and secure mobile computing. An enterprise or other entity will need to establish the requirement to be both secure and accessible. It must also mandate that solutions are to be inclusive for all users.
  • Determining the accessibility (and any gaps) of high-priority combinations of device, operating system, assistive technology and mobile service carriers. Mobile device accessibility is impacted by the operating system vendor, the device manufacturer, the carrier and application providers. A device manufacturer will tailor an Android release and install that on their device. Carriers will add their own capabilities to the devices and further tailor what gets delivered to the customer. Assistive technologies may or may not function on a given combination of device, operating system and carrier provision. With the prolific combinations of device, operating system, carriers and assistive technologies, the enterprise will need to prioritize the combinations that they are willing to support. The enterprise will need to evaluate the costs of options and determine which combinations are both secure and accessible and will receive funding to be supported. This step is the assessment of alternatives.
  • Determining how to fill accessibility and security gaps, including identification of third party assistive technologies and security solutions. The current practicality is that no out-of-the-box solutions meet a stringent combination of accessibility and security requirements. A complete solution for an enterprise may require third party solutions.
  • Determining which platforms will be supported and at what level. Here, the options identified in the previous steps are weighed against financial realities to determined schedule and funding.
  • Creating platforms for development and testing that offer a way to easily build accessible security into new mobile applications. Development and testing of accessible secure mobile enterprise applications is still mostly roll-your-own. Bringing cost efficiency to both accessibility and security of enterprise application development requires that they be integrated into the development environment and automated test tools.
  • Providing authentication schemes, including biometrics, that provide options for persons with disabilities and those in challenging environments. Authentication that works for one person or one environment may be totally unusable for another person or environment. Unfortunately most security tests offer only a single modality test. This is similar to the early growing pains of CAPTCHA before accessible alternatives were provided.. Security tests need viable alternate modalities built-in.
  • Creating security solutions, including containerization or hypervisor solutions, that are accessible and support assistive technologies in work and personal partitions for “bring your own device” (BYOD) models. The challenge here is not just a secure accessible alternative, but one that can be deployed on a personal device in an enterprise to bring the personal device up to the security requirements of the enterprise. The weaknesses here generally are inaccessible security tests and solutions that don't work well with assistive technologies already deployed on personal devices. As an example, one containerization solution used a common namespace for applications in both the personal and work containers, resulting in an application only being able to be deployed and used in one of the two containers. Third party assistive technologies had to be recompiled to enable use in both containers. Furthermore, the Android Eyes-Free Shell was listed as a launch choice in addition to the work container rather than providing a way to access the work the work container.
  • Evaluating and updating assistive technologies to address security and privacy implications, including those related to exposing enterprise data to third parties. While security solutions sometimes appear to be developed without consideration to accessibility, accessibility solutions also seem to sometime forget security. Assistive technology providers need to scrutinize their processing and artifacts to ensure no sensitive data is vulnerable. Data content at all stages of processing must be secure. Particularly problematic are buffers, logs, and data sent to third party cloud solutions. As an example of the challenge, some enterprises are not allowing employees to use Siri, the iPhone's voice activated digital assistant, because enterprise data is sent to the Apple cloud for processing [7].
  • Determining how compliance monitoring, enablement and enforcement will be done. In an enterprise using BYOD, the enterprise needs to be able to detect security violations and enforce both security and accessibility settings that meet policy mandates? For example, an assistive techology that uses an external server for content processing or storage is a security exposure. A fully secure solution needs verification that users are not using such solutions and creating a security risk. Users may need automated enablement of solutions on personal devices. For example, a user may be unaware that an alternative security test is available in certain circumstances, such as a public place. In the future, it would be desirable for the system to detect the need for and enable the alternative security test. These areas of detection, enforcement, and alternative solutions remain ripe for better solutions.

4. Major Difficulties

There are four major difficulties for accessible security. The first is the rapid transformation and adoption of accessibility standards worldwide, including transformation of Section 508, Twenty-First Century Communications and Video Accessibility Act, and growing adoption of the UN Convention on the Rights of Persons with Disabilities. Accessibility standards as they apply to mobile devices are still being understood. As an example, the applicability of keyboard support for keyboardless devices is not well defined and a subject of current discussion in standards interpretation.

The second challenge is that diversity of mobile devices on the market creates challenges related to accessibility. Mobile device accessibility is impacted by a combination of the operating system, device manufacturer, carrier and assistive technologies provided on the device. The Android market is fragmented with several releases running in parallel. With less control of the devices, trying to ensure an accessible security solution for Android devices is challenging. Some assistive technologies (i.e. Siri) come with security and privacy issues that may prevent their use in certain enterprises.

A third challenge is the emergence of new security technologies that, in many cases, have not reviewed their solutions for accessibility. Device partitioning solutions can create hurdles for accessibility. Where solutions use shared namespaces, assistive technologies may not function in all containers or partitions. In situations where the containerized solution has provided applications for calendar, email and web browsing, not all applications may be accessible.

The fourth difficulty is that some accessibility solutions may have been developed prior to the increasingly stringent requirements for security. These need to be evaluated for secure artifacts, such as encrypted logs and profiles, and transmissions outside of the secure enterprise.

5. Outcomes

By building accessibility into secure mobile strategies and solutions from the start, the solution will be less expensive than addressing accessibility as a bolt-on afterthought. It will further address the weakest links in the security chain before a security risk is created.

6. Open Research Avenues

The complexities of solutions that are both accessible and secure indicate several areas for future and more in-depth research. These include new accessible security authentication techniques, biometric authentications, alternative modalities for security tests and content, methods for enabling secondary security tests, remote monitoring and personalization of devices, creation of frameworks for delivering accessible and security mobile applications, and automated solutions for testing both security and accessibility of mobile applications.

Acknowledgements

The IBM Research Human Ability and Accessibility Center wishes to acknowledge the input of Bill Bodin, IBM Distinguished Engineer for his insight and partnership in accessible security for mobile solutions.

References