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.

Assessment of Keyboard Interface Accessibility in Mobile Browsers

• Jan Richards, Inclusive Design Research Centre, OCAD University, jrichards@ocadu.ca.
• Alison Benjamin, Previously at Inclusive Design Research Centre, OCAD University, alison.benjamin@gmail.com
• Jorge Silva, Inclusive Design Research Centre, OCAD University, jsilva@ocadu.ca
• Greg Gay, Inclusive Design Research Centre, OCAD University, ggay@ocadu.ca

Problem Statement

Smartphone evolution has generally tended away from onboard physical keyboards towards touchscreen-driven devices. While the trend is usually exemplified by the Apple iPhone, the trend is also evident on other platforms, such as Android, Windows Phone and even BlackBerry. From an accessibility perspective, onboard physical keyboard are not a strict requirement, however, without them, the less obvious software supports for keyboard accessibility can be put at risk.

Background

Onboard physical keyboards can benefit several groups of users with disabilities. The first are people with visual disabilities who can benefit from keys that are discernible by touch without activation, so clearly separated keys, key nibs and standard layouts are also important factors. A second group are people with certain dexterity disabilities, who can benefit from keyboards optimized to minimize inadvertent presses, so key spacing and shape are also important factors. A third group are people who can be confused by the dynamic nature of onscreen keyboards and who can benefit from the consistency of a physical keyboard.

As a result, the industry move towards touchscreens carries intrinsic accessibility risk. However, in reality, these have been somewhat attenuated by the following innovations:

1. Touchscreen-optimized screen readers help certain users explore the screen without accidentally activating controls. For example, VoiceOver on the iPhone (3GS and higher) and Explore-by-Touch mode in Android 4.x [1].

2. Enhanced support for external control, especially via Bluetooth. Size constraints in mobile devices have always meant that onboard physical keyboards tend to be small, which can make them difficult to use for people with certain dexterity impairments. Moreover, such onboard keyboards are not usable at all by people who are unable to touch the devices directly, instead relying on ability switches and/or wheelchair controls. The most common type of external control support that is being added to mobile devices is support for external keyboards, which are then free to be larger than onboard keyboards (though some are small and mobile) and can be equipped with keyguards, if required. The various Bluetooth connection possibilities have also begun to enable external control via ability switches and/or wheelchair controls (e.g., via Tecla Access [2]).

However, while technically, the phase-out of onboard physical keyboards does not appear to be presenting major accessibility problems, one likely negative consequence appears to be an erosion of awareness of the existence of keyboard accessibility among developers of both the platforms and third-party applications. We believe that this may occur because the “typical” devices used for routine testing by developers as they will , as onboard keyboards become increasingly rare

Requirements for Keyboard Accessibility on Mobile Devices

In order to enable effective navigation and control by a person using a keyboard or ability switch(es), the following functional requirements must be met (relevant success criteria in the UAAG 2.0 Public Working Draft [3] success criteria will be cross-referenced):

• Focus Indication: A visual indication of the current focus, so that the user know which control will receive an activation command and so the user can judge their progress towards an intended focus target (UAAG 2.0 1.3.1 Highlighted Items, 2.1.2 Keyboard Focus). For example, VoiceOver adds a focus indicator.
• Sequential navigation: The ability to move through all of the controls from start to end (UAAG 2.0: 2.2.1 Sequential Navigation Between Elements). For example, VoiceOver supports full sequential navigation in which the user can swipe through every operable control on the screen. In contrast, some Android devices require the use of the appropriate directional arrows (up, down, left, right) in order to focus some items.
• Focussed controls are operable: Once focus has been navigated to a control, it must be operable with the keyboard (UAAG 2.0: 2.1.1 Keyboard Operation). For example, on Android devices, after using the D-pad controls to move focus to a button, the user can press Enter to activate the button.
• Enough time: Effective keyboard access requires that people be able to enter keystrokes at their own pace (2.1.1 Keyboard Operation). For example, a person using a scanning keyboard will tend to enter keystrokes relatively slowly.
• Non-sequential navigation: is provided to make keyboard navigation more efficient (UAAG 2.0: 2.3.1 Direct Navigation to Important Elements). For example, a mobile device may support “heading navigation” in a web page or a “page down”-type warp functionality.
• Keyboard trap protection: Mobile devices must ensure that keyboard focus is not permanently held by an application or rendered content (2.1.5 No Keyboard Trap). For example, in many cases, a “Home” button is provided to enable the user to return quickly to a Home screen.

Onboard physical keyboards have several accessibility use cases

• people with visual disabilities and those who require an alternative to seeing (e.g. those using a phone in unclear conditions) benefit from keys that are discernible by touch without activation, have clearly separated keys, have key nibs and use a standard layout.
• people with certain dexterity disabilities, people with larger hands, and those who rely greatly on typing (e.g., in email, browser and SMS applications) can benefit from keyboards optimized to minimize inadvertent presses, with clearly spaced keys and a cupped shape
• people who can be confused by the dynamic nature of onscreen keyboards and who can benefit from the consistency of a physical keyboard.

