This document describes a pilot project to create an accessible talking comment form for children using Adobe Flash. The form was tested with various accessibility tools and users. It was found to be generally accessible and received positive feedback, though some limitations of interoperability between Flash and screen readers remained. The pilot demonstrated that Flash can be used to create an engaging and accessible service when designed with user needs in mind.

1. Multi-Lib Phase 2
Report 4:
Pilot 2
An accessible talking customer comment form for children:
A specimen accessible Flash application
providing a practical customer service
in public libraries
Andrew Lewis
January 2007
Library and Information Services
The Royal Borough of Windsor and Maidenhead
Supported by a Research and Development grant
from MLA South East.

2. An accessible talking comment form:
Executive Summary
Flash is the most widely available platform for delivering interactive multimedia content on
the web, and as such has huge potential for creating engaging library services that can
reach children. Whilst it cannot be ignored as a powerful tool for reaching target
audiences, it has attracted some criticism for not being an accessible format for disabled
people.
This pilot aimed to put these criticisms and Flash's accessibility features to the test, by
creating a new children's web service. The aim was to demonstrate a service that would
be enhanced specifically by using interactive multimedia and have a real purpose, yet that
would also be accessible to disabled people using their preferred access technologies.
An animated, talking customer comment form for young children was chosen. This was
created and initially tested by library development staff. This was then further assessed
independently with user testing by the Shaw Trust (Kennedy & Broome, 2006).
Professional testers with a range of different disabilities used the form with their own
access technologies set up with their usual personal preferences.
The form received a positive review in these tests, both for its appeal and accessibility.
Final refinements were made, based upon the comments received from these tests, and
the form was introduced as a live service in June 2006. Flash's accessibility tools were
demonstrated successfully, although the pilot highlighted the limits of these with certain
access software. These are detailed in the report.
The pilot was successful in its aims. It created a Flash application that provided a new
feedback service for children. By using bold and appealing audiovisual multimedia the
service was made more accessible in a non-technological sense than it could be by other
means, and also remained accessible to the disabled people who tested it when using
their favoured technologies set up to their normal preferences.

3. Contents
Executive Summary............................................................................................................ 2
Scope ................................................................................................................................. 4
Flash and web accessibility............................................................................................. 4
Accessibility and user needs........................................................................................... 5
Objectives........................................................................................................................... 5
Method ............................................................................................................................... 6
Choosing a service to pilot .............................................................................................. 6
Concept development ..................................................................................................... 6
Specific accessibility issues ............................................................................................ 8
Enabling the form's "send" function............................................................................... 10
Developer testing .......................................................................................................... 10
Equipment and software used....................................................................................... 10
Results ............................................................................................................................. 12
Results from development testing ................................................................................. 12
Results from user testing .............................................................................................. 12
Analysis of results............................................................................................................. 16
Flash-enabled accessibility ........................................................................................... 16
Limits of interoperability ................................................................................................ 16
Conflicting user requirements ....................................................................................... 16
Conclusions ...................................................................................................................... 17
Success against objectives ........................................................................................... 17
Overall conclusions ....................................................................................................... 17
References ....................................................................................................................... 18

