Tablet tests with low vision users: Usability
17. June 2014
The usability of tablets for low vision users is strongly linked to the use of zoom magnification, but other aspects such as bad contrast or illegible virtual keyboards also contribute.
This article describes the most common problems experienced by low vision users in our tests, and proposes some remedies.
The tablets tested and the task
We have tested the following five tablets (German version) with low vision users:
- ASUS Memopad (Android 4.2.2, Asus-Skin)
- Sony Xperia Tablet (Android 4.2.2, Xperia UI-Skin)
- Samsung Galaxy Tab Pro (Android 4.2.2, TouchWiz-Skin)
- Apple iPad 4 (iOS 7.1)
- Windows Surface Pro 2 (Windows 8.1)
Users were given a task involving the default mail and calendar apps on the respective tablets:
- Look for a mail with a particular subject line
- Find meeting information in that mail
- Open the calendar app and create a new entry for the meeting
- Go back to the mail app and respond to the mail
The results below summarise some important usability issues that we identified when analysing the test notes and memos written straight after the tests.
Using the virtual keyboard
A very common problem in our user tests was that the keys on virtual keyboards were simply too small to be read comfortably by low vision users. The keyboards on the Surface Pro 2 and the Asus Memopad were the easiest to read without magnification: at 17 pt, the letters were the largest. With a size of 15 pt, the iPad key characters were smaller, but still relatively easy to read as they had been set to bold (via the system settings Accessibility > Bold Text).
Fig. 1: Sony Xperia Tablet virtual keyboard. The Sony keyboard had the smallest letters measuring just 12 pt. The keys (black on light grey gradient) offer ample room for larger letters. The default view shows lower case letters.
Fig. 2: ASUS MemoPad virtual keyboard. While the keys (black on light grey gradient) have roughly the same size as on the Sony tablet, the letters on the ASUS MemoPad keyboard are much larger (17 pt).
Fig. 3: Samsung Galaxy Tab Pro virtual keyboard. The keys (black on light grey) are rather small, measuring only 13 pt. The keyboard imitates a 3D look.
Fig. 4: Microsoft Surface Pro 2 virtual keyboard. The letters on the Surface keyboard are quite large with 17 pt (measured on capital letters; the default view shows lower case letters). In contrast to all other keyboards in the test, letters are rendered white on a dark grey background.
Fig. 5: Apple iPad 4 virtual keyboard. Measuring just 15pt, the letters on the iPad keyboard are smaller than on the Surface and the Asus tablet, but the strong contrast (black on white) and the fact that captial letters are rendered in bold makes them relatively easy to read.
When zooming into screen content, there is an important difference between the behaviour of Android tablets vs. that of the iPad and the Surface tablet. On Android, the virtual keyboard is not magnified, it stays in position. For many low vision users, the unmaginfied keys are simply not large enough. Users strained to recognise them or guessed, often helped by the knowledge of the familiar QUERTZ layout.
In contrast, when zooming in on the iPad or the Surface Pro tablet, both screen content and virtual keyboard are magnified. This facilitates the recognition of keys, but it makes using the keyboard very cumbersome as it is only partly visible. Often during writing, the visible section has to be moved to get to the desired keys. Users therefore tended to use the keyboard unmagnified. Moving back and forth between interacting with the virtual keyboard and checking the written text elsewhere was time-consuming and often difficult.
A problem for all users of the virtual keyboard is that only a part of the screen remains visible above it, sometimes less than half the screen. Here, the iPad worked better than the competition due to its width-to-height ratio of 4:3, which leaves more usable screen real estate visible than on any other tablet in the test.
- Operating systems and skins should provide a good default size and contrast of keyboard keys so that more users can use the keyboard without magnification. On all virtual keyboards in the test, it would be possible to crank up the letter size, often significantly as on the Sony and Samsung tablets. This option could be included as additional accessibility setting. Being able to set letters to bold (as on the iPad) would also help.
- A basic setting of the zoom function should be the option to include or exclude the keyboard. Peferably, this setting should be easy to toggle via a gesture. iOS or Windows users who can use the keyboard unmagnified would benefit from this option, as would Android users who can only recognise magnified keys. Apple will offer this option in its newest iOS version, iOS 8.
- There is another way to support low vision users of tablets: offer a pop-up enlargement of the currently selected key, a feature already in use on smartphone operating systems (Android, iOS on the iPhone, and Windows Phone 8). Fig. 6 shows the implementation on the iPhone. Such a pop-up not only helps by magnifying the letter: crucially, it is displayed above the key position covered by the touching finger. This could be an additional option in the Accessibility settings.
Fig. 6: iPhone virtual keyboard: When touching the key (the letter has a size of 9 pt), a pop-up reproduces the letter above the key at 200 % magnification (18 pt). Android smartphones and Windows Phone offer a similar pop-up display.
Insufficient contrast, enhanced contrast settings
Often, the default contrast of tablet interface elements is too low. This can apply to headings, active text, form labels, placeholder text, buttons and other controls, but also to rulers and grids, which are especially important when using content magnified. Worst offender here is surprisingy the iPad. Important elements like form field labels and placeholders have very poor contrast. Placeholders with a contrast as poor as 1.65:1 (required in line with WCAG would be 4.5:1) are the only labels for some fields in the pop-up window for a new calendar entry. Badly contrasting when not activated (not: inactive) are also the ubiquitous iOS sliders/toggle buttons in apps und system settings.
Windows 8 (tested on the Surface Pro 2) is the only operating system offering users fully configurable high contrast settings of text, backgrounds, links and so on.
Samsung's TouchWiz skin goes beyond Google's offerings in vanilla Android by offering a setting for inverse colours, as does the iPad. It should be remembered however that poor contrast is still poor contrast when colours are inverted, as fig. 7 demonstrates. Colour inversion cannot replace user-configuarable contrast settings.
Fig. 7: iPad calendar seen with colour inversion. Important interface elements like text field placeholder texts or select elements to specify Repeat, Invitees or Alerts appear dark grey on black without outline. Especially when colours are inverted, they are hardly recognisable even for users with good vision.
The deficiencies of the colour inversion mode became apparent in a test where a low vision user who routinely uses a inverted contrast mode on the PC tried to carry out the test task of creating a new calendar entry on the iPad (compare fig. 7). The thin, poory contrasting outlines separating the pop-up window and the poorly contrasting placeholder text for important inputs meant that after sereval agonising attempts, the user finally gave up.
- Make sure that all interface elements have sufficient default contrast (at least 4.5:1)
- Offer not just colour inversion, but proper user-configurable contrast modes (like Windows 8)
- Offer options for selecting strong contrast for rulers, grids and element outlines so that these will have better visibility both in the default view and when used with colour inversion
Unnoticed context changes
A prime exampe for unnoticed contrast changes is the opening of new pop-up windows outside the currently visible magnified area (such as the pop-ups displayed when creating a new calendar entry on the iPad or the Samsung calendar). Such pop-ups are not interpreted as a new view, i.e., the zoom is not reset to 100% as it happens on new screens in the "vanilla" and Asus versions of Android.
The example in fig. 8 shows a pop-up window for a new calendar entry on the iPad. The pop-up has been brought up by carrying out the secondary 'hold' gesture on a hour slot in the day view. The pop-up opens on the right side of the screen, outside the magnified area (which is shown as outline in the top-left quarter of the screen). Even tapping on the hour slot (which his now marked in blue) has no effect: the inserted pop-up is already on display, it is just not visible for the zoom user.
Fig. 8: iPad calendar, pop-up window problem. When zoomed in with 250% magnification on the day view, a pop-up window for creating a new calendar entry appears outside the visible area and is not noticed by the zoom user (the visible area is indicated by a frame in the top left corner).
This is not an easy one. Several approaches are feasible for solving the problem of pop-up windows going unnoticed for zoom users:
- Open pop-up closer to the trigger so it has better chances of being (partially) visible in the magnified area
- Use a different design approach: New screen instead of pop-up window on the same screen
- Offer an explicit hint to the pop-up window in the visible area
- Revert zoom to 100% when a pop-up is opened
- Move magnified section to show (parts of) the pop-up window
Which solution is best in any particular case should be determined through user testing. Other and better solutions may be feasible.
Spatial correlation of connected information elements
Zoom users frequently experience issues when informaton elements that are connected (such as a button and its label, or a calendar day and an event entry) are divided by an unneccessary large gap (compare fig. 9). In these cases, magnification users often have to move the magnified area to resolve the meaning of the control or connected information elements.
Fig. 9: WLAN switches on iPad, Surface Pro 2, and Sony Xperia tablet (top down): The gap between switch and label is unneccessarily large especially on the iPad and on Windows 8. When using stronger magnification, both won't fit into the same magnified area. On Windows 8, the lack of horizontal rulers makes the allocation of switch and label even more difficult. On Android tablets, the apparently fashionable gap is also in evidence, but it is usually smaller.
A related problem appears in the allocation of connected information elements in the magnified view. There is often less context available to determine what belongs together. An example are calendar entries seen in the month view (compare fig. 10-12).
Fig. 10: Calendar entry on the ASUS calendar seen with zoom magnification (about 250%)
On the Asus calendar, the correct allocation of calendar day and entry rests on the low-contrast grid lines (see fig. 10). This view is largely equivalent to what users see on the (untested) "vanilla Android" Nexus calendar.
Fig. 11: The same magnified calendar entry on the Asus calendar. Here, the grid lines have been edited out to illustrate the allocation problem.
Many low vision users will not perceive the thin and poorly contrasting grid lines. Fig. 11 shows the Asus calendar month view with the same entry, but grid lines have been removed to simulated the perception of a low vision user. The right-aligned positon of the date and the left-aligned entry can easily lead to an allocation error: Users in the test allocated the entry "Gleitarbeit" (flextime) to the date 22, not the correct date 23.
The Sony calendar showed a similar problem, but grid lines had slightly better contrast here. The Samsung calendar S-Planner offers a better solution: both date and entry are left-aligned and in close proximity (see fig. 12).
Fig. 12: Calendar entry on the Samsung tablet. Samsung has a better solution: while the contrast of the grid lines is hardly better than on the Sony, both date and entry are left-aligned and in close proximity and can therefore be allocated without grid lines.
- Make sure there is only a small gap between connected information elements
- Use high-contrast rulers, grids and outlines to ease allocation
- The setting of a hight contrast mode for rulers, grids and outlines could be an option in the accessibility settings
Lack of focus visibility
When low vsion users provide text input, the text cursor is often very difficult to spot. When it was set accidentally (for example, by touching copied reply text in a mail edit window) users did not know at what position their input would be registered. Only Windows 8 offers the option to enlarge the cursor. But at the largest setting, the cursor remains just 1px wide with an outlined dot at the end.
Both Android and Windowss 8 fail to keep the focus visible when zoom and the respective screen reader are used at the same time. The horizontal swiping gestures that make Talkback (Android) and Narrator (Windows) traverse the screen elements do not reset the visible area: the focus wanders off-screen. The only notable exception: the iPad. Here, the visible area is reset so that the currently focused element is always visible.
- Make cursor size and appearance customisable in accessibility settings
- Folllow Apple's example and reset the maginified area to keep track with the visible focus when zoom and screen reader are used at the same time
Recognition and interpretation of elements (icons, controls)
Many visual icons and controls were not easily recognised by low vision users. Unlabelled symbols like Reply or Forward in the mail apps often triggered a guessing game. Having additional text labels as in the Sony calendar helps (see fig. 13).
Fig. 13: The mail app on the Sony tablet has controls with additional text labels
A related problem is the sole use of placeholder text to label text inputa as seen in the New Entry popup window on the iPad calendar (compare fig. 7). Such placeholder text disappears as soom as it is replaced by the first (even accidental) input, making the field often hard to indentify afterwards. The magnified view reduces the availability of contextual cues that might help users guess the meaning of controls with missing labels.
Some icon controls without label can appear cryptic to novice users. An example is the plus icon (+) used in all calendars to create a new entry. This icon was often not immediately interpreted correctly in our tests. On the other hand, it signifies the creation of new elements (entries, mails, etc.) on all tablets tested, i.e., it is used across operating system boundaries. Maybe some icons are on their way to become conventions as firmly established as the trash can icon for Delete and the (curiously obsolete) floppy disc icon for Save.
Some apps were not easily identified by low vision users when their name was unconventional (Samsung's calendar is called S-Planner) or missing (Windows 8 omits the label Calendar on the tile view of the Calendar app). This is mainly a general usability problem but it is exacerbated for low vision users who find it harder to identify iconic content.
- Use additional labels for icons or icon-based control elements (compare fig. 13)
- Provide proper labels for all text inputs - not just placeholder text
- Use conventional names: Call a calenar "calendar" (not S-Planner like Samsung)
- Support emerging conventions for icons and naming such as the plus icon for "New"
Some feedback messages displayed on tablets (for example, "New entry created") are shown for just 2-3 seconds and then disappear without a trace. Low vision users often did not manage to read these feedback messages in time, their meaning had to be inferred from the task context.
- Offer feedback in a form that remains visible at least until users' next input action
- Provide feedback via dialogs that ask users to confirm or dismiss an action (such as "Save calendar entry?" with the options Save and Dismiss, which used in the Windows 8 calendar)
Tablets have become an established form factor and are usable by low vision users. Compared to a desktop PC, they offer many advantages especially for users who need to bring up the device close to their eyes.
Some of the usability issues we have identified are related to the fact that the magnified view offers a lot less context than a full screen view. Problems like errors in the correct allocation of information elements may only become fully apparent under magnification. Other issues such as poor contrast, the lack of descriptive labels, or transient content can be framed as usability issues, but also fall under accessibility requirements as defined in the Web Content Accessibility Guidelines 2.0. The tests have demonstrated that there is no clear-cut line between accessibility and usability.
Improving the zoom function (see our article on tablets' zoom magnification) and offering better text scaling options in the system settings (see our article on the adjustability of text size) would make tablets a lot more usable for low vision users.
The "remedies" listed above suggest some design improvements which would tackle the usability problems identified. Some are obvious improvements, others would need to be validated in user testing. We think there is still plenty of room for making the use of tablets a better experience for low vision users.