Dr Sofia Celic, Web Accessibility Consultant, Vision Australia Foundation [HREF1], 454 Glenferrie Road, Kooyong, Victoria 3144. Sofia.Celic@visionaustralia.org.au
Dr Andrew Arch, Manager Online Accessibility Consulting, Vision Australia Foundation [HREF1], 454 Glenferrie Road, Kooyong, Victoria 3144. Andrew.Arch@visionaustralia.org.au
Flash developers have traditionally overlooked accessibility, or been unable to address it directly by following the Web Content Accessibility Guidelines (WCAG) recommendations and techniques. In this paper, we describe the application of WCAG checkpoints to the Flash MX multimedia development platform and discuss how accessibility can be incorporated using a variety of techniques.
Flash MX includes some features that improve accessibility of Flash movies, particularly for users browsing with a screen reader and users requiring presentational control. Currently, access to these features requires an Internet Explorer host page, rendering many HTML-specific WCAG checkpoints, such as primary language specification, satisfiable.
Flash MX movies and most elements can have text alternatives assigned and, conversely, access to inappropriate elements can be prohibited. In addition to providing a text alternative for visual elements, this feature can be used to provide context information, correct pronunciation of initialisms, abbreviation expansions and identification of headings, lists and quotes.
Flash MX’s innate scripting language, ActionScript, provides some powerful methods for developers. With careful planning, this allows presentational aspects, such as font and color, to be controlled by the user through preference settings.
Although Flash MX movies are not capable of meeting the accessibility requirements
of all WCAG checkpoints, Flash MX certainly does provide methods to develop
more accessible movies and satisfy most of the checkpoints.
Flash is a popular tool for the creation and delivery of rich online content such as educational material. Accessible education is a requirement of many educational institutions (Alexander & Steele, 2002; AESOC, 2002) and the delivery of learning applications electronically can broaden the audience reach when designed and developed in a manner conducive to a variety of modalities. Accessibility of Flash content to people with disabilities relying on assistive technologies has been greatly limited until the release of the current version, Flash MX, which has addressed many of these limitations, partially through the incorporation of Microsoft’s Active Accessibility (MSAA). In order to take advantage of many of the accessibility features available in Flash MX, the final Flash movie has to be delivered via Internet Explorer on a Windows platform.
The Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (Chisholm et al, 1999) has been widely accepted as the standard, or at least the basis, for creating accessible online content. As such, this has seen a requirement for Flash content to meet appropriate accessibility levels. WCAG 1.0 was written for HTML applications and is difficult to directly apply to Flash content. In this paper we identify accessibility considerations and techniques for Flash MX content according to the intent of the WCAG 1.0 guidelines and checkpoints to increase accessibility of Flash content and provide a basis for grading it’s accessibility to this standard.
This paper, based on initial work undertaken for The Learning Federation's [HREF5] requirements for accessibility guidelines for the developers of online learning modules, only covers WCAG 1.0 checkpoints (or guidelines if more appropriate) that have a particular application to, or suggested techniques for, Flash MX. Most previous articles discussing Flash accessibility (e.g. Clark, 2002) have tended to criticise Macromedia for not going far enough quickly enough with the Flash MX release. While the current product is still not completely accessible to all people with disabilities on all platforms, Macromedia are committed to improving their products. Rather than adding another critique to the list, this paper attempts to document what can be done with the current release of Flash and direct developers to techniques that can be addopted now, and will expand the audience who can access the end product.
The Web Content Accessibility Guidelines 1.0 were developed primarily to promote online accessibility. While WCAG 1.0 was prepared as a "reference document for accessibility principles and design ideas" (Chisholm et al, 1999), it is very HTML-centric. However, it is still the standard for online accessibility in most countries. In the following sections, we consider each WCAG checkpoint or guideline, what it means for Flash MX and what techniques are available to Flash developers to address the relevent accessibility issue.
Every element important for understanding the Flash content screen and navigating the Flash movie must be accessible to a screen reader. By default, text itself, text in buttons and basic form elements will be read by screen readers. Other elements that need to be accessible to a screen reader must have an explicitly associated text equivalent.
Most elements can deny access and careful consideration must be given to which elements should and should not be accessed. Objects consisting of multiple elements can be important in this regard and the accessibility of the object as a whole and of the individual members must be considered. Importantly, not all elements should be accessible by a screen reader.
Text itself may be included in the list of Flash elements that require a text equivalent. Flash does not support markup of text, such as quotations, lists and headings, which provide extra information to a screen reader. Such information can be provided through a text equivalent.
Note: Flash MX elements that cannot be assigned accessible text equivalents are invisible buttons and some pre-made form components, such as combo boxes, list boxes and scroll bars.
The provision of text equivalents for animations can be more complicated. An animation that can be summed up in a brief text equivalent would have this text assigned as the text equivalent for the object as a whole. Other animations cannot be summed up so easily and may require changes in the text equivalent throughout the animation.
Looping animations usually only require the announcement of any associated text equivalent once, requiring careful consideration of where and how to provide text equivalents for them.
Flash MX elements that by default cannot have text equivalents
assigned (such as graphics) or that cannot have their access by a screen reader
denied (such as static text fields) can have this default behaviour changed
by saving them as a ‘movie symbol’ or a ‘button symbol’.
Instances of these objects can subsequently be assigned a text equivalent or
denied access by screen readers as required via the accessibility panel.
The “make object accessible” checkbox in the Accessibility Panel controls screen reader access to the object and any text equivalent associated with it.
Objects made up of more than one element can control screen reader access to child elements with the “make child objects accessible” checkbox in the Accessibility Panel.
Elements or objects that require a text equivalent can provide this through the ‘name’ and ‘description’ fields in the Accessibility Panel. One or both of these panels can be used to provide the text equivalent. An object or element with a brief text equivalent should use the ‘name’ field in the Accessibility Panel and objects or elements with longer text equivalents should use the ‘description’ field.
The hierarchy of sub-components is important for determining appropriate text equivalents for a multi-component object. Which components and sub-components will be announced first? Does this influence the text equivalent that should be used?
Buttons with graphics (including graphics of text) must have a text equivalent provided.
Form objects, equivalent to the pre-made versions offered by Flash MX, can be created manually with appropriate text equivalents added to sub-components.
Although Flash does not use image maps per se, the use of ‘invisible buttons’ is akin to the use of image maps in HTML. ‘Invisible buttons’ are used to designate “hot-spots” and respond to user interaction. Although Flash MX allows the assigning of values to the accessibility fields for these buttons, they are never announced. In addition, ‘invisible buttons’ are dependent on a pointing device for their use. If these must be used, provide redundant accessible links, such as buttons.
In addition, any functionality dependent on the transfer of mouse position coordinate information to the server for processing should be avoided as this information is not accessible to assistive technologies.
There are at least four ways to add captions:
The options vary in quality of text rendering and ease of implementation. Currently there is no consensus regarding the best approach. The choice should always be the option that provides the user with as much control as possible for rendering without losing quality. See references for examples.
User agents currently do not have the ability to access and change presentational features of Flash content. The Flash movie itself needs to provide the user with this capability.
In particular, allow users to change:
The ActionScript Color object can be used to modify or apply colors to Flash content and the ActionScript TextFormat Object may be used to modify text properties. Authors should add buttons with these functionalities attached to allow the user to control these aspects of the Flash movie.
With HTML, the use of relative units allows for scaling to make use of available screen real estate and easy change of font size. Until user agents can access Flash content to allow the user the same control, the Flash movie itself should provide these capabilities.
The Flash movie should be published to resize to the available screen real estate. Alternatively, sizing options can be provided for the user.
In addition, the ‘zoom’ feature, an option of the menu provided in response to a right-mouse click on a Windows' Flash application, should not be disabled. Access to this feature is not available through keyboard methods, and as such buttons should be added to the Flash movie itself to allow the user to change ‘zoom’ settings.
In some movies the ‘zoom’ feature may not be appropriate. In these situations, and preferably in all, provide a method to change text size. The ActionScript TextFormat Object can be used to alter text size. See references for examples.
Flash does not currently support structural markup for headings. This means that browsing software or assistive technology cannot use heading markup for navigation. However, text alternatives and descriptions may be used to mimic the identification of a heading by a screen reader.
Use a dynamic text field for the heading. Ensure the ‘make object accessible’ checkbox is selected and include the identifier “heading” in the ‘description’ field of the accessibility panel. The value of the ‘description’ field in this situation is announced before the content of the dynamic text field.
Flash does not currently support structural markup for lists. However, text alternatives or descriptions may be used to mimic the markup information.
Use a dynamic text field for the list. Depending upon the nature of the list, use either the ‘description’ field alone or in combination with the content of the text field to convey the information appropriately. The selection of the ‘make object accessible’ checkbox controls the access to text field content. For example, only a ‘description’ value of “list” or “list of x items” is necessary if the content of the text field delineates list items effectively to a screen reader. In other cases, a screen reader may not announce characters used to delineate list items, such as the “*” character, necessitating the use of the ‘description’ field value alone to ensure appropriate identification.
For example, a list such as:
may have a text alternative of “List of equipment required: pen; pencil; eraser; paper; end list.” The semi-colon is announced by the screen reader and thus delineates the list items.
Grouped text fields can be converted to movie clips to provide access to accessibility panel fields.
Flash does not currently support structural markup for quotations. However, text alternatives or descriptions may be used to mimic the markup information.
Use a dynamic text field for the quote. Ensure the ‘make object accessible’ checkbox is selected and include the identifier “quote” in the ‘description’ field of the accessibility panel. The value of the ‘description’ field in this situation is announced before the content of the dynamic text field
Flash does not currently support markup for abbreviations or acronyms. As a result, it is important to ensure that abbreviations and acronyms are expanded or explained on their first usage within a Flash application.
If abbreviations and acronyms cannot be expanded in the text, provide the expansion via a text alternative of the acronym or abbreviation using the ‘name’ and ‘description’ accessibility fields.
To aid non-visual identification of acronyms and “correct” pronunciation by screen readers, space the letters out to ensure each character is pronounced. This can be done in the text itself or in the text alternative.
Flash MX has no capabilities to mark up tabular data. Ensure that visual representations of tabular data are grouped into a single element with a sufficiently detailed accessible text equivalent. The text equivalent should contain a brief heading, a summary and a description of the data in a format that would make sense to someone only listening to the information. With complex or large tables it is necessary to provide a link to an HTML page containing the data table marked up with accessible HTML.
Ensure the text equivalents of animated elements change as appropriate with the animation. Appropriateness should be judged by the importance of the change in providing additional/new information. E.g. dynamic decorative effects do not require updated equivalents.
Currently Flash does not offer any way to dynamically change the ‘name’ and ‘description’ accessibility fields of an existing object. Dynamically created objects can be assigned the ‘name’ and ‘description’ accessibility fields at the time of creation via the ActionScript ‘_accProps’ object. Unfortunately, changing these properties after the object is created has no effect. In addition, this technique may not work as intended requiring testing for effectiveness.
Another option is to replace an instance of an object, with one set of ‘name’ and ‘description’ field values, with another instance of the same object but with a different set of ‘name’ and ‘description’ field values. However, this technique may be problematic and should be tested before implementation.
The ActionScript ability to test whether a screen reader is active or not (Accessibility. IsActive() method) and/or whether the system supports communication between accessibility aids and the Flash Player (System.capabilities.hasAccessibility() method), may be used to determine the most appropriate course of action.
The Flash movie itself is a programmatic object and as such should have an alternative for situations where it is not loaded or not supported.
The ActionScript ‘fscommand’ method is utilized to communicate between the Flash movie and script located within the host application. Some other ActionScript commands may also do this for more specific events, such as getting a URL (getURL).
Within Flash MX, ActionScript is used to denote instructions in response to event triggers. Flash MX provides event handlers beyond those available with HTML. Flash MX allows both a ‘mouse’ and ‘keyboard’ interactive devices to trigger some event handlers. The mouse-dependent event handlers that have no ‘keyboard’ equivalent include ‘releaseOutside’, ‘dragOver’ and ‘dragOut’ and should be avoided or, as with other device-dependent event handlers, redundant methods provided to allow users to interact via alternate devices.
Note: “pre-made” components provided within Flash MX that are mouse-dependent should be avoided.
Use ActionScript to provide additional keyboard triggers for mouse-dependent effects and events. For example, “drag ‘n drop” exercises can also be undertaken with a keyboard by enabling selection and movement keys when appropriate elements have focus.
Create components from scratch incorporating keyboard controls, instead of using “pre-made” device-dependent components.
Flash supports dynamic content, including data population and variable content loading. This content may or may not be accessible, requiring testing prior to implementation, to ensure the desired result. If the dynamic content information cannot be made accessible, provide an alternative presentation.
Until user agents are able to freeze moving content in objects, avoid movement in pages or provide a means within the Flash movie for users to freeze movement. This includes looping animations, scrolling text and video.
Provide the user with as much control over the content as possible. Device-independent familiar buttons to stop, pause, play, rewind, fastforward and skip animated content should be provided. Some animations may be more appropriately controlled in a user preferences setting for the entire movie. For example, a user could select a checkbox to disable all looping background movement (and/or audio).
ActionScript provides controls through the Movie Clip methods such as stop(), play(), stopAllSounds(). The Date object and getTimer function should be investigated for pause/resume and other controls.
In addition, do not disable the contextual menu (accessed with a right mouse click) that allows access to controls, such as play and rewind. Note that keyboard access to this menu only appears to be available through a Windows keyboard.
Although the Flash movie itself does not “refresh” to update content, it is a central capability of the application to stream content and request new content at particular time intervals. The changes in content can produce an effect equivalent to a page refresh for some assistive technologies. Potentially, a user browsing with a screen reader will not even reach the area being refreshed before another refresh call is made.
In addition, avoid using ‘http-equiv=refresh’ Meta data or scripts in the host page to refresh pages.
Limit loading of new content to a minimum as each load causes the screen reader to start from the top each time. Provide the user with as much control over this as possible, including being able to stop or alter the time interval between “refreshes”.
Until user agents provide the ability to stop auto-redirect from objects, or their host pages, do not redirect pages automatically. Flash MX supports an ‘onClipEvent()’ function that can redirect users when the movie is loaded (‘load’ parameter) or at some point during the movie (‘enterFrame’ parameter). Flash can also call scripts within the host application to redirect pages.
Configure the server to perform redirects as much as possible. Alternatively, use static content and provide a standard link to redirect the page or movie.
Ensure scripts within the Flash MX movie and within the host application are accessible. This includes avoiding scripts dependent on mouse coordinates or mouse double-clicks and any that provide important information that is not accessible. Some Flash MX elements are not accessible, such as invisible buttons, and should be avoided or provided with redundant accessible alternatives.
Information contained in the ‘down state’ of a button is not available to assistive technology. Text and graphics portrayed in this state and any changes in ‘name’ and ‘description’ field values of the Accessibility Panel are not available to assistive technology. Do not convey important information in this manner unless it is also available in an accessible manner.
Similarly, ‘invisible buttons’ are not available to assistive technology. Although Flash MX allows input for the ‘name’ and ‘description’ fields of the Accessibility Panel, these are not announced by a screen reader. In addition, ‘invisible buttons’ are not included in the tab order, rendering these elements as device dependent. Use accessible interactive elements whenever possible or provide redundant accessible elements.
Ensure that all appropriate elements of the Flash application can be operated in a device-independent manner. This includes any other technologies, such as QuickTime, embedded within the Flash movie, and access to the Flash movie itself.
‘Invisible buttons’ are not included in the tab order, rendering these elements as device dependent. Use accessible interactive elements whenever possible or provide redundant accessible elements.
Keyboard controls can be specified and captured using the ActionScript Key object. This also means avoiding any “pre-made” components that are currently not device-independent. However, be aware of the extent of keyboard shortcuts already employed by browsers, assistive technologies and operating systems.
Use application-level event triggers rather than user interaction-level triggers. That is, avoid specifying event handlers that are device-dependent, such as mouse-specific or keyboard specific events. Instead, use device-independent event handlers, such as ‘focus’ and ‘blur’, or double-up on the specification of device-dependent event handlers (ie, specify both mouse-specific and keyboard-specific events for the one control).
Flash has the capability to call script functions located within a host application. Ensuring these can be activated in a device-independent manner may require avoiding “pre-made” Flash components and creating a device-independent equivalent from scratch.
Keyboard navigation around a web page and a Flash movie should be in an expected order. Users expect tab order to follow a particular visual line and to have related elements grouped together in the tab order. If the default tab order does not follow expectations, the tab order should be overridden to ensure a logical order.
In addition, it is currently necessary to provide a way for users to shift focus out of a Flash movie via the keyboard.
The default tab order of a Flash application is determined by a weighting formula that often does not correspond to the expected visual order (see references for a more detailed explanation of how the default tab order is determined). The default tab order can be overridden by specifying the order via the ‘tabIndex’, ‘tabChildren’ or ‘tabEnabled’ methods of ActionScript. When specifying the tab order it is important to remember that all the accessible objects in a frame need to have a tab position specified. This includes dynamic text objects and movie clips even if these do not need to be tab stops. Otherwise users browsing the movie with a screen reader will have the specified tab order ignored.
Keyboard shortcuts allow quick keyboard access to a link or form control without needing to use the mouse or tab key repeatedly. This speeds up the user's interaction with the page. However, be aware of the use of keyboard shortcuts for operating systems and other software packages that may be in use, such as browsers and assistive technologies, and avoid assigning keys that may interfere with the operation of these technologies.
The Shortcut field of the Accessibility Panel allows for assigning keystroke combinations for objects. An ActionScript Key object must also be specified to capture key presses from the keyboard.
Creating or switching windows changes the "system focus" which can interfere with access devices. It may also surprise and disorient new or casual users and those with cognitive disabilities. Flash movies can call script functions located within a host browser thus providing the means to open new windows, cause pop-ups and change window focus, just as with HTML. In addition, the ActionScript method of ‘getURL()’ has the option of specifying a target or new window that has the same accessibility issue.
In addition, Flash has the capability of layering content, requiring careful implementation of keyboard support and any element equivalents to the layer in current focus only. If focus cannot be achieved exclusively for the current layer, this technique should be avoided.
Provide warnings of new windows and changes in system focus. Warnings should be part of the active element, either as part of the text itself or at least within the ‘name’ and ‘description’ equivalent, if applicable. Text equivalents and orientation information should be used to orient and inform the user of the new focus. If layering of content is used to switch focus, ensure sufficient description of change is provided in text equivalents or as part of the content itself. Also ensure correct device-independent navigation of the layer currently in focus.
Flash MX has an autolabel feature that associates form elements with closely positioned text. For correct automatic associations, the text label must be placed appropriately.
Ensure text labels are placed inside, above or near the text fields to ensure the Flash MX autolabeling feature associates the correct label automatically for form fields. In cases where the autolabel feature is not appropriate, such as when the text equivalent should be different from the text label or when the text label is located away from the form control, a text equivalent for the form control may be explicitly specified with the Accessibility Panel.
It is possible to attach a text equivalent to an entire Flash application that briefly describes the design of the movie and its major components. The description should introduce and explain both the purpose of the screen and its layout.
The ‘name’ and ‘description’ fields of the accessibility panel can be accessed at the _root timeline and deselecting all options.
Alternatively a movie clip can be attached in the upper left corner of the screen that has a description to be read first whenever the screen is loaded. This allows for the flexibility of changing this description whenever a change causes the screen reader to begin again at the top of the Flash screen. This option is apparently more reliable since Window Eyes tends not to read the description field the first time through.
The accessibility panel can be used to directly specify a label for most form elements.
Flash has the capability to present elements in a variety of ways. While this may mean the application is new and interesting, a move from the familiar presentation of, and interaction with, buttons, links, etc may be confusing and disorientating. Flash applications should use familiar presentational elements and use them consistently as much as possible.
Avoid making the “text pixels” alone of a text link active. The lack of active area around the whole text link is counteractive to user’s previous experiences of interacting with links. The user may mistakenly miss the presence of the active link or may be unable to precisely position the pointing device to select such small active areas. Avoid small target sizes as much as possible. ActionScripting can be employed to dynamically increase target size as a mouse approaches, however this technique should not be used on its own, as it is not responsive to other selection devices.
Even though Flash MX still has accessibility issues, this paper shows that multimedia developers can adopt WCAG 1.0 as a basis for addressing accessibility to a significant extent.
This requires an approach to developing Flash MX movies that incorporates the accessibility features and utilises work-arounds. Careful planning of component levels, grouping and their relationships are essential. This means that accessibility must be an integral aspect of developing Flash MX movies and cannot be a separate consideration to be addressed after development. Not only does this ensure an accessible and usable result for non-mouse users and screen reader users, but also allows effective control via ActionScript to provide user settings of presentational aspects. Use of the techniques and concepts described in this paper will ensure Flash MX movies effectively reach a larger audience.
This paper describes current knowledge of ongoing work and will be expanded and improved as techniques are explored and developed. We expect to publish simple examples to demonstrate the solutions discussed. This work has also spurred an international effort to develop techniques and examples, which will also be referenced when available [HREF4].
Our thanks to Bob Regan, Senior Product Manager for Accessibility, Macromedia, who provided extensive reviewing of our work.
Alexander, D. & Steele, S. (2002). "What is happening in educational institutions where students/teachers/lecturers make web pages?". Presentation at OZeWAI conference.
AESOC working group (2002). Draft Disability Standards for Education. [HREF2]
Chisholm, W. et al. (1999). Web Content Accessibility Guidelines 1.0. [HREF3]
Clark, J. (2002). "Flash-MX: Clarifying the Concept", A List Apart, No. 143. [HREF6]