4. Scope
This report is practitioner research offered to the professional library community, for use
when considering accessibility within the specific context of multimedia development. It is
a case study of implementing the accessibility features in Flash Mx 2004.
While it is hoped that this experience may be helpful and encouraging to others, it should
be noted that accessibility is a complex and user-specific subject, and the accessibility of
other authoring software will be different. It should be assessed on an individual basis,
with regard to the specific users needs of target audiences, the systems these audiences
use, and the specific versions of software employed.
Background
Flash and web accessibility
Flash is the most widely available platform for delivering multimedia content available over
the web. It is relatively inexpensive to buy, and can be used to create fully interactive
games, interfaces, cartoons and can control other media such as videos. This content is
also readily deliverable because the Flash Player is almost universally available as a plug-
in for popular web browsers, with a claimed 96% penetration (Adobe, 2006). It can readily
interoperate with other web technologies, and there is a large development community to
seek help from. All these factors give it a compelling appeal for developing multimedia
content for use in delivering library services.
Flash has however attracted some criticism for not being an accessible format for disabled
people. Discussion of this issue has centred around how far it is possible to access web
content delivered in Flash via commonly used access software. Flash movies are a
proprietary format, which are not based upon html web standards, but rather use a
dedicated player to interpret them. Flash can communicate with html, and the Flash
player plug-in is freely available for web browsers.
Popular access technologies are also in a sense proprietary software, and have features
that are designed to interpret web standards and re-present web features in an accessible
way.
Discussions of Flash and web accessibility often centre around technologies like screen
readers which translate visual layouts to an audio equivalent. Earlier versions of Flash
could not be interpreted by screen readers. Macromedia reacted to this by introducing
accessibility features in version 6 (Flash MX) and above, that were intended to allow these
access technologies to interpret text and controls in a Flash movie.

5. Macromedia (now Adobe) have published a discussion paper on how to use Flash'
accessibility features, see Regan (2005)
Accessibility and user needs
Any discussion of accessibility can only be understood in terms of meeting the needs of
specific users. Flash accessibility is almost always discussed in terms of the requirements
of blind users using the web. However, whilst this is an important aspect, people with
other disabilities may have considerably differing and even conflicting user needs.
For example, it is not always realised that people who have visual impairment have user
requirements that are different from truly blind people, and can range across issues like
screen contrast or just the simple ability to magnify the size of web screens. People with
learning difficulties may find the use of pictograms and symbols more useful than text.
Design factors to be considered
The judge of a good application providing a service can be viewed as whether it can be
readily used by its intended customer audience or audiences. In other words, usability is
the driver of good accessibility design. The following are issues that need to be
considered:
• What is the intended audience
• What are their needs as users
• Has the designer made any attempt to serve their needs
• Have these users been involved in testing prototypes
• In addition to issues arising from disability, other factors affect users needs, such as
age, ability to read, level of information literacy, urgency, recreation, and so on. These
diverse design factors are complex and need to be considered together.
Objectives
The aims of this pilot were simple:
• To test Flash's accessibility features by creating an application that used them, that
would be implemented as a new library service.
• To provide a case study that might inform others working with multimedia.

6. Method
Choosing a service to pilot
The first step was to consider services that might benefit from the possibilities that Flash
could offer. Due to Flash's cartoon-like qualities, the most obvious area to look at was
children's services. After considering various services for children, it was felt that
obtaining user feedback from children can be difficult, and this eventually led to the idea of
creating a more appealing alternative to traditional customer comment forms.
There was a feeling that paper feedback forms were not especially appealing to children.
For younger children, who are still developing their reading skills, using forms that rely on
written instructions can be difficult and daunting without some help, because of a possible
lack of experience or confidence in understanding them.
It was therefore decided to create an animated talking customer comment form for
younger children. The form had the following design criteria:
• It needed to have very bold striking visual design
• It needed to send out a friendly message
• It would offer some help in filling out the form
• It would work with common access technologies
Concept development
Once a service had been chosen, the concept was further developed.
Because it was aimed at younger children, it was felt that it should offer encouragement in
ways that they are comfortable with. Learning is a social activity, and for younger children
learning how to do new things often occurs with help from others, such as friends, parents
and teachers. It was therefore decided to recreate this familiar learning situation by
creating a help character to guide children through the process.
To appeal to as many audiences as possible, it was important not to make this too readily
associated with any specific social groups. A smiley ball-like character was created,
similar to the emoticons commonly found in instant messaging, texting and on websites.
The voice was created by making vocal recordings, and these were altered using sound
manipulation software.

