Audio Access to Calendars
Andy Brown, Caroline Jay and Simon Harper
School of Computer Science
University of Manchester
Kilburn Building, Oxford Road
Manchester, UK
[andrew.brown-3 | caroline.jay | simon.harper]@manchester.ac.uk
ABSTRACT
Keywords
The rise of ‘Web 2.0’ has brought a much more interactive aspect to the Web: users are no longer just reading
pages, but creating them, modifying them, and interacting
with them. The Web is increasingly becoming the preferred
means of communication, and particularly booking events
and appointments; online personal and corporate diaries allow friends and colleagues to arrange meetings and coordinate activities. Many of these types of online activities
require users to perform the apparently simple task of entering a date. For sighted people who have access to pop-up
calendars, selecting a date is quick and easy. Unfortunately,
this facility is not currently available to people with visual
impairments, for whom entering a correctly formatted date
can be a difficult and time-consuming task, with mistakes
having potentially serious consequences. Here we describe
the process by which we designed and evaluated an audio
interface for entering dates. An eye-tracking study gave insight into how tabular calendars help sighted people enter
dates, This understanding was used to design an audio interface that used the cognitive advantages of the visual design,
rather than mimicking the visual representation. Iterative
testing was followed by an evaluation using participants with
visual impairments that highlighted the problems with manual date entry, and which showed the audio system to be
effective and popular.
Web 2.0, AJAX, Visual Disability, Eye-Tracking.
Categories and Subject Descriptors
H.1.2 [Models and Principles]: User/ Machine Systems—
human factors, human information processing; H.5.4 [
Information Interfaces and Presentation]: Hypertext/
Hypermedia—user issues, navigation; K.4.2 [Computers
and Society]: Social Issues—assistive technologies for persons with disabilities
General Terms
Human Factors, Experimentation
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
W4A2010 - Technical, April 26-27, 2010, Raleigh, USA. Co-Located with
the 19th International World Wide Web Conference.
Copyright 2010 ACM 978-1-4503-0045-2 ...$5.00.
1.
INTRODUCTION
The modern Web is more interactive than ever: users are
no longer passive consumers, reading pages as they would a
book, newspaper or encyclopedia. Instead, information now
flows in all directions, allowing it to be used in a much more
conversive way. Not only is it used to communicate with
friends, it is widely used for many more formal transactions
such as ordering and buying goods and services. Examples for individuals (as opposed to businesses) include buying the weekly shopping, paying taxes, arranging insurance,
and booking appointments. Many of these are important
and must be done correctly, with the consequences of error
ranging from minor to major inconvenience, and including
breaking the law; it is therefore vital that users are supported in giving information as accurately as possible, and
with the minimum room for error. This is particularly the
case for users with visual impairments, as it is more difficult
for them to review their input. Here we describe the design,
implementation, and evaluation of a non-visual interface for
entering dates on a Web form.
Pop-up calendars, or ‘date pickers’ are common on forms
where a date needs to be input. These typically display one
month in a tabular format; figure 1 gives some examples.
The month is given at the top, with controls on either side
to navigate to the next or previous month; the table below
has a header row giving the days of the week, followed by the
dates represented by numbers with one week per row. The
table cell representing the date currently in the input box is
often given visual highlighting. A typical mode of operation
(used by all the examples in figure 1) is to have a text input
box that, when focused, initiates the appearance of a calendar. The calendar usually appears immediately below the
text box, and over other content (hence ‘pop-up’). The user
then has the choice of typing the date manually, or selecting
the date using the calendar. The latter is usually done with
the mouse, although some are keyboard accessible. Once a
date has been selected, the calendar disappears.
Due to their dynamic nature (i.e., they appear on demand,
rather than being ever-present), these pop-up calendars are
not generally announced or accessible to users with visual
impairments. Supporting non-visual date entry does not
appear to have had much consideration, probably due to the
availability of an apparently simple alternative: typing the
date manually. However, as will be demonstrated in section
5.2, this is not as simple as it might seem. Furthermore,
2.
(a) Yahoo! User Interface Library
(b) Dojo Toolkit
(c) Meteora
(d) Uize
Figure 1: Examples of JavaScript pop-up Calendars
from online ‘widget’ libraries.
pop-up calendars are presumably of some benefit to sighted
users, so it is reasonable to offer those benefits to all users,
particularly considering the importance of inputting data
like this correctly.
Since the appearance of a calendar is effectively a change
to the page, an example of a pop-up calendar was included
in research looking at dynamic pages (pages that change
without requiring a reload). An eye-tracking study was undertaken that sought to understand how sighted users allocated attention when changes took place; in addition to
pop-up calendars, this study [5] also looked at tabs, slide
shows, auto-suggest lists [2], expansion buttons and tables.
The results with respect to calendars were particularly interesting, however, and prompted the work described below.
The initial eye-tracking study (§ 3.1) showed that sighted
users nearly always used the calendars, and that the way
they did so gave them some advantages over manually typing
the date (§ 3.2). In particular, users did not need to be aware
of the required format, the risk of typing errors was reduced,
and the relationships between dates became more explicit.
A direct translation of the calendar to audio, however,
would not offer all of those advantages to screen reader users.
Indeed, the difficulties of interacting with tables in audio are
well documented (see § 2). Instead, the understanding of
the cognitive benefits tables offer sighted users allowed an
interface to be designed that offers those same benefits to
users browsing non-visually (§ 4).
Iterative testing with screen reader users resulted in a
design that evaluation with users with visual impairments
showed to be effective and popular (§ 5).
BACKGROUND
The typical use of calendars to assist with date entry has
been described above, where it was noted that they may be
considered ‘dynamic’ content, as they appear (and disappear) without reloading the page. This type of behaviour
is one of the key characteristics of ‘Web 2.0’, where such
chunks of interactive content are known as ‘widgets’. Screen
reader users, however, are suffering from a disadvantage with
this type of content as their assistive technologies lag behind
these developments. A review of how users of different assistive technologies deal with dynamically updating pages [1]
showed that older browser / screen reader combinations apparently did not even respond to some updates, in particular
those which occurred automatically. Even newer technologies often did not notify the user that the page had changed
(it should be noted that technology is changing rapidly, even
if users don’t always have the most up-to-date version).
The situation is improving, however, notably through the
development and deployment of the Accessible Rich Internet
Applications Suite (ARIA) from the W3C’s Web Accessibility Initiative1 . The essence of WAI-ARIA [3] is that adding
semantic metadata will allow the user-agent/assistive technology partnership to render the rich information appropriately. Although there are situations where it is difficult to
find an appropriate solution through ARIA (see, for example, [15, 2]), there are also many situations where it can be
applied effectively. The difficulty, however, is designing an
interface that allows the ‘widget’ to be used effectively and
efficiently.
A common approach in the field of accessibility is to make
the information available through audio by direct translation. We contend that this is not always appropriate, indeed that it can often be a poor choice. The case of pop-up
calendars is a good example: direct translation would give
the updated content to the user to browse, and present this
as a table. The user could move between the cells of the
table until the desired date is found. Tables are, however,
difficult structures to navigate non-visually.
As Wright [17] has pointed out, tables have no aural equivalent and they can be considered as one of the natural
functions of written language. The fundamental problem
with presenting them in an audio interface is that tables are
multi-dimensional, whereas the audio information stream is
essentially one-dimensional [18]. A particular problem is
gaining an overview (see, for example, [8]), although this
should not apply to calendars as most people are aware of
the general layout. However, it is possible that presenting
a calendar as a table introduces as many difficulties to the
user as manual date entry.
If direct translation is not appropriate, what approach
should be taken? Clearly users with visual, or other, impairments must be able to access the same raw information
as sighted users, but the precise details about how that information is presented need not be maintained. Thus, in
the case of calendars, it is important to give users equivalent information — which dates fall on which days of the
week, how many days in each month, etc. — but this does
not necessarily mean giving them monthly tables of dates
organised by day and week. A better approach than direct
translation is to develop an understanding of how the information benefits the user (its cognitive benefits), then build
1
Introduced at http://www.w3.org/WAI/intro/aria.php
a mechanism for presenting it around that understanding,
i.e., attempt to replicate those benefits through the audio
interface.
As an aside, Wright also notes that tables are cleverly convoluted lists [17], and this is particularly clear in the case
of calendar tables. This suggests that, while a tabular arrangement might suit sighted users, something closer to the
list arrangement might suit users with visual impairments.
However, given that most information on the Web has been
designed for an audience of sighted users, a natural first
stage in developing an understanding of the cognitive benefits is to examine, in detail, how those users interact with
the information.
Eye tracking has been used to investigate cognitive processes for over 100 years [12], and is a powerful tool when
used in conjunction with Web pages, enabling us to determine those areas that are most salient (attract the most
fixations), and those that receive little attention. Eye tracking’s most obvious application is in improving the standard
design and layout of Web pages, and evaluating their usability [13]. Studies have also examined the saliency of items on
a page under varying conditions (e.g. [4, 10, 14]), how
eye movements vary according to information scent [11] and
how looking for a menu is influenced by page complexity and
prior expectations [9]. Eye-tracking is thus an excellent tool
to help develop an understanding of the benefits of certain
forms of presentation.
3.
EYE-TRACKING EXPERIMENTS
In order to gain insight into how sighted users deal with
various forms of dynamic information, an eye-tracking experiment was performed. The study investigated how people
allocate visual attention to dynamic content in two situations: completing short, directed tasks; and browsing.
Each of the directed tasks used in the experiment was
designed to prompt interaction with an element containing dynamic content, with the goal of gathering data about
how people perceive and use the content in that particular situation. To ensure the data have external validity, the
tasks were chosen to reflect what a person might reasonably
choose to do with such content.
The procedure and results for the complete experiment are
reported in full in a technical report [5]; this paper describes
only those sections that gave data on how participants interacted with calendars.
3.1
Method
17 male and 13 female volunteers, aged between 18 and
34, took part in the study, which took approximately 30
minutes, and for which they were paid £5. All participants
used the Internet on a daily basis. Participants sat in front
of a 17” monitor with a built in Tobii 1750 eye tracker, and
Tobii Studio Professional edition eye gaze analysis software
was used to record and analyse the data.
During the experiment participants were required to enter two dates on the Kayak site. Kayak is a travel site incorporating a flight search engine. In order to accurately
document user interaction with the site, each participant
completed three tasks in order, in a single visit. The first
was: ‘Search for a flight for one person from Manchester to
New York, leaving on <date> and returning a week later’.
Subsequent tasks were to find the cheapest flight and the
last flight of the day; these tasks involved interaction with
a variety of dynamic content, but not calendars. Departure
and return dates are set using text input fields; when these
receive focus, a calendar appears below the box (and obscuring other content) showing two months arranged in tables
(Figure 2).
Although only one example of a Calendar was used in
the experiments, the consistency of form (see Figure 1, or
wall calendars) is such that we believe that these results are
generalisable (the appearance of one month or two is not
significant — the results demonstrate that it is the basic
layout of a month that is important; see §3.2).
In all cases, interaction was documented with live Web
sites, as this was necessary for many of the dynamic features
to function, meaning that all participants viewed slightly
different information2 .
3.2
Results
When selecting dates for the flight, in four cases, the dates
were already correct, so participants simply checked them
visually and continued. Moving the cursor to the date field,
or clicking the symbol next to it, prompted a calendar to
appear (see Figure 2). One participant viewed the calendar when it appeared, but chose to edit the dates directly.
Only two participants seemed to ignore it completely. The
remaining 23 participants used the calendar. Of these, 14
requested it directly by clicking the symbol to the right of
the date field. 9 participants clicked in the date field initially
to edit the departure date, but used the calendar when it
appeared, and of these, 6 then went on to click the symbol,
to request the calendar, for selecting the return date.
The eye-tracking not only gave information about whether
participants looked at the calendar, but also about the way
in which they used it. When selecting the departure date,
they quickly scanned and located the required day. When
selecting the return date, specified to them as ‘a week later’,
people used the layout of the calendar to work it out. Participants treated the calendar as a table, running their mouse
and/or gaze along the row underneath the departure date
(which was highlighted in red), before selecting the date directly underneath, or focusing on the departure date, and
then moving down the same column by one row (see Figure 3).
3.3
Analysis
It can be seen that the tabular layout is organising the
dates in a way that makes relationships between dates more
explicit, and allows people to jump between them at different levels of granularity. The day is the smallest unit in the
calendar, and is represented by a simple number. Context
can be obtained by glancing at the top of the column, to
give the day of the week, or the top of the table, to give
the month and year. Days are grouped into rows, each representing a single week, and weeks are grouped into tables,
each representing a month. Thus, when viewing one date,
viewing a date one week earlier (or later) requires moving
up (or down) a cell in the column. Moving a month requires
shifting one’s gaze to the next table, and possibly activating
the control to display other months. Finally, and perhaps
most importantly, to select a date the user simply clicks it
— there is no need to consider the format in which it should
2
Note that this also means that the pages are no longer the
same structure, and that the nature of some of the dynamic
updates has changed or may change.
be entered.
We may summarise the main advantages as follows:
• Entering a date does not need the user to find, or guess,
the date formatting used by the designer.
• The possibility for typing errors is reduced. A typical
date requires 8 numerals and 2 separators; selecting a
date by mouse requires a single click. This could be
a particularly significant benefit for users with motorimpairments [16], as multiple actions with potential
for typing errors are replaced by a single action with
the potential for pointing or clicking errors [7].
• Relationships between dates become explicit: that the
13th day of the month is exactly one week after the
6th can be identified rapidly by their relative position
(one above the other) in the table. This reduces the
need for simple, but error-prone, mental arithmetic.
4.
Figure 2: A participant selecting the departure date
from the calendar. The calendar appears when the
participant edits the date field, or clicks the symbol
to the right of the date field.
PRESENTING CALENDARS IN AUDIO
The benefits that calendars offer sighted users could also
be expressed in terms of the problems caused by needing to
type a date in a box, namely: uncertainty about the format;
the possibility of typing errors going unnoticed; and the need
for mental calculations (or referral to another calendar) to
determine the day of the week, or relationships. These problems are as valid for users with visual impairments as they
are for those who are sighted; indeed, it could be argued
that they are more important. Glancing is more difficult
when interacting non-visually, so reading formatting cues
(e.g., dd/mm/yyyy under the input box) is more difficult,
particularly as the user may not be aware of the existence
of the cue. For the same reason, it can also take more effort
for users with visual impairments to examine another calendar for help. Finally, it should be noted that checking one’s
input can also be more difficult when interacting through
audio, again due to the difficulties of glancing.
Considering that we wish to replicate the benefits that a
calendar for selecting dates offers sighted users, it is possible
to enumerate the goals of any non-visual implementation:
1. Automate formatting.
2. Minimise potential for typing errors.
3. Make relationships more explicit.
Implementing an interface that fulfils these goals should
help screen reader users to enter dates more quickly and
with fewer errors than typing manually.
4.1
Figure 3: A participant selecting the return date
from the calendar. The participant locates the departure date (21, highlighted), and then moves down
one row to select the date a week later.
Implementation
In order to test a set of mappings for dealing with dynamic
content generally, a proof-of-concept system has been developed for evaluation. This is a self-voicing extension to the
Firefox Web browser based on the Fire Vox extension3 . This
system includes an interface for dealing with calendars.
4.1.1
Introduction
Since the date entry interface is designed as part of a
system, it is necessary to introduce this system as a whole
before describing the details of how users entered dates. The
3
http://www.firevox.clcworld.net/
extension was a prototype screen reader designed to test a
set of rules for presentation and interaction with dynamic
information in Web pages. This was achieved by a threestage process:
1. Detecting page changes then clustering them into meaningful updates.
2. Classification, according to the attributes of the update and the user’s activity.
3. Presentation, applying the rules appropriate for the
class.
One particular class was the pop-up calendar. These updates involve dynamic insertion of a calendar onto the page,
and occur when users move focus to a date field (i.e., the
update is initiated by the user) or when an icon is selected
(i.e., the update is requested by the user). Before describing the detection, classification, and presentation of pop-up
calendars, it is necessary to introduce the user interface. In
particular we describe the methods for navigating around a
page.
The user interface for the experimental prototype was
changed from that used in the standard Fire Vox, on the basis that this was not particularly intuitive, and might take
more learning time than would be appropriate in a short
(less than two hours) evaluation. The replacement interface
was loosely based on that used in the Orca screen reader
for the Gnome desktop on Linux. Navigating around a page
can be done in two ways: sequential navigation, or elementbased navigation.
Sequential navigation allows users to move from element
to element as they appear in the DOM (a depth-first traversal of the tree). This can be done at three levels: element,
sentence or word.Moving at these three levels of granularity
is achieved using the number pad keys found on a typical
desktop computer keyboard. Each row relates to a different level of granularity: the top row moves by element, the
middle by sentence, and the bottom by word. The columns
enable the user to move backwards (left column) or forwards
(right column), or to query their current location (middle
column).
Element-based (or structural) navigation is a method for
jumping between elements of a certain type. For example,
jumping between, and reading, the headings on a page can
be used to give an overview of its content. This type of navigation is achieved by using character keys (e.g., ‘H’ moves
between heading elements) when in structural navigation
mode. This mode may be toggled between on, off, and automatic. In automatic mode, structural navigation is enabled
unless the focus is in a form element requiring typing, such
as an input box.
4.1.2
Calendar Initiation
The non-visual implementation for pop-up calendars uses
some simple heuristics to detect the update type, then employs the grid layout of the navigation keys to recreate some
of the benefits of the table layout typical in these updates.
An update is assumed to be a pop-up calendar if it appears
when entering a text field that has some characteristic of
a date. Characteristics include containing text formatted
as a date, or having a label, name, or id containing ‘date’.
Presentation involves a change of mode, and starts with the
announcement ‘Date Entry’ followed by the date in the field
(if no date is present, today’s date is spoken). There is also
a command to allow this mode to be entered manually.
Having identified that the user has entered a field requiring date input, the next stage of the process is to determine
the format required. This is done using a set of heuristics.
The first stage is to identify the separator, if there is one.
Once this has been done it is necessary to determine which
segments represent the day, month and year. The date is
compared with two patterns, representing the ‘British’ format (day, month, year) or ‘American’ format (month, day,
year) using the following regular expressions (assuming the
delimiter has been identified as a colon):
UK: ^(0?[1-9]|[12][0-9]|3[01]):
(0?[1-9]|1[012]):
(19|20)?[0-9][0-9]
US: ^(0?[1-9]|1[012]):
(0?[1-9]|[12][0-9]|3[01]):
(19|20)?[0-9][0-9]
If only one of these matches, that format is assumed, otherwise an additional test is performed, based on the possibility that the date is today. The segments of the day and
month in the field are compared to those of the current date;
if both are identical, no conclusions can be drawn; similarly
if only one matches. If both match, however, the assumption
is that the date is today, and whichever format matches is
used. Finally, if none of these are conclusive, the format last
used is assumed; if none exists, a default can be used based
on user preferences. These rules undoubtedly have scope for
further generalisation and refinement.
4.1.3
User Interaction
Once the calendar has been initiated, and announced, the
user may then change the date a day, week, or month at a
time, either forwards or backwards; this is done using the
number pad keys, with the top row moving months, middle
row moving weeks, and bottom moving days. The current
day, date, or month is spoken using the middle column, while
the left and right columns move backwards and forwards in
time respectively. The ‘enter’ button puts the selected date
into the input field and the ‘escape’ button exits the calendar
mode without modifying the input field. Similarly, typing
the date manually (using the numbers above the character
keys on the keyboard) exits this mode and allows ‘normal’
operation using text input.
Speech feedback is kept relatively terse. On entering the
mode the date is spoken in full, e.g., ‘Friday 21 June 2009’ ;
after this the default when navigating is to speak only the
day of the month. If, however, a month boundary is passed,
the new month will be spoken, e.g., moving a day at a time
‘30’, ‘31’, ‘1 February’, ‘2’. The same applies when passing
year boundaries. When the user queries the current date,
key 2 gives the day of week and day of month (‘Friday 21’ ),
key 5 gives the full date (‘Friday 21 June 2009’ ), and key
8 gives the month and year (‘June 2009’ ). Figure 4 shows
these commands, as mapped in the evaluation, with examples of the output. Finally, setting the date is done with
the ‘Enter’ button, with confirmation including the full date
(‘Date input set to Friday 21 June 2009’ ); at this point, date
mode is left and the user can continue normal navigation.
The ‘Escape’ button exits date entry mode with no change
to the field (even if the user has changed the date).
focus on the tasks relevant to date entry. Only the results
of the date entry task are discussed.
Previous
Month
28 January
Current
Month
March 2010
Next
Month
28 March
Previous
Week
21
Current Date
Wednesday 28
February 2010
Next Week
7 March
Previous Day
27
Current Day
Wednesday 28
Next Day
1 March
Figure 4: The user interface. A 3 × 3 grid of keys
maps to 9 commands. Italicised text gives the output for each command if the date is currently set at
February 28 2010.
Referring back to the requirements (section 4), it can be
seen that they have been fulfilled in the following ways:
1. Formatting is automatically detected and applied to
the selected date.
2. Navigation keys are used to move between dates, with
a brief confirmation of the new date for each change.
This feedback minimises the consequences of any typing error, demanding only another key press to correct.
3. Navigation by week and month preserves some of the
relationships that the visual tabular presentation makes
explicit. For example, moving one week at a time allows the user to browse all dates that lie on the same
day of the week.
Furthermore, it is possible to identify some other aspects
of this interface that potentially improve upon the visual
form. For example, moving by larger units, such as a month,
preserves the values of the day, so moving from the fifteenth of May to the fifteenth of September requires four
key presses. Performing this visually requires attention to
move away from the date (15) to the next month button,
pressing this until September appears, then locating the fifteenth of this month. This is arguably a slower and more
complex operation.
5.
EVALUATION
In the same way that the implementation was integrated
with a more general system for Web browsing and interaction, evaluation of this interface for date entry was performed as part of an evaluation of the system as a whole [6].
The procedure for the whole experiment is described, with
5.1
Method
The aim of the evaluation was to test whether the interaction metaphors developed in the SASWAT project provided
better access to dynamic micro-content than screen readers
do at present. The study used a within-subjects design, in
which all participants completed a series of tasks as part of a
holiday booking process on the HCW Travel Company Website (specially designed for the evaluation), once using the
Firefox browser with the Fire Vox screen reading extension4
(the base case browser) and once using the Firefox browser
with the SASWAT screen reading extension (the SASWAT
browser). The Fire Vox browser was chosen as a baseline because it provides access to dynamic micro-content at a level
similar to many proprietary screen readers, including JAWS.
In brief, most screen readers currently allow access to new
content if the user is able to navigate to it, but do not inform
the user that the content has changed. The navigation commands (see Section 4.1.1) were identical in both browsers.
The differences between the behaviour of the two browsers
with respect to date entry are detailed in Section 5.1.3.
The goal of the evaluation was to give participants an opportunity to compare the behaviour of both browsers whilst
interacting with a variety of dynamic micro-content, so they
could later specify which they preferred in a structured interview. As such, they completed the same tasks, on the
same website, twice. To control for practice effects, half the
participants completed the holiday booking tasks using the
base case browser first, the other half using the SASWAT
browser first.
Two participants (p1m and p2m — details of participants are given in section 5.1.1) completed the tasks on the
‘full’ version of the HCW Travel Website5 that had been
used during the iterative evaluation. It was noted that this
obliged the participants to spend some time navigating between different elements on the page, so the remaining participants completed the tasks on a reduced version6 , which
contained identical dynamic micro-content, but fewer (superfluous) links and images, and a reduction in the amount
of text.
The evaluation was run on a MacBook Pro running OS
X 10.5.8 Leopard. The evaluation was conducted with the
Mac system voice ‘Alex’ at the speaking rate ‘normal’. Audio output was provided by the on-board speakers. Participants used a USB Dell keyboard to navigate and provide
typed input. The session was recorded with a digital voice
recorder.
The evaluation sessions were run in meeting rooms at
four locations: the Human-Centred Web Lab at the University of Manchester; Macclesfield Eye Society, Macclesfield;
Walthew House, Stockport; the Disability Information Bureau, Macclesfield.
5.1.1
Participants
Participants were recruited in a variety of ways. P1m
was a member of staff and p2m and p3m were students
4
http://firevox.clcworld.net/
http://hcw.cs.manchester.ac.uk/research/saswat/
experiments/hotels/book.php
6
http://hcw.cs.manchester.ac.uk/research/saswat/
experiments/hotels/simple/intro.php
5
Participant
P1m
P2m
P3f
P4f
P5f
P6m
P7m
P8f
P9m
P10f
P11m
P12f
Impairment
profoundly blind
profoundly blind
partially sighted
registered blind
profoundly blind
registered blind
profoundly blind
registered blind
profoundly blind
registered blind
partially sighted
registered blind
Onset
adulthood
birth
birth
childhood
adulthood
birth
adulthood
adulthood
birth
adulthood
adulthood
childhood
Table 1: Nature and onset of visual impairments of
participants in the final evaluation of the SASWAT
Web browser. Note that all participants who are
marked as registered blind had some residual sight.
Participant
P1m
P2m
P3f
P4f
P5f
P6m
P7m
P8f
P9m
P10f
P11m
P12f
Assistive technology
JAWS
JAWS
ZoomText
JAWS
JAWS
JAWS
JAWS
ZoomText (no audio)
JAWS
ZoomText (no audio)
Enlarged fonts
JAWS
Browser
IE
IE
IE
IE
IE
IE
IE
IE
IE
IE
IE
Firefox
Table 2: The assistive technology and Web browser
normally used by the participants in the final evaluation of the SASWAT Web browser.
browsed the Web using the screen reader JAWS (v. 10 or below). One participant used the screen magnifier ZoomText
with audio and two used ZoomText without audio. P11m
used a standard desktop computer set-up with a large font
size, but had had experience of using JAWS at college. Table 2 describes the computer set-up used by the participants.
Most participants browsed the Web every day. P4f browsed
the Web weekly and p10f monthly. P7m had only browsed
the Web twice before, for a short period in college. Common
reasons for Web browsing included work, study, shopping
and email (see Table 3).
5.1.2
Procedure
The investigator read out the Information Sheet and Consent Form, and when participants had indicated that they
were happy with the information they had received, they
signed the Consent Form. All participants signed the form
themselves, with the exception of p2m, for whom a second
investigator signed on his behalf.
Participants were shown how to use the browser and given
the chance to practice using the navigation commands on a
shortened version of the Fire Vox User Manual home page.
They then completed the tasks with each browser, and answered questions about their experience in the structured
interview. Each session was audio recorded. The information sheet and script used for the experiment (including the
interview questions) and transcripts of all the session recordings are available to download with the evaluation Technical
Report [6].
5.1.3
Task
The task involving date entry was found on the booking
page of the Web site. This page allowed participants to enter their destination and departure and return dates. A link
was also present that, when selected, expanded a section
of the page to display instructions. After viewing these instructions, and entering their destination, participants were
given the following task:
Set the departure date to the 1st January 2010,
and the return date to the 2nd February 2010.
at the University of Manchester who were contacted via
word of mouth (they had taken part in previous studies
and expressed an interest in participating in future ones).
These participants had provided feedback in informal iterative evaluation sessions during development, so had thus
had experience of using an earlier version of the SASWAT
Web browser.
The remaining participants were recruited through advertisements placed in Macclesfield and Stockport talking newspapers, and circulated by staff at Macclesfield Eye Society
and Walthew House Deaf Blind Services in Stockport. P4f,
p5f, p6m, p7m and p11m were service users and p8f, p9m
and p10f were volunteers/staff at either Macclesfield Eye Society or Walthew House. P12f was an IT teacher who worked
with blind students. P1m, p2m, p3f, p6m and p12f were in
the 20-45 age group; the remaining participants were over
45. Participants received an honorarium of £20 for taking
part.
Three of the participants were partially sighted, four were
registered blind with some residual vision and five were profoundly blind. Table 1 summarises the nature and onset of
the visual impairments of participants.
All participants normally used Windows, and the majority
The ways in which the site appeared to the user when
performing this task are described below. The visual presentation describes what a sighted user would see; the base
case presentation describes what occurred when the simple
version of the system was used, and represents a typical
method for entering a date; the SASWAT presentation describes again how the interface being tested works.
Visual presentation: When the focus entered one of the
date fields a pop-up calendar appeared. This was from
the Dojo toolkit, styled in the form shown in Figure
1(b). Initially the current date was displayed in the
date field (in the format dd/mm/yyyy), and this was
highlighted in the calendar by a box. Two controls
displaying arrow icons could be used to move to the
preceding or next month. Clicking on one of the days
entered it into the date field. When a departure date
had been entered, the return date was automatically
set to this too, providing it had been correctly formatted, otherwise it was set to the current date.
Base case presentation: When the focus entered the date
field, the browser read out the date it contained (the
Participant
P1m
P2m
P3f
P4f
P5f
P6m
P7m
P8f
P9m
P10f
P11m
P12f
Browsing Frequency
daily
daily
daily
weekly
daily
daily
only twice in college
daily
daily
monthly
daily
daily
Browsing Nature
work
study, email, Facebook
shopping, study, email
finding things out
study, shopping, ‘everything really’
looking up historical information
N/A
family tree, shopping (with help)
work, study, email, occasional shopping
family tree (with help)
shopping, price comparison, looking things up
work, email, looking things up
Table 3: The frequency and nature of Web browsing of the participants in the final evaluation of the SASWAT
Web browser.
text sent to the speech synthesiser was in the form
‘departure date 26/01/2010’, which was spoken as ‘departure date twenty six, one, two thousand and ten’).
The calendar appeared, but the user was not notified
of this, and it was not possible to access it in audio.
To set the date, the user typed it in manually, using
the numbers along the top of the keyboard.
SASWAT presentation: When the focus entered the date
field, the browser read out the date it contained (as
above). It then said, ‘date entry’, followed by the date
again (in full, e.g, ‘Tuesday January twenty-six two
thousand and ten’) to indicate that it was in a mode
that allowed users to access the calendar. The user
could move to a different date using the commands described in section 4.1.3. Pressing the enter key placed
the current date in the date field and the browser said,
‘date input set to <date>’.
5.1.4
Interview
After they had completed the tasks with each browser,
participants answered a series of questions about their experience browsing the Web, and their opinions of how the two
different browsers dealt with the various types of dynamic
micro-content. They were asked for details of the nature and
length of their visual impairment, the assistive technology
they usually used, the frequency with which they browsed
the Web and the kind of things they used the Web for. For
each item of dynamic micro-content, participants were asked
whether they had encountered it before on the Web, to give
their opinion on how easy it was to use, whether they would
like to be able to access it, and whether they could think of
any ways of improving access to it in audio. Finally, participants were asked which browser they preferred overall
and why, whether it was useful to be notified when information on a Web page changed, and whether they agreed with
the statement, ‘if information on a Web page is available
to someone sighted, it should also be available to someone
who is visually impaired’. Throughout the interview, participants were encouraged to expand on an answer if they
wished to.
5.2
Results
P1m, p3f, p4f, p9m, p11m and p12f said they had come
across calendars before on the Web, whilst the remaining
participants had not. P5f said she had heard of them, but
not accessed them.
On the whole, participants found the calendar date entry
easier to use than typing the date manually. When typing
manually, all participants made either formatting or typing
errors, or both, or asked the experimenter what format was
needed. Only one third of participants (p1m, p2m, p4f and
p11m) did not make any typing errors. It should be noted
that all participants were using an unfamiliar keyboard, and
that errors were often related to the special character separating the days, months and years.
No participants conclusively determined the format to use:
4 of the 12 immediately asked the experimenter what the
format should be:
p1m: ‘So, format?’
p8f: ‘Do you have slashes in between? Dots?’
p9m: ‘And what punctuation after each?’
p11m: ‘What do you put between them? Anything?’
Another three asked indirectly:
p2m: ‘Ah right. It’s. . . it must be 01 and then another 01
and then 10, isn’t it?’
p3f: ‘Do you want me to put like a 01?’
p10f: ‘Shall I just do 1 1 then?’
Three further participants (p5f, p6m, p7m) asked or were
told after having difficulties or making errors. Even with
such help from the experimenter, some participants submitted the form without the correct date in the correct format.
When using the audio date selection tool, all participants
correctly entered both dates, without error. Positive comments about the calendar ranged from ‘alright, yeah’ (p4f)
and ‘ace’ (p1m) to ‘great, that is brilliant, that is really,
really good’ (p7m). P10f thought the audio presentation
of the calendar was very good, and would like to have access to it, but thought she would be more likely to type
the date in. P2m was also keen to access the calendar, but
non-committal about whether he would use this or type the
date. P1m thought he would probably use the calendar, but
would like the option of entering the date manually. The
interface already provides this flexibility, by allowing people
to select a date using the number pad, or type it in directly
using the numbers along the top of the keyboard.
P3f, p5f, p6m, p7m, p8f and p12f all said that using the
calendar was much easier than entering the date manually.
Part of the reason for this may have been because using the
keyboard to type the date was difficult. P6m said, ‘going
down the keypad to put in the dates and the week that
you wanted to go away I found very useful, whereas if I’m
using the numbers along the top of the keyboard, I always
get dead confused for some reason. I find out where the
numbers are, and then having to find the slash... ’Cause
you’re moving from one side of the keyboard to the other
side and then moving back again.’ It was not only novice
users who had trouble entering the date: p3f, p1m and p12f
who use computers at work on a daily basis all found typing
the date difficult and time-consuming.
Most of the participants wanted to have access to the
calendar, but p9m felt it was ‘very fiddly... I wouldn’t like
to have to mess around for its own sake’. When asked if he
would like the option of either using the calendar or typing
in the date, he remained negative about the calendar: ‘I
think I’d prefer to type it in, ’cause that’s quicker.’ P11m
really liked using calendars when looking at the screen (he
has partial sight), but thought he would prefer to type the
date when using a screen reader, and was not convinced
of the benefit of providing calendars in audio. It is worth
noting, however, that all of the participants, including those
who were sceptical about the need to use the calendar, either
asked for help with formatting the date, or entered the date
incorrectly (p9m, in fact, did both of these things).
P1m and p9m both thought they would prefer to use
the cursor keys for accessing the calendar, although p1m
could see the advantage of consistently using the number
pad for interaction. P5f also mentioned ‘making it easier
with the keystrokes’, although she did not specify any particular changes.
6.
DISCUSSION
Before discussing these results, and their implications, in
more detail, it is worth summarising what the tool offered
the user:
those who declared a preference for manual input, demonstrate that the task of entering a date in a Web form is far
from simple. When this tool was provided, although some
participants took a little time to become familiar with the
commands for changing the date, all completed the departure and return fields successfully.
While it could be argued that the problems addressed by
this tool could be determined by a detailed analysis of the
process, or by performing studies with users who have visual
impairments, we believe the process that led us to design
such a tool is of particular interest to the assistive technology research community. Our process started by developing
an understanding of how sighted users, i.e., those users for
whom the original interface was specifically designed, interacted with information, in this case dynamic Web content.
This understanding was then used to map the visual interface of the facility to an audio one. Importantly, however,
this mapping is not a direct, or naı̈ve, translation but is
based on determining how the user is helped by the information. In this case a direct translation would be a table,
but while this would help deal with formatting, it misses the
other main point, which is that the user really needs to be
able to find the required date efficiently, ideally with a quick
way of determining its relationship with another date. This
approach can be applied to different types of information,
and differences between users with congenital or late-onset
blindness, or with less severe impairments do not appear
to matter, and it can (and should) be combined with other
design approaches to provide optimum accessibility. If interpreted correctly, techniques such as eye-tracking can give
real insight into how people use information and how to
present it non-visually.
7.
Technical reports describe the eye-tracking study [5] and
final evaluation [6] in more detail. Available with these reports in the Human Centred Web Lab repository are associated files containing the eye tracking data, participant
information sheets, consent forms, questionnaires, and transcriptions.
8.
• Automatic identification of date input fields.
• Automatic date formatting.
• Notification of the date currently set in the box.
• Keyboard commands to change the date by day, week
and month (the precise keys chosen are not that important, although the 3 × 3 arrangement matches the
command requirements well).
• Terse speech output.
• Confirmation of the date set.
• The option to type the date in manually.
The evaluation gave clear evidence that providing these
features to the user is beneficial. The users liked the tool,
and most would choose to use it, while those who prefer manual date entry have that option at no extra cost. Furthermore, the problems encountered by most users, including
EXPERIMENTAL RESOURCES
ACKNOWLEDGEMENTS
This work is part of the Single Structured Accessibility
Stream for Web 2.0 Access Technologies (SASWAT) project
and is funded by the UK EPSRC (EP/E062954/1). As such
the authors would like to thank them for their continued
support.
9.
REFERENCES
[1] A. Brown and C. Jay. A review of assistive
technologies: Can users access dynamically updating
information? Technical Report, University of
Mancester, http://hcw-eprints.cs.man.ac.uk/70/,
2008.
[2] A. Brown, C. Jay, and S. Harper. Audio
representation of auto suggest lists. In W4A’09:
Proceedings of the 2009 Cross-Disciplinary Conference
on Web Accessibility (W4A), pages 58–61, 2009.
[3] B. Gibson. Enabling an accessible web 2.0. In W4A
’07: Proceedings of the 2007 international
cross-disciplinary conference on Web accessibility
(W4A), pages 1–6, New York, NY, USA, 2007. ACM.
[4] L. A. Granka, T. Joachims, and G. Gay. Eye-tracking
analysis of user behavior in www search. In SIGIR
’04: Proceedings of the 27th annual international
ACM SIGIR conference on Research and development
in information retrieval, pages 478–479, New York,
NY, USA, 2004. ACM.
[5] C. Jay and A. Brown. User review document: Results
of initial sighted and visually disabled user
investigations. Technical Report, University of
Mancester, http://hcw-eprints.cs.man.ac.uk/49/,
2008.
[6] C. Jay, A. J. Brown, and S. Harper. Internal
evaluation of the saswat audio browser: method,
results and experimental materials., January 2010.
[7] S. Keates and S. Trewin. Effect of age and parkinson’s
disease on cursor positioning using a mouse. In Assets
’05: Proceedings of the 7th international ACM
SIGACCESS conference on Computers and
accessibility, pages 68–75, New York, NY, USA, 2005.
ACM.
[8] J. Kildal and S. Brewster. Non-visual overviews of
complex data sets. In CHI 2006, Montreal, Quebec,
Canada, 2006.
[9] J. McCarthy, A. Sasse, and J. Riegelsberger. Could i
have a menu please? an eye tracking study of design
conventions. In Proceedings of HCI2003, pages
401–414, 2003.
[10] B. Pan, H. A. Hembrooke, G. K. Gay, L. A. Granka,
M. K. Feusner, and J. K. Newman. The determinants
of web page viewing behavior: an eye-tracking study.
In ETRA ’04: Proceedings of the 2004 symposium on
Eye tracking research & applications, pages 147–154,
New York, NY, USA, 2004. ACM.
[11] P. Pirolli, S. K. Card, and M. M. V. D. Wege. Visual
information foraging in a focus + context
visualization. In CHI ’01: Proceedings of the SIGCHI
conference on Human factors in computing systems,
pages 506–513, New York, NY, USA, 2001. ACM.
[12] K. Rayner. Eye movements in reading and information
processing: 20 years of research. Psychological
Bulletin, 124(3):372–422, 1998.
[13] M. Russell. Using eye-tracking data to understand first
impressions of a website. Usability News, 7.2, 2005.
[14] A. Schiessl, S. Duda, and R. Fischer. Eye tracking and
its application in usability and media research. In
MMi-Interativ ’03, pages 41–50, 2003.
[15] P. Thiessen and C. Chen. Ajax live regions: chat as a
case example. In W4A ’07: Proceedings of the 2007
international cross-disciplinary conference on Web
accessibility (W4A), pages 7–14, New York, NY, USA,
2007. ACM.
[16] S. Trewin and H. Pain. Keyboard and mouse errors
due to motor disabilities. International Journal of
Human Computer Studies, Volume 50:109–144, 1999.
[17] P. Wright. Tables in text: the subskills needed for
reading formatted information. In L. J. Chapman,
editor, The Reader and The Text, pages 60–69.
Heineman, London, 1981.
[18] Y. Yesilada, R. Stevens, C. Goble, and S. Hussein.
Rendering tables in audio: the interaction of structure
and reading styles. SIGACCESS Access. Comput.,
(77-78):16–23, 2004.