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.

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.

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

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.

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.

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.

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

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

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

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

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

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

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.

Table 1 Issues raised by multi-disability user testing

Issue Recommended/ Proposed action RBWM Response Shaw Trust Team decision

Changing web page contrast didn’t change Flash contrast

Acceptable as is, but preferably make theapplication contrast change too

No change was made as not deemed as a major problem by the tester. An investigation into whether it could be made to work suggests it is not actually possible in Flash, as the resolution is being changed by manipulating the html, and the Flash movie is not the same. AL

Agreed. It was felt that this was not an accessibility issue as such. Approved

Jaws Links List does not see the button links within the Flash Application

Attempt to make the links visible in the Links List option in Jaws.

This feature of Jaws is reading html. However, the Link List option within Jaws cannot see Flash buttons (in this case the “Back”, “replay” and “next” buttons.) The links can be read out by Jaws once they have the focus, when tabbing through the form, so they can be used by Jaws, but it would appear that the specific List Links feature of Jaws does 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 team agreed that as this is where Macromedia Flash and Screen reader product developers need to work together. Currently the only option in Jaws for Flash is to ignore Flash content altogether! The feature’s can be tabbed to and accessed. Approved

The voice command Link does not identify the Flash Links, and so an alternative method had to be used to the normal use by the tester

Acceptable as is, but make the Link work if possible

The link option appears to only work with html links, and it does not appear to be possible to make it work for links within Flash movies, only links on the html page that the movie is sitting in - AL

Again, this is a problem whereby the manufacturers need to address one another. Approved

Lack of control over speech content being produced by the application

Make the speech controllable by the user, so they can hear again if required.

Recommendation has been implemented. All sections now have an additional REPLAY option that can be tabbed to as a control. This allows user to replay the speech as often as they like. AL

Approved

User requiring 800x600 screen resolution for their Kurtzweil reader

Ensure application is at top of page to avoid confusion

A solution has been found based upon your recommendation. The form now

Approved

Issue Recommended/ Proposed action RBWM Response Shaw Trust Team decision

could not see application at top of the page

launches embedded in a page with no right navigation, and this means the form easily fits on 800x600 resolution. AL

Speech wording too brief in form filling section

Expand the wording to give more usable instructions

Recommendation has been 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”

Approved

The application has speech immediately on launch

We would also advise you do not have the presentation play automatically once the page has opened but have a ‘start media’ button’.

This is a difficult balance. Although this recommendation is understood, it is felt that the target audience of children using the form, the speech should start when the form is launched, as it adds to the impact and usability of the form. This is 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.

The team agreed that as the applications intended audience is children, this recommendation need not be implemented. Approved

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.

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.

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