7. As well as being friendly, and bold, the design also had the advantage or being very
simple to animate. See Fig. 1 below
Fig. 1 Visual design of the help character
To allow for the needs of deaf people, the use of subtitle text was required, and these
were provided using cartoon-like speech bubbles, in keeping with the design style.
The character's purpose was to talk the child through the process of sending a comment
to the library, and the application was developed as a very simple three-stage animation.
Step 1 - Welcome the child in a friendly way and invite them to contribute
Step 2 - Present the child with the form, and explain how to use it
Step 3 - Give them the option to review their comment, and either amend it or send it
Step 4 - Thank then for sending the comment
See Fig. 2

8. Specific accessibility issues
It is important to note that although this pilot was looking at technical accessibility of Flash,
content itself will also determine whether a service can be accessed by its audience. In
this sense, the form was addressing accessibility of its audience of younger children by
being suited to their intellectual level. For example, the main help character is friendly and
tells children what to do in simple language.
All vocal recordings had a corresponding visual version of the message using the speech
bubbles, which functioned to reinforce the spoken help and to provide an alternative
means of using the form if sound was not being used. This was partly to allow children
who might be deaf to use it, but also because it could not be assumed that computer a
child had access to had sound capability.
As well as having the help character explain what to do, the controls on the form also had
spoken audio help, so that if you tabbed to a control, it would speak out its function. For

9. example, the button marked "next" in Fig. 1 will read out the message: "This button takes
you to the next stage - filling out the form"
Similarly, the text boxes in the form were made to speak the letters as the child typed, so
that could hear what they were doing as well as see it on screen. These were spoken in a
distinct vocal style than the main character, to distinguish that this voice was representing
content entered by the child.
This was done by making vocal recordings of the name of each letter on the keyboard,
and creating a simple mapping engine in Flash that would play the sound of each letter if
the corresponding key for that letter was pressed.
All the built-in sounds combined meant that the form was accessible as a standalone
application for most users, including people with visual impairments. However, for people
who are blind and using screen readers, this could have been a significant problem. Any
sound from the form playing on top of sound from the screen reader would make it very
confusing and difficult to use.
To address these users, a special detection process was incorporated into the form. This
checked for speech readers before loading the main content. If a reader was present, all
sound within the form was turned off. If a reader was not detected, the sound was made
active. The script for this was amended from a specimen movie one made available by
Macromedia's Accessibility web pages (Regan, 2003)
All controls on the form were identified as accessible objects and given meaningful names
within Flash's accessibility panel, following the recommended procedure.
Fig. 3 Flash MX 2004 authoring environment showing accessibility panel

10. Enabling the form's "send" function
Once the form was created, it was made active by making use of an existing mail script,
already in use to drive forms on the Borough's web pages. This was a version of the
freely available generic form processing script FormMail (Wright, 2005).
The script itself is readily configurable and easy to install, although to use it requires it to
be loaded to the script bin of the web server used. In this pilot, this was not required as
the script installed by the corporate web team worked with the Flash application with no
alteration.
Reusing an existing web resource in this way provided a quick and easy means of
sending the comments. The FormMail is called using the getURL function within Flash.
The variables sent are a combination of defined fields such as where to send the
response, and the customer's input from the form's field variables.
Developer testing
First generic testing common to all development projects was conducted. This included
general usability, logic of wording, consistency, style and so on. However specific
accessibility testing was also required.
This included checking the accessibility tagging in Flash control by control to see if worked
with two commonly available domestic screen readers: Jaws and Windows Eyes. These
were chosen as they were the two readers most often cited by individuals in a previous
research project (LEWIS, 2004).
User testing
Once the form was completed, It was then made available for commercial independent
accessibility assessment by the Shaw Trust (no date), who employ people with several
different disabilities to undertake user testing, using access technologies suited to, and set
up for, their specific needs.
Equipment and software used
The main authoring tool used in this pilot was Flash MX 2004. The form was built as an
application, using Flash's ActionScript to provide user-controls for interactivity, to create
the visual content, and to provide the animation required.
Voices were recorded using a Sony minidisc recorder, and the audio files this produces
were converted from Sony's proprietary format to WAV, and imported into Flash. The
sound of the main character's voice was created adjusting a vocal recording using effects

