• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Andrewlewis multilib-phase2-report4-rbwm-2007-01-17
 

Andrewlewis multilib-phase2-report4-rbwm-2007-01-17

on

  • 219 views

 

Statistics

Views

Total Views
219
Views on SlideShare
219
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Andrewlewis multilib-phase2-report4-rbwm-2007-01-17 Andrewlewis multilib-phase2-report4-rbwm-2007-01-17 Document Transcript

    • Multi-Lib Phase 2Report 4:Pilot 2An accessible talking customer comment form for children:A specimen accessible Flash applicationproviding a practical customer servicein public librariesAndrew LewisJanuary 2007 Library and Information Services The Royal Borough of Windsor and MaidenheadSupported by a Research and Development grantfrom MLA South East.
    • An accessible talking comment form:Executive SummaryFlash is the most widely available platform for delivering interactive multimedia content onthe web, and as such has huge potential for creating engaging library services that canreach children. Whilst it cannot be ignored as a powerful tool for reaching targetaudiences, it has attracted some criticism for not being an accessible format for disabledpeople.This pilot aimed to put these criticisms and Flashs accessibility features to the test, bycreating a new childrens web service. The aim was to demonstrate a service that wouldbe enhanced specifically by using interactive multimedia and have a real purpose, yet thatwould also be accessible to disabled people using their preferred access technologies.An animated, talking customer comment form for young children was chosen. This wascreated and initially tested by library development staff. This was then further assessedindependently with user testing by the Shaw Trust (Kennedy & Broome, 2006).Professional testers with a range of different disabilities used the form with their ownaccess 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, andthe form was introduced as a live service in June 2006. Flashs accessibility tools weredemonstrated successfully, although the pilot highlighted the limits of these with certainaccess software. These are detailed in the report.The pilot was successful in its aims. It created a Flash application that provided a newfeedback service for children. By using bold and appealing audiovisual multimedia theservice was made more accessible in a non-technological sense than it could be by othermeans, and also remained accessible to the disabled people who tested it when usingtheir favoured technologies set up to their normal preferences.
    • ContentsExecutive Summary............................................................................................................ 2Scope ................................................................................................................................. 4 Flash and web accessibility............................................................................................. 4 Accessibility and user needs........................................................................................... 5Objectives........................................................................................................................... 5Method ............................................................................................................................... 6 Choosing a service to pilot .............................................................................................. 6 Concept development ..................................................................................................... 6 Specific accessibility issues ............................................................................................ 8 Enabling the forms "send" function............................................................................... 10 Developer testing .......................................................................................................... 10 Equipment and software used....................................................................................... 10Results ............................................................................................................................. 12 Results from development testing ................................................................................. 12 Results from user testing .............................................................................................. 12Analysis of results............................................................................................................. 16 Flash-enabled accessibility ........................................................................................... 16 Limits of interoperability ................................................................................................ 16 Conflicting user requirements ....................................................................................... 16Conclusions ...................................................................................................................... 17 Success against objectives ........................................................................................... 17 Overall conclusions ....................................................................................................... 17References ....................................................................................................................... 18
    • ScopeThis report is practitioner research offered to the professional library community, for usewhen considering accessibility within the specific context of multimedia development. It isa 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 shouldbe noted that accessibility is a complex and user-specific subject, and the accessibility ofother 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 audiencesuse, and the specific versions of software employed.BackgroundFlash and web accessibilityFlash is the most widely available platform for delivering multimedia content available overthe web. It is relatively inexpensive to buy, and can be used to create fully interactivegames, interfaces, cartoons and can control other media such as videos. This content isalso 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 readilyinteroperate with other web technologies, and there is a large development community toseek help from. All these factors give it a compelling appeal for developing multimediacontent for use in delivering library services.Flash has however attracted some criticism for not being an accessible format for disabledpeople. Discussion of this issue has centred around how far it is possible to access webcontent delivered in Flash via commonly used access software. Flash movies are aproprietary format, which are not based upon html web standards, but rather use adedicated player to interpret them. Flash can communicate with html, and the Flashplayer plug-in is freely available for web browsers.Popular access technologies are also in a sense proprietary software, and have featuresthat are designed to interpret web standards and re-present web features in an accessibleway.Discussions of Flash and web accessibility often centre around technologies like screenreaders which translate visual layouts to an audio equivalent. Earlier versions of Flashcould not be interpreted by screen readers. Macromedia reacted to this by introducingaccessibility features in version 6 (Flash MX) and above, that were intended to allow theseaccess technologies to interpret text and controls in a Flash movie.
    • Macromedia (now Adobe) have published a discussion paper on how to use Flashaccessibility features, see Regan (2005)Accessibility and user needsAny discussion of accessibility can only be understood in terms of meeting the needs ofspecific users. Flash accessibility is almost always discussed in terms of the requirementsof blind users using the web. However, whilst this is an important aspect, people withother disabilities may have considerably differing and even conflicting user needs.For example, it is not always realised that people who have visual impairment have userrequirements that are different from truly blind people, and can range across issues likescreen contrast or just the simple ability to magnify the size of web screens. People withlearning difficulties may find the use of pictograms and symbols more useful than text.Design factors to be consideredThe judge of a good application providing a service can be viewed as whether it can bereadily used by its intended customer audience or audiences. In other words, usability isthe driver of good accessibility design. The following are issues that need to beconsidered:• 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.ObjectivesThe aims of this pilot were simple:• To test Flashs 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.
    • MethodChoosing a service to pilotThe first step was to consider services that might benefit from the possibilities that Flashcould offer. Due to Flashs cartoon-like qualities, the most obvious area to look at waschildrens services. After considering various services for children, it was felt thatobtaining user feedback from children can be difficult, and this eventually led to the idea ofcreating 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 onwritten instructions can be difficult and daunting without some help, because of a possiblelack of experience or confidence in understanding them.It was therefore decided to create an animated talking customer comment form foryounger 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 technologiesConcept developmentOnce 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 inways that they are comfortable with. Learning is a social activity, and for younger childrenlearning how to do new things often occurs with help from others, such as friends, parentsand teachers. It was therefore decided to recreate this familiar learning situation bycreating 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 readilyassociated 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 soundmanipulation software.
    • As well as being friendly, and bold, the design also had the advantage or being verysimple to animate. See Fig. 1 below Fig. 1 Visual design of the help characterTo allow for the needs of deaf people, the use of subtitle text was required, and thesewere provided using cartoon-like speech bubbles, in keeping with the design style.The characters purpose was to talk the child through the process of sending a commentto 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 contributeStep 2 - Present the child with the form, and explain how to use itStep 3 - Give them the option to review their comment, and either amend it or send itStep 4 - Thank then for sending the commentSee Fig. 2
    • Specific accessibility issuesIt 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. Inthis sense, the form was addressing accessibility of its audience of younger children bybeing suited to their intellectual level. For example, the main help character is friendly andtells children what to do in simple language.All vocal recordings had a corresponding visual version of the message using the speechbubbles, which functioned to reinforce the spoken help and to provide an alternativemeans of using the form if sound was not being used. This was partly to allow childrenwho might be deaf to use it, but also because it could not be assumed that computer achild had access to had sound capability.As well as having the help character explain what to do, the controls on the form also hadspoken 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 takesyou 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, sothat could hear what they were doing as well as see it on screen. These were spoken in adistinct vocal style than the main character, to distinguish that this voice was representingcontent 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 ifthe corresponding key for that letter was pressed.All the built-in sounds combined meant that the form was accessible as a standaloneapplication for most users, including people with visual impairments. However, for peoplewho are blind and using screen readers, this could have been a significant problem. Anysound from the form playing on top of sound from the screen reader would make it veryconfusing and difficult to use.To address these users, a special detection process was incorporated into the form. Thischecked for speech readers before loading the main content. If a reader was present, allsound within the form was turned off. If a reader was not detected, the sound was madeactive. The script for this was amended from a specimen movie one made available byMacromedias Accessibility web pages (Regan, 2003)All controls on the form were identified as accessible objects and given meaningful nameswithin Flashs accessibility panel, following the recommended procedure. Fig. 3 Flash MX 2004 authoring environment showing accessibility panel
    • Enabling the forms "send" functionOnce the form was created, it was made active by making use of an existing mail script,already in use to drive forms on the Boroughs web pages. This was a version of thefreely available generic form processing script FormMail (Wright, 2005).The script itself is readily configurable and easy to install, although to use it requires it tobe loaded to the script bin of the web server used. In this pilot, this was not required asthe script installed by the corporate web team worked with the Flash application with noalteration.Reusing an existing web resource in this way provided a quick and easy means ofsending 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 theresponse, and the customers input from the forms field variables.Developer testingFirst generic testing common to all development projects was conducted. This includedgeneral usability, logic of wording, consistency, style and so on. However specificaccessibility testing was also required.This included checking the accessibility tagging in Flash control by control to see if workedwith two commonly available domestic screen readers: Jaws and Windows Eyes. Thesewere chosen as they were the two readers most often cited by individuals in a previousresearch project (LEWIS, 2004).User testingOnce the form was completed, It was then made available for commercial independentaccessibility assessment by the Shaw Trust (no date), who employ people with severaldifferent disabilities to undertake user testing, using access technologies suited to, and setup for, their specific needs.Equipment and software usedThe main authoring tool used in this pilot was Flash MX 2004. The form was built as anapplication, using Flashs ActionScript to provide user-controls for interactivity, to createthe visual content, and to provide the animation required.Voices were recorded using a Sony minidisc recorder, and the audio files this produceswere converted from Sonys proprietary format to WAV, and imported into Flash. Thesound of the main characters 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 theplayback, then the length of the recording was expanded to return to the pace of theoriginal recording, whilst keeping the raised pitch.Testing was done using trial versions of speech readers Jaws (Freedom Scientific) andWindows Eyes (GW Micro), which were available to download from the web. Theseversions 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 Mattsscript Archive was used (Wright, 2005). Data was sent to this script a call for the script urlwhich sends the information using web protocol (Hypertext Transfer Protocol - HTTP).
    • ResultsResults from development testingThe result of the initial developer testing was that the accessibility tool in Flash appearedto be successful in making the controls work with the screen readers used in the testingprocess.Fields and controls that had been designed to be made accessible without a mouse usingthe keyboard all functioned correctly in the screen readers.The detection script was tested, and failed initially, so that the application sounds playedeven when a screen reader was detected. This was fixed by introducing a simple timedelay in between detection and load.Results from user testingThe results of the Shaw Trust assessment (Kennedy & Broome) of the application weregenerally favourable with all testers being able to use the form. The style of the form wasalso praised as being fun and testers said that they enjoying having something interestingto 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 waspraised as “work[ing] wonderfully with screen reading software and enable a nonsighted user to take advantage of the interactive applications available.” (p.16)Although the form successfully worked in its initial version, there were also some valuableusability comments, which were fed back into the form to create a finished version. Fromall tests there were seven recommended changes suggested by the testers. Of thesethree changes were implemented and three could not be implemented. The remainingissues 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 bettercontrol of the flow of the process by allowing a replay option to hear sounds again. Thiswas 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 understandEnglish as their first language.There were some minor suggested wording changes, which were also incorporated, andan 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 aredesigned to work with HTML in different ways, and neither software is specificallydesigned 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 toallow contrast changes, but these would not be linked to any other contrast changes madevia Windows settings. They would have to be defined for a wide number of unknownusers.
    • Table 1 Issues raised by multi-disability user testing Recommended/ ProposedIssue RBWM Response Shaw Trust Team decision actionChanging web page contrast didn’t Acceptable as is, but No change was made as not deemed as Agreed. It was felt that this waschange 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. ALJaws Links List does not see the Attempt to make the links This feature of Jaws is reading html. The team agreed that as this isbutton links within the Flash visible in the Links List option However, the Link List option within where Macromedia Flash andApplication 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. ALThe voice command Link does not Acceptable as is, but make The link option appears to only work with Again, this is a problem wherebyidentify the Flash Links, and so an the Link work if possible html links, and it does not appear to be the manufacturers need to addressalternative 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 ApprovedLack of control over speech Make the speech controllable Recommendation has been Approvedcontent being produced by the by the user, so they can hear implemented. All sections now have anapplication 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. ALUser requiring 800x600 screen Ensure application is at top of A solution has been found based upon Approvedresolution for their Kurtzweil reader page to avoid confusion your recommendation. The form now
    • Recommended/ ProposedIssue RBWM Response Shaw Trust Team decision actioncould not see application at top of launches embedded in a page with nothe page right navigation, and this means the form easily fits on 800x600 resolution. ALSpeech wording too brief in form Expand the wording to give Recommendation has been Approvedfilling 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 theimmediately 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.
    • Analysis of resultsFlash-enabled accessibilityIn general, Flash accessibility tools worked well. The tagging of the controls made themaccessible to screen readers, and Flashs screen reader detection method also preventedconfusion 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, andthis makes it more accessible to its target audience of children, regardless of whether theyhave a disability or not.Limits of interoperabilityWhere issues could not be resolved, they were to do with specific interoperability betweenFlash and other proprietary applications: Jaws, SpeakEasy, and Microsoft Windows. Thefindings here should be seen as highlighting the current limits of interoperability onlybetween Flash and these specific applications.As interoperability can only be achieved by working together, the solution to theselimitations can only be found by dialogue between the developers of the respectiveapplications on both sides. In this sense, it would be simplistic and unfair to simply statethat 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 thedevelopment of enhanced services, and that although they worked together in mostcases, each package also offers something that does not necessarily work with the other.Conflicting user requirementsThe results also highlighted areas where changes requested for one user group (dyslexicpeople) conflicted with another user group (children), and that a compromise wasrequired. This suggests that the idea of universal design of a single application that willsuit everyones access needs may be flawed, or at best simplistic.It may be possible to make a single application technically accessible or useable to manydifferent users, but that there is a risk that it may be less useful to any of the intended thancreating separate applications that best suit their individual preferred access methods.In such as case, a universally accessible design would be less useful than separatedifferent accessible solutions. It is also likely that as the complexity of an applicationgrows, so that the possibility of creating something that is all things to all users decreases.
    • ConclusionsSuccess against objectivesThe pilot was felt to be very successful. It produced an application that has since beenmade into a live service, and one that is appealing for children. The study was alsosuccessful in highlighting the limitations of interoperability that underpin the use of Flashwith features in access software that is used by people with disabilities.The pilot showed that interactive multimedia created in Flash could be used to addaccessibility, so long as the needs of users are understood. The importance of usertesting 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 ofthese issues.Overall conclusionsThe form successfully demonstrated a simple application that was accessible to thefavoured technologies of the disabled people who tested it, while remaining accessible ina non-technology sense as a bold and appealing service offering a fun and strikinglydifferent take on gaining feedback.The following is a comment from the by the independent tester at Shaw Trust from theirsummary: “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 isnot necessarily the best approach for those users.
    • ReferencesADOBE. Flash Player statistics. September 2006.http://www.adobe.com/products/player_census/flashplayer/Accessed: 08/01/2007FREEDOM SCIENTIFIC. Jaws for Windows web page. [WWW] (No Date)http://www.freedomscientific.com/fs_products/software_jaws.aspAccessed: 08/01/2007GW MICRO. Window-Eyes demonstration download page. [WWW] 2004.http://www.gwmicro.com/demo/Accessed: 08/01/2007KENNEDY, ANDREA & BROOME, GRANT. User test on Flash application for RoyalBorough of Windsor & Maidenhead. Shaw Trust Web Accreditation & Adaptive SolutionServices. Neath. 31 January 2006LEWIS, ANDREW. A user survey of the experiences of blind and visually impaired peopleusing electronic information services, with regard to the practical implementation of theseservices in public libraries. In: e-LIS. [WWW] 2004.http://eprints.rclis.org/archive/00002493/Accessed: 08/01/2007REGAN, BOB. Screen reader detection. In: Macromedia accessibility weblog.Macromedia, [WWW] July 29 2003.http://weblogs.macromedia.com/accessibility/archives/2003/07/screen_reader_d.cfmAccessed: 08/01/2007REGAN, BOB. Best Practices for Accessible Flash Design. August 2005.http://www.macromedia.com/macromedia/accessibility/whitepapers/Accessed: 08/01/2007SHAW TRUST. Web Accessibility Services. (No Date)http://www.shaw-trust.org.uk/page/3/59/Accessed: 08/01/2007W3C. Web Content Accessibility Guidelines 1.0. 5 May 1999.http://www.w3.org/TR/WAI-WEBCONTENT/Accessed: 08/01/2007WRIGHT, MATT. FormMail. In: Matts Script Archive. 2005.http://www.scriptarchive.com/formmail.htmlAccessed: 08/01/2007