Bob Reagan: For those of you who don't know me, my name is Bob Reagan, and I am the Senior Project Manager for Accessibility at Macromedia. And I am in charge of accessibility across the product line. Everything from Dreamweaver to Flash to Freehand.

I come to Macromedia from academia. My background is in education and I am working on a doctorate -- although I find less and less time for it -- in education, looking at education policy; and I came to accessibility in a round about way.

When my fellowship finally ran out, here at the University of Wisconsin, and I had to start working for a living, I started teaching Web design. And around that time I was told that there was going to be a policy instituted here on campus for accessibility. And I knew very little about accessibility. Nothing, to be quite honest. So I had to learn a lot of it, I had to learn everything within a couple of weeks so that I could teach it to other people. And the experience here at the University of Wisconsin has shaped my approach to disabilities from the ground up, in that, in helping people with disabilities access content on the Web, we need to be thoughtful about the experience of designers and how they are going to accomplish the task that are put in front of them.

One of my greatest frustrations, when I was at the University of Wisconsin, was that we didn't have the tools we needed, I felt, in order to accomplish what we were asking of our faculty. We would literally have faculty and staff, occasionally, in tears because they felt like their jobs were on the line and they didn't know html and therefore didn't know how to do what was being asked. And I think that's one of the things that probably been most prominent shaping my thinking about accessibility is about, In order to make accessibility feasible, the tools need to be changed. We need to make sure that we're talking about accessibility in ways that reflect what is going on a day to day basis for developers.

There will always be people who are provided with all the tools they need to make accessible content and will still choose not to do that. And for those folks, we're looking at hooking up a hammer to the back of the monitor to take care of that problem. But for those that do care, and are willing to put forth at least a minimal amount of effort, we want to make sure that we're making accessibility as transparent and as easy as possible. And to put it in language that reflects their level of technical expertise.

So that's my general approach to accessibility at Macromedia.

Now today, we're going to be talking about Flash and particularly Flash MX and the accessibility history there. Having said all of these wonderful things about helping novices, making accessibility easy ... we're going to get into an area where accessibility is not easy. And it isn't something that's transparent at this point.

Before I begin, I would like to learn a little bit about how experienced anyone here is.. Are there any Flash developers in the group?

Guest: I just learned. I just did my first Flash in the past two weeks. Loved it, but I kind of struggled, but hope to learn more.

Guest: I'm not familiar with it. I'm familiar with the program itself, but not…. I haven't used it.

Bob Reagan: OK, so we'll keep this fairly high level then. The first thing we need to understand when we're talking about Flash and Flash and disability is the history of Flash accessibility because the history is fairly dark, in that until this release of the player, of the Flash player, the content of a Flash movie was not accessible at all to someone who was using a screen reader, and it had very limited accessibility to somebody with mobility impairments.

And so about two years ago, there was enough of a concern amongst our customers who were using Flash on a regular basis, particularly in the government, that the company decided that it was time to do something about it. Now, what they did at that point, was to embrace a standards approach to accessibility of Flash. Which means that rather than providing direct access to a screen reader, they chose to use the Microsoft Active Accessibility Standards as a means of communicating between the Flash player and the assistive technology such as a screen reader.

Now for those of you who are not technical and don't know what MSAA is: it operates in the Windows operating system, much like a database. And as content is played by the  Flash player, it's pushed into this database. On the other side, a screen reader or other assistive technology picks up that information and renders it to the user on the other side.

So this is important and it's going to become more important later as we go on. But the idea there is that, using a standard, we could reach a broader number of assistive technologies down the road. Initially, the only screen reader that implements support for this as we launched was WindowEyes from G. W. Micro. And this is a relatively small portion of the screen reader market. The largest screen reader on the market is, of course, JAWS. And JAWS support came later.  That was released in September.  Flash MX was released in March.  So it took them about an extra 6 months to add in support for the Flash player.

Another thing to keep in mind is that because this is based on MSAA, and the changes were made specifically to the Flash player. This only works on the player that runs in Internet Explorer on Windows. That decision was made to prioritize that player first because that's where the largest number of screen reader users and people with disabilities in general were. We wanted to make sure we were going there first.

We will be adding support to other players going forward. And when we have our next major release of Flash … which will be sometime in the future, I can't say when … we will be adding support for additional players. And our plan is, with each major release, to increase the accessibility of another player. Because it is a fairly significant undertaking, to add in support.

Now one of the biggest problems that we have, because this is limited to the Windows operating system under Internet Explorer, while that may have reached the broadest number of people with disabilities, it has not reached the broadest number of developers. And we need to make sure that we're encouraging our developers to be testing their work under Windows, using Internet Explorer with a screen reader.

A couple of things about Flash and disabilities that we need to make clear from the very beginning is that it's not automatic. Simply because the player is able to communicate with the screen reader, doesn't mean it has anything interesting to say. And it's very, very important that we understand that. One of the greatest myths about accessible Flash design is that it parallels accessible html design, and it's just not true. It's not simply a matter of proper structure and description. It much more closely resembles accessible C or C++ or Java design. Accessible Flash design requires more attention and thought on the part of the developer than does html. And it's much harder to automate.  We're going to take a look at some of the reasons behind that today as we go through this.