11. and tools in Sound Forge XP. The pitch of the vocals was raised by speeding up the
playback, then the length of the recording was expanded to return to the pace of the
original recording, whilst keeping the raised pitch.
Testing was done using trial versions of speech readers Jaws (Freedom Scientific) and
Windows Eyes (GW Micro), which were available to download from the web. These
versions are time limited, and require the test computer to be rebooted after a fixed time.
To enable the form to send comments, an open source perl script "FormMail" from Matt's
script Archive was used (Wright, 2005). Data was sent to this script a call for the script url
which sends the information using web protocol (Hypertext Transfer Protocol - HTTP).

12. Results
Results from development testing
The result of the initial developer testing was that the accessibility tool in Flash appeared
to be successful in making the controls work with the screen readers used in the testing
process.
Fields and controls that had been designed to be made accessible without a mouse using
the keyboard all functioned correctly in the screen readers.
The detection script was tested, and failed initially, so that the application sounds played
even when a screen reader was detected. This was fixed by introducing a simple time
delay in between detection and load.
Results from user testing
The results of the Shaw Trust assessment (Kennedy & Broome) of the application were
generally favourable with all testers being able to use the form. The style of the form was
also praised as being fun and testers said that they enjoying having something interesting
to test:
"Shaw Trust Web Accreditation Team is delighted to see developers take a
stance and create exciting interactive applications instead of 'dumbing down'
a site with text only content. It is hoped that other local authorities will take
their cue [from] RBWM and realise that providing a fully interactive and
accessible service via a Web site is a realistic goal." (p.4)
The specific ability of the form to detect a screen reader and turn off sound was
praised as “work[ing] wonderfully with screen reading software and enable a non
sighted user to take advantage of the interactive applications available.” (p.16)
Although the form successfully worked in its initial version, there were also some valuable
usability comments, which were fed back into the form to create a finished version. From
all tests there were seven recommended changes suggested by the testers. Of these
three changes were implemented and three could not be implemented. The remaining
issues were resolved by agreement not to change (see Table 1).
Of the changes that could be made, the main change was an ability to give users better
control of the flow of the process by allowing a replay option to hear sounds again. This
was highlighted during a test by a dyslexic person, but it was also felt a positive benefit for

13. other users such as people with learning difficulties, or people who do not understand
English as their first language.
There were some minor suggested wording changes, which were also incorporated, and
an issue about how the Flash movie was displayed in a web page was resolved.
Of the three unresolved issues two were because the screen reader used and Flash are
designed to work with HTML in different ways, and neither software is specifically
designed to work with the other directly.
• The first of these issues was that a link list function in the screen reader Jaws did not
recognise the controls in the Flash application. This is believed to be because they
were not HTML anchor <a> tags used to create hyperlinks in web pages. The controls
still worked using the tab key, but this was not as good for the tester.
• The second issue that was not resolved was where a person using voice activation
software Dragon SpeakEasy could not use the command LINK. This is a built-in voice
command that creates a numbered list of web links that the user can choose from.
Again this is believed to be because SpeakEasy recognises web links as defined by
<a> tags. Again the controls could be accessed using a visual grid, but this was also
not as good for the tester.
• The final unresolved issue involved a visually impaired user requiring high contrast.
Their normal method of achieving this was to change the local settings on their
computer to high contrast yellow on black. This had no effect on the Flash application.
This was accepted as usable but not ideal.
This was one issue where it should be possible to add extra functionality to the Flash to
allow contrast changes, but these would not be linked to any other contrast changes made
via Windows settings. They would have to be defined for a wide number of unknown
users.