Strategy

In order to ensure keyboard accessibility, mobile software developers will need to be aware of the important accessibility role played by keyboard interfaces and will need to test this functionality as a routine part of QA.

This paper records an attempt to conduct such an evaluation with respect to keyboard accessibility of web content as rendered on a range of mobile web browsers, making use of keyboard accessibility functionality where an onboard physical keyboard is not present. Testing was performed in March 2012.

Mobile Devices

The following mobile devices were tested:

• Samsung Galaxy 551: This Android (v2.2) touchscreen device has an onboard physical QWERTY keyboard.
• Samsung Galaxy Nexus: This Android 4.0.1 touchscreen device was tested with the Tecla Access system (ver. 0.6beta).
• iPhone 4S with iOS 5.1: This iPhone has the newest version of VoiceOver, which builds on native iOS support for system-wide keyboard navigation.

Browsers

The following mobile browsers were tested:

• iPhone 4S Safari
• iPhone 4 Opera Mini
• Android4 Browser
• Android4 Firefox
• Android4 Opera Mobile
• Android4 Chrome Beta
• Android2 Browser
• Android2 Opera Mobile
• Android2 Dolphin Browser HD

As a control, we also tested the same websites on two desktop browsers:

• (Desktop) Safari [4] (Mac OS)
• (Desktop) Firefox 10.0.2 (Windows)

Websites

We identified two popular websites (FaceBook and YouTube) as well as a more accessible control site, the W3C’s site. The mobile and browser based versions of each site were examined. In each case, the tester attempted to reach and operate as much of the functionality as possible using the mobile device control method (listed above).

Table 1: Tested websites

Site	Type	Desktop URI	Mobile URI
Facebook	Social Network	http://www.facebook.com (logged-in)	m.facebook.com (logged-in)
YouTube	Online Video	www.youtube.com	m.youtube.com
W3C	Home page	http://www.w3.org	http://www.w3.org (mobile view)

Outcomes

The results of the testing show that robust keyboard accessibility is technically feasible (e.g. iPhone 4S Safari), many browsers are not paying attention to keyboard accessibility (e.g. iPhone 4S Opera Mini, Android4 Firefox)

Detailed results of the testing are presented in Table 2.

Table 2: Tested Browsers