So, what I want to point to now is, I want to talk a little bit about the accessibility policies  What they have to say about Flash. You know, the question becomes, if you use, a lot of accessibility policies, at least the local accessibility policies, at the level of a department or office lets say, "Oh, no no no! You can't use Flash. It's not accessible." And the main accessibility policies are pretty quiet about the role of third party content such as Flash.

W3C guideline reads: "Use W3C content where available and appropriate." And the decision about whether or not Flash content is appropriate is left up to you, the designer. That doesn't prohibit using Flash development. And, you know, if you ask anybody, the W3C Web content work group, they'll tell you that. But the question about appropriateness is a tricky one. And the way I like to frame the issue is this: that for someone who is blind, the least accessible form of content … or, I'm sorry … the MOST accessible form of content is pure text. For someone with a learning disability, the least accessible form of content is plain text. And that tension between addressing the needs of people with visual disabilities and addressing the issues of people with cognitive disabilities is inherent to design and it's not something that can be resolved easily.

Flash does a very good job of presenting information and structured information in ways that aren't possible with plain text. And so we want to be thoughtful about that. We want to be thoughtful about the fact that Flash is being used merely for kind of showiness or fluff or flash, part of the time.

We want to make sure that the way we're using it is to provide an alternative way of understanding and taking in the same information that we're proving in text. So, for example, in a chemistry course, a lesson on hydro-dynamics. An animation, an interactive animation showing a pressure and volume and changes in pressure and volume can really help somebody with a learning disability, or someone like me who is simply a visual learner, understand information in ways that wouldn't be possible with plain text. Now at the same time, we need to be sure that that's not the only way that we're providing that information. That information is available in a text description. And perhaps with some numerical data along side of it, so that the relationship, those equations, are available and understandable for someone who isn't able to see the Flash animation.

So I think that one of the first things that we need to be thinking about when it comes to whether or not a particular piece of Flash content can be used or should be used, we have to answer the question of what role it's playing within the content. We need to be thoughtful about that.

The question of the accessibility of Flash content within section 508 is mildly clear. But not much. Section 508 is a little bit more explicit in the way that it allows the use of third party content. It considers all pieces of third party content, Whether it's a Flash movie, a Quicktime movie, a PDF, what have you. It treats it all as a piece of software. So a small Flash navigation bar on a Web page, is treated with the same set of guidelines and standards that we use to measure the tool Dreamweaver … or Word … or any other piece of software.

Now the problem with those guidelines is that they're very broad. They do have to address a tiny piece of Flash content, Microsoft Word, Internet Explorer, Macromedia Dreamweaver. And so they don't hit really close to the actual problems that we see with Flash content. And so I thought would I would do today is take a few minutes and walk you through some of the common problems that I found so far, when it comes to designing accessible Flash content.  Before I do that, are there any questions?

Okie doke.

So the first thing I want to talk about is closed captioning.

So, captioning is something that we wanted to make sure we added in, in this release, because we added a lot of support for video. And so it's very easy to add video and we needed to make sure at the same time it was added, it was easy to add captions as well. To do that, we worked with The National Center for Accessible Media and adding in support for their tool Magpie.

Magpie is a free tool that helps generate the caption files, including the timing. But it won't automatically generate the text associated with it. I can quickly take us to that page right there.  Actually I'm reluctant to try anything here at this point.

The thing that we worked with a third party developer to create … an extension for Flash, to import an XML file that's created by Magpie, that loads the captions into a single dynamic text field automatically. So this helps significantly reduce the amount of work involved within Flash in creating the captions.

So, in other cases, you are also able to just use Flash as an old fashioned animation (inaudible), and place text directly on the stage, so that it reflects the action on the stage, and is synchronized with that fairly well.

The next thing that I wanted to talk about was the use of text alternatives. Now in html, text alternatives are one of the most basic things you need to teach people about when it comes to html accessibility. Every image needs to be described in some way. Flash allows the same functionality. And it does put it out to the level of a brief name and a long description, just like you have the ALT attribute and the longdesc attribute in html. However, there are a couple of important differences with Flash, in the way that we assign names.

First of all, not every visual element in a Flash movie is going to want a name. We’re not going to want to describe everything on the stage. And the reason for that is that not everything serves as an actual function. Since screen readers don’t read elements that don’t have a name, we don’t have to think about a parallel like the NULL attribute in html. We don’t need to force the screen reader to be silent about things that are un-named. At the same time, within Flash, we are able to build elements out of a lot of small parts.

