Paper 4:
Assessment of Keyboard Interface Accessibility in Mobile Browsers

This extend abstract is a contribution to the Online Symposium on Mobile Accessibility. The contents of this paper has not been developed by W3C Web Accessibility Initiative (WAI) and does not necessarily represent the consensus view of its membership.

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):

Onboard physical keyboards have several accessibility use cases

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:

Browsers

The following mobile browsers were tested:

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

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

References

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.