Flash used to be inaccessible for users with disabilities, but the 2002 release of Flash MX changed this by including support for accessibility. What was once a barrier has turned into an opportunity for making advanced Internet features available to users with disabilities.

In our earlier usability studies of users with disabilities, we found that the Internet can be a great, empowering tool that gives these users access to experiences and information that were previously difficult to access, if they were available at all. For example, blind users' ability to have a daily newspaper read aloud from a website has greatly enhanced their ability to follow current events without having to wait for special editions to be prepared.

Unfortunately, our earlier studies of how users with disabilities use websites also found that simply making a website technically accessible is not sufficient. It must also be easy to use, even for people using assistive technology, which produces a different user experience than mainstream browsers. Usability and accessibility go hand in hand, and one without the other is not much use in the real world. If something is too difficult to use or if users get lost all the time, they won't benefit much.

Our earlier studies of non-Flash websites generated a long list of usability guidelines to supplement the traditional rules for technical accessibility. There are many design considerations -- beyond technical questions such as ALT text -- that make websites easier and more pleasant to use for users with disabilities. Having an ALT text is one thing, but ensuring that it helps users navigate a user interface is another, and it requires attention to both usability and accessibility.

Preliminary Study, Early Findings

Given our earlier experience, we knew that the launch of Flash MX with accessibility support would require the development of special usability guidelines to make these designs easier to use. We thus conducted a research study on some early accessible Flash designs.

Because the accessible Flash technology had only been on the market for a few months at the time of our study, we had very few good Flash sites available for user testing. Sure, we could have tested old Flash designs that were not accessible, but all we would have found was that without accessibility, there is not going to be any usability worth mentioning. Obviously, if you can't access an application, you can't use it -- not really a finding that would be particularly helpful in guiding designers who want to make Flash applications easier to use for people with disabilities.

Given this, we restricted our research study's testing to four Flash applications that we'd identified as candidates. We are releasing the early findings now to help establish, from the start, good practices for usable Flash design for users with disabilities.

Flash's Main Usability Problems

Even our limited early research identified several usability issues with Flash designs when used by users with disabilities. We identified several key issues that designers must address when creating Flash for users with disabilities:

  • Flash is unknown. Because Flash has been inaccessible until recently, users with disabilities have no experience with Flash designs. As more Flash designs become accessible, many of these users will be encountering Flash for the first time, and will have to make sense of an unfamiliar environment that behaves differently than a static Web page. This is a temporary problem, but will be a real one during 2003 (and possibly even 2004, depending on how rapidly Flash designs become accessible, and thus how soon users with disabilities gain Flash experience).
    To overcome this problem, designers might have to include short instructional texts on websites to help users with disabilities understand how to interact with Flash designs. Obviously, this is a short-term solution to a short-term problem. In the long run, individual websites cannot take on the job of teaching users how to use the Web; websites should instead produce designs that follow familiar standards and interface conventions and rely on the fact that users will have already learned how to interact with such designs.
  • Lack of alternative textual descriptions. Flash designs tend to be highly visual, but users who cannot see or who have low vision need a textual alternative that describes what the visuals mean for the application. For example, a product photo should be supplemented with a description of the salient product features that are being visually communicated.
    I usually recommend against Flash intros, because they are often annoying to users and do not add value to the user interface. But, when animations or other intros are used appropriately -- such as to give users a conceptual model of the system -- they should be supplemented with equivalent explanatory text for users who cannot see the animation and would otherwise be dropped into the main interface without the required knowledge.
  • Moving interface elements. Anything that users need to read or interact with should stay still; moving text and navigation control were big offenders in several designs we studied.
  • Related items spaced too far apart. Things that are used together should be placed close together. Otherwise, such items might get separated when the screen is magnified for low-vision users or read aloud for users who are accessing the design with a screen reader. Somebody who can see a big area of the screen might see both items simultaneously and thus experience an integrated user interface, but users with disabilities will experience a disjointed user interface. Examples of when such spacing is particularly important are:
    • Choosing between alternatives. All alternatives should be visible at the same time, or users might think that only the one, visible alternative is available.
    • An operator and the operand. When one interface element acts on another, both must be visible together.
    • An action and its result. If feedback or instructions are displayed too far from the actionable area of the screen, users might think nothing is happening.
  • Overly complex functionality. Flash applications introduce the ability to offer advanced functionality, making the Web into a full-featured environment. Great, but users with disabilities sometimes appreciate simply being able to get through a process with less hassle and fewer options.
    In particular, many Flash applications let users construct their own objects, layouts, or customized products. Such interactions can be made smoother for users with disabilities if they include appropriate default constructions that can be modified, rather than requiring that all users build everything from scratch every time. Of course, users with disabilities should still have the choice of utilizing the full scope of features and options. They just shouldn't be required to do all the work all the time. It's much easier to modify something than to start with a blank screen.

Further research will probably identify additional issues that make Flash easy to use for users with disabilities. Still, having designers pay attention to the guidelines identified so far will go a long way toward making Flash more accessible -- and ensuring the broadest audience for the new functionality it makes possible on the Web.