So, for example, if we were thinking about a stick figure of the human body, we wouldn’t want a name for the head and the arms and the legs. We’d want a single attribute that describes all of those elements, all at once. And Flash allows you to group elements and make the child object of that group inaccessible. So that we can group together all of the parts of our stick figure and provide a single text equivalent … Dick Banks, Norm Coombs … instead of having each of the individual parts of that group named. So, it’s not like html in that we can check and make sure that every visual element has a name, nor do we want to do that.

Another important part about assigning text descriptions for elements is that Flash also allows elements to be moved, and to move constantly. Now, what happenes is somewhat technical, so I’ll try to explain it as basically as I can. But the end result is that every time there’s a change to a page, the screen reader reads that almost like you followed a link, like you clicked on a link in html. It follows ... it treats Flash as if it's html. And so if we click on a button on our example site here, the screen reader will return to the top of the page. And that’s how we would expect it to behave. However, lets take another example that’s not quite so benign. If we, say, have a banner ad at the bottom of a page that’s constantly changing, constantly looping ... and it’s on an html page that was reading just fine before. The constant movement in the banner ad can force the screen reader to return to the top of the database in the operating system and start reading it over. So for a CNN Webpage, with a banner ad at the bottom, the user might get through a couple of lines, maybe a paragraph, but then it would constantly return to the top.

So there are two ways to handle this. The way that a developer would handle it, is to make these objects, the child objects, inaccessible. What that would do, is allow you to provide a single text description for the element that’s moving, and to hide the elements inside … the moving parts. That would prevent the screen reader from constantly refreshing and re-reading the entire data tree.

Now, assuming that not all of our customers are going to be designing Flash with accessibility in mind, we’ve also worked with the assistive technology companies, to make sure there’s a way of halting the Flash event. We make that very, very clear, that that issue needs to be addressed within the screen reader. WindowEyes has done this, so that it can be done on the fly. With JAWS, it’s a little more complicated because it has to be done in the preferences, which is not an ideal way to handle it.

Any questions about the assigning of ALT text in a Flash movie?

Dick Banks: Is that a relatively recent addition, that's in the MX version of Flash?

Bob Reagan: That’s right. All of this is only possible with the release of Flash MX, which came out in about March

Dick Banks: I have a question, Bob.

There are so many developers that are making $29.95 Flash creation programs. Is it difficult to take those creations and put them in Flash MX and make those accessible?

Bob Reagan: Well, yes and no. The bulk of the improvements are made in the player. And so assuming that these little $29.95 Flash creation programs are used to create relatively simple elements, such as text with a small animation, the text will be accessible due to the improvements made in the player.

However, without a specific effort on the part of that third party tool maker, to create an accessibility object that can be read by a screen reader, the rest of that content will not be able to be made accessible. It’s up to that company to provide a means for adding a text description for making child objects accessible and inaccessible. So, that won’t happen by default. The only thing that will happen with the availability of text, if a tool like that creates standard text … what they call static text … or dynamic text, that information will be available via the Flash player. Does that make sense?

Dick Banks: Yeah, I understood that. Thanks Bob.

Bob Reagan: OK, so let’s keep going. And the next thing I want to talk about is the use of color. And this is a relatively simple thing and it relates to all aspects of design. But it’s really important when it comes to Flash.

You know, before I was a Web design instructor, I used to teach third grade. And one of the things that used to happen is the beginning of each year, we’d break out the big box of 64 crayons. Every kid would want to make sure that the first week, that they’d use every single crayon in the box.

Flash developers, especially new Flash developers suffer from some of the same level of excitement. They’ve got a lot of crayons available and they want to make sure they can use them all. And when it comes to accessibility, we want to be thoughtful about issues for people with color deficits: making sure that we’re not using color combinations that will be difficult to read, that the contrast will be sufficient, that red/green combinations are avoided, and so on.

The other thing that we want to be careful of is we want to make sure that we’re making the text very, very readable. That, you know, we are able to use the Flash player to move in and out of Flash content easily. So we want to make sure that, by default, at the "normal" size, (most people don’t realize that they can do that), that the Flash is as readable as possible. Sometimes our developers tend to like to put complex backgrounds and do things that were more common in html two or three years ago than we are really seeing today with the recent focus on usability in HTML. With the recent focus on usability in Flash, we're hoping to see some of those types of practices fall by the wayside.

Does that make sense to everybody?

Guest: Norm and Dick knew that, in my class in the fall, I used a Flash template with text and used it like PowerPoint. And that text was too small. I couldn’t see it. And I had to insist on an alternative because it was too hard to read.

Bob Reagan: What we should show you how to do is how to right click to zoom in on the Flash. One of the nice things about Flash, that isn’t used very much, is that -- because it’s all vector based -- it grows very, very nicely when you ask it to zoom in. The biggest problem that we have right now, though, is that it only zooms in with the field remaining consistent. It doesn’t actually grow the size of the Flash movie on the page, it just grows the size of the contents within that container. And so it can make things nice and big, so we have to figure out a way how to break it out of the container. Which is a limitation of the Active X control that we are using. Does that make sense?

Dick Banks: Yeah, I understood that, Bob.