Mobile Browser	Browser chrome keyboard accessible?	Sequential Navigation?	Non-sequential Navigation?	Focus Indicator?	Are controls operable once they have focus?
Desktop Safari (Mac OS)	Yes	Yes with exceptions: -facebook.com: some sequential navigation, but could not navigate to requests, messages, notifications at top of page, and some other elements. Could not tag a post with a user or your location, could not access the Facebook Chat sidebar. -youtube.com: some sequential navigation, but video controls and some other buttons could not be reached via tab-shift/tab. Video controls can be accessed first by mouse and then with keyboard, but there is a keyboard trap.	Yes via the VoiceOver rotor.	Yes with exceptions: -youtube.com, facebook.com: generally, yes, but not all navigable elements receive highlighting focus.	Yes. Enter or space activates an item. Arrow keys to operate drop-down menus etc. -youtube.com, facebook.com: in general, elements that can receive highlighting focus are also operable
Desktop Firefox 10.0.2 (Windows)	Yes	Yes (using “tab”) with exceptions -facebook.com: genrally yes -youtube.com: generally, but not “+” buttons in listed videos	No. But planned [5].	Yes with exceptions because user can override with styling -Facebook: generally except login and signup buttons -YouTube	Yes. Enter or space activates an item. Arrow keys to operate drop-down menus etc.
iPhone 4S Safari	Yes	Yes  with exceptions: -m.facebook.com: some elements (e.g. messages, notifications, friend requests, tag a post with a user or location, security settings) are not accessible to VoiceOver. -m.youtube.com: can’t navigate to icons at top of page (e.g. menugrid and search icon), can navigate to all elements in video interface (e.g. share, dislike, like).	Yes Navigation by headings, can be done with the VoiceOver rotor which has keyboard alternatives [6].	Yes with exceptions: -m.facebook.com: VoiceOver provides focus, but some elements which should receive focus do not receive focus, e.g., elements to tag a post with a user or location, to select the level of privacy control, and messages, notifications and friend requests. -m.youtube.com: VO provides focus, but some elements which should receive focus do not receive focus, e.g., menugrid, search, like, dislike.	Yes -m.facebook.com, m.youtube.com: Elements that can receive focus are generally operable.
iPhone 4S Opera Mini	No	No	No	No	No
Android4 Browser	No, e.g. Address bar, browser settings, not accessible [7].	No	Yes with exceptions: -m.facebook.com -m.youtube.com: can't access links at bottom of page, video player controls. Focus order is not intuitive. -m.youtube.com: links at bottom of the page and video controls (e.g. to start playing a video or control a video when playing) cannot be navigated to	Yes with exceptions: -m.facebook.com: No operable elements receive focus highlighting. Opening the Tecla keyboard on the Facebook login page can allow user to enter in username and password, but no No, e.g.: -m.youtube.com: not all elements receive focus highlighting, e.g. play control to start playing a video; pause, forward, back video controls once a video is playing, and other elements (e.g. like, dislike, share videos) and the links at bottom of the page	Yes with exceptions: -m.facebook.com. No elements are operable. Note: At login page, opening the Tecla keyboard can allow user to enter in username and password and login. But once logged in, nothing is operable. -m.youtube.com: links at bottom of the page; pause, forward, back video controls once a video is playing, and  other elements (e.g. like, dislike, share videos) are not operable
Android4 Firefox	No [8], e.g. Address bar, browser settings, not accessible	No	No	No	No
Android4 Opera Mobile	No. Opera’s controls (e.g. back, forward, tabs, “O” button to access bookmarks, history, etc.) are not accessible.	No Note: elements can be navigated to via a virtual cursor which is controllable from Tecla keyboard.	Yes	Yes	Yes Note: elements can be operated via virtual cursor which is controllable from Tecla keyboard.
Android4 Chrome Beta	No	No	No	No	No
Android2 Browser	Yes. Typing on the keypad can activate the address bar. Combination of D-pad, physical back button, and Menu Key can be used to adjust browser settings	No	Yes with exceptions: -m.facebook.com -m.youtube.com: can’t access video player controls and other elements (e.g. like, dislike, share videos).	Yes with exceptions: -m.facebook.com: Excepting friend request, messages, and notifications icons (which have small orange circular focus indicator) and some links, many operable elements do not receive focus highlighting. -m.youtube.com: not all elements receive focus highlighting, e.g. play control to start playing a video other elements (e.g. like, dislike, share videos) and the search text input field.	Yes with exceptions: -m.facebook.com [9] Many elements e.g., message, notification and search overlays at top of the interface are not operable. -m.youtube.com: not all elements receive focus highlighting, e.g. play control to start playing a video other elements (e.g. like, dislike, share videos). Some controls that do not receive highlighting focus (e.g. search text input field) are operable.
Android2** Opera Mobile	No. Opera’s controls (e.g. back, forward, tabs, “O” button to access bookmarks, history, etc.) are not accessible to the keyboard or to the Opera cursor.	No Note: elements can be reached via virtual cursor which is controllable from the D-Pad.
Android2** Dolphin Browser HD	No with exceptions: Limited ability to control the browser chrome with a combination of the QWERTY keypad, D-Pad and hardware buttons (Back + Menu Key) but many other functions (e.g. create a new tab) not accessible. Aspects of chrome (e.g. dialogs) lack focus highlighting.	No	Yes, with exceptions: -m.youtube.com: can’t access video player controls and other elements (e.g. like, dislike, share videos).	Yes, with exceptions: -m.youtube.com: some elements that can be activated (e.g. play button on video) do not receive focus although they respond to input.	Yes, with exceptions: -m.youtube.com: not all elements receive focus highlighting, e.g. play control to start playing a video other elements (e.g. like, dislike, share videos). Some controls that do not receive highlighting focus (e.g. search text input field) are operable.

Open Research Avenues

• Strategies for raising awareness among developers (e.g. Automated mobile keyboard accessibility testing tools)
• The degree to which focus highlighting must be user-customizable on mobile.
• Comparison of strategies for non-sequential navigation on mobile.

Acknowledgements

The authors would like to acknowledge Bell Mobility and Komodo OpenLab for providing test devices and the Government of Ontario and the AEGIS Project for supporting development of Tecla Access.

References

• [1] "AndroidOS: About Explore by Touch". http://support.google.com/ics/nexus/bin/answer.py?hl=en&answer=2492750 (accessed March 2012).
• [2] "Tecla Access: About Tecla Access". http://mobile-accessibility.idrc.ocad.ca/projects/tekla (accessed March 2012).
• [3] Allan, J., Ford K., and Spellman, J. “User Agent Accessibility Guidelines 2.0” (2011). http://www.w3.org/TR/2011/WD-UAAG20-20110719/
• [4] Safari setting: “Preferences > Advanced > Universal Access > Press Tab to highlight each item on a webpage”
• [5] "Mozilla: About Us Community Map Our Projects Get Involved Mozilla Keyboard Planning FAQ and Cross Reference". http://www.mozilla.org/access/keyboard/ (accessed March 2012).
• [6] AxS Lab. "iOS VoiceOver Gesture, Keyboard & Braille Shortcuts". http://axslab.com/articles/ios-voiceover-gestures-and-keyboard-commands.php (accessed March 2012).
• [7] "Android Issues: Issue 27022 Input method app cannot access built-in browser chrome" (http://code.google.com/p/android/issues/detail?id=27022) (accessed March 2012).
• [8] Mozilla has announced they are working to increase accessibility in their mobile browser code-named “Fennec” (http://www.marcozehe.de/2012/05/08/first-round-of-accessibility-support-for-android-in-mobile-firefox/). However, this was announced after the testing for this paper.
• [9] With JavaScript disabled, the same barriers appear.