14. Table 1 Issues raised by multi-disability user testing
Recommended/ Proposed
Issue RBWM Response Shaw Trust Team decision
action
Changing web page contrast didn’t Acceptable as is, but No change was made as not deemed as Agreed. It was felt that this was
change Flash contrast preferably make the a major problem by the tester. not an accessibility issue as such.
application contrast change An investigation into whether it could be
too made to work suggests it is not actually Approved
possible in Flash, as the resolution is
being changed by manipulating the html,
and the Flash movie is not the same.
AL
Jaws Links List does not see the Attempt to make the links This feature of Jaws is reading html. The team agreed that as this is
button links within the Flash visible in the Links List option However, the Link List option within where Macromedia Flash and
Application in Jaws. Jaws cannot see Flash buttons (in this Screen reader product developers
case the “Back”, “replay” and “next” need to work together. Currently
buttons.) the only option in Jaws for Flash is
The links can be read out by Jaws once to ignore Flash content altogether!
they have the focus, when tabbing The feature’s can be tabbed to and
through the form, so they can be used accessed.
by Jaws, but it would appear that the
specific List Links feature of Jaws does Approved
not show the links in a Flash Movie. –
This is really identifying a limit on Flash’s
accessibility with this particular access
aid I believe. AL
The voice command Link does not Acceptable as is, but make The link option appears to only work with Again, this is a problem whereby
identify the Flash Links, and so an the Link work if possible html links, and it does not appear to be the manufacturers need to address
alternative method had to be used possible to make it work for links within one another.
to the normal use by the tester Flash movies, only links on the html
page that the movie is sitting in - AL Approved
Lack of control over speech Make the speech controllable Recommendation has been Approved
content being produced by the by the user, so they can hear implemented. All sections now have an
application again if required. additional REPLAY option that can be
tabbed to as a control. This allows user
to replay the speech as often as they
like. AL
User requiring 800x600 screen Ensure application is at top of A solution has been found based upon Approved
resolution for their Kurtzweil reader page to avoid confusion your recommendation. The form now

15. Recommended/ Proposed
Issue RBWM Response Shaw Trust Team decision
action
could not see application at top of launches embedded in a page with no
the page right navigation, and this means the form
easily fits on 800x600 resolution. AL
Speech wording too brief in form Expand the wording to give Recommendation has been Approved
filling section more usable instructions implemented. The wording of speech
help in this section has now changed:
OLD wording:
“Filling out the form”
NEW WORDING:
“Right, use this form to fill in your details
and send us your comments. When you
are finished use the next button”
The application has speech We would also advise you do This is a difficult balance. Although this The team agreed that as the
immediately on launch not have the presentation recommendation is understood, it is felt applications intended audience is
play automatically once the that the target audience of children using children, this recommendation
page has opened but have a the form, the speech should start when need not be implemented.
‘start media’ button’. the form is launched, as it adds to the
impact and usability of the form. This is Approved
partly because the target audience of
young children may have low reading
ability due to their age. Because of this
it is felt the speech instruction should
remain as it is and start on launch. The
additional control over replay of this
speech identified above is felt to give
sufficient extra control to be an
acceptable balance between the
different user needs. AL.

16. Analysis of results
Flash-enabled accessibility
In general, Flash accessibility tools worked well. The tagging of the controls made them
accessible to screen readers, and Flash's screen reader detection method also prevented
confusion successfully by allowing sound to be turned off.
In addition, the use of Flash allowed controls that increased accessibility to certain users.
Using Flash meant that an engaging, visually appealing application could be made, and
this makes it more accessible to its target audience of children, regardless of whether they
have a disability or not.
Limits of interoperability
Where issues could not be resolved, they were to do with specific interoperability between
Flash and other proprietary applications: Jaws, SpeakEasy, and Microsoft Windows. The
findings here should be seen as highlighting the current limits of interoperability only
between Flash and these specific applications.
As interoperability can only be achieved by working together, the solution to these
limitations can only be found by dialogue between the developers of the respective
applications on both sides. In this sense, it would be simplistic and unfair to simply state
that either Flash or the other applications are inaccessible in themselves.
It would be fairer to say that both offer useful accessibility features that can assist the
development of enhanced services, and that although they worked together in most
cases, each package also offers something that does not necessarily work with the other.
Conflicting user requirements
The results also highlighted areas where changes requested for one user group (dyslexic
people) conflicted with another user group (children), and that a compromise was
required. This suggests that the idea of universal design of a single application that will
suit everyone's access needs may be flawed, or at best simplistic.
It may be possible to make a single application technically accessible or useable to many
different users, but that there is a risk that it may be less useful to any of the intended than
creating separate applications that best suit their individual preferred access methods.
In such as case, a universally accessible design would be less useful than separate
different accessible solutions. It is also likely that as the complexity of an application
grows, so that the possibility of creating something that is all things to all users decreases.

17. Conclusions
Success against objectives
The pilot was felt to be very successful. It produced an application that has since been
made into a live service, and one that is appealing for children. The study was also
successful in highlighting the limitations of interoperability that underpin the use of Flash
with features in access software that is used by people with disabilities.
The pilot showed that interactive multimedia created in Flash could be used to add
accessibility, so long as the needs of users are understood. The importance of user
testing by real people with their own access equipment and settings was highlighted.
It is hoped that this study is of interest to others using Flash, and help raise awareness of
these issues.
Overall conclusions
The form successfully demonstrated a simple application that was accessible to the
favoured technologies of the disabled people who tested it, while remaining accessible in
a non-technology sense as a bold and appealing service offering a fun and strikingly
different take on gaining feedback.
The following is a comment from the by the independent tester at Shaw Trust from their
summary:
“We would highly recommend that…you encourage others to follow
your lead. The Team are pleased that you have chosen to work with
interactive platforms such as this and have made them accessible,
rather than avoiding platforms that may be a problem.” (Kennedy &
Broom, 2006. p.15)
The results suggest that universal design of single applications for many different users is
not necessarily the best approach for those users.

18. References
ADOBE. Flash Player statistics. September 2006.
http://www.adobe.com/products/player_census/flashplayer/
Accessed: 08/01/2007
FREEDOM SCIENTIFIC. Jaws for Windows web page. [WWW] (No Date)
http://www.freedomscientific.com/fs_products/software_jaws.asp
Accessed: 08/01/2007
GW MICRO. Window-Eyes demonstration download page. [WWW] 2004.
http://www.gwmicro.com/demo/
Accessed: 08/01/2007
KENNEDY, ANDREA & BROOME, GRANT. User test on Flash application for Royal
Borough of Windsor & Maidenhead. Shaw Trust Web Accreditation & Adaptive Solution
Services. Neath. 31 January 2006
LEWIS, ANDREW. A user survey of the experiences of blind and visually impaired people
using electronic information services, with regard to the practical implementation of these
services in public libraries. In: e-LIS. [WWW] 2004.
http://eprints.rclis.org/archive/00002493/
Accessed: 08/01/2007
REGAN, BOB. Screen reader detection. In: Macromedia accessibility weblog.
Macromedia, [WWW] July 29 2003.
http://weblogs.macromedia.com/accessibility/archives/2003/07/screen_reader_d.cfm
Accessed: 08/01/2007
REGAN, BOB. Best Practices for Accessible Flash Design. August 2005.
http://www.macromedia.com/macromedia/accessibility/whitepapers/
Accessed: 08/01/2007
SHAW TRUST. Web Accessibility Services. (No Date)
http://www.shaw-trust.org.uk/page/3/59/
Accessed: 08/01/2007
W3C. Web Content Accessibility Guidelines 1.0. 5 May 1999.
http://www.w3.org/TR/WAI-WEBCONTENT/
Accessed: 08/01/2007
WRIGHT, MATT. FormMail. In: Matt's Script Archive. 2005.
http://www.scriptarchive.com/formmail.html
Accessed: 08/01/2007