Hi, all. I think we''ll go ahead and get started although more people might be joining us, as we start here. I want to welcome you all to the accessible technology webinar series hosted by the DBTAC Great Lakes ADA center. I am Janet Peters, and Im the Project Coordinator of Accessible Technology at our center, and we''re hosting a series of webinar(s) for the 2009 year, and there is several of them on the website coming up, so if you are signed up for those, great, and if you''re interested, please take a look at that. We are here today, we''re going to talk about accessible websites using Flash, and our speaker today is Mike Scott. Mike Scott is an Assistive Technology and Accessibility Specialist. He currently has been focusing on the Illinois Information Technology Accessibility Act which is where I know him from, but he has done a wide range of work with public and private sector clients, helps assess accessibility in existing systems, design and develop new accessibility and train staff on how to successfully implement accessibility in systems, and design and development. Hes very knowledgeable and it is an honor for us to have him here as a speaker and hopefully we will learn a lot in the next hour an a half. Just a few logistics: you can use your microphone to ask a question, by pushing it down at the bottom. Be sure to release it when youre done because only one speaker can go at a time. You can also type questions into the public chat area, and because we do have this session being captioned, Ill repeat those questions, just so the captioner can catch them and have it in the transcripts. We do make an archive of our sessions and so that will be available to you in a couple weeks after this, and well get that up on the website as soon as we can. And there is an evaluation and we would appreciate some feedback. Any comments or questions can be put onto the evaluation and you can also email us and the email is on your web thing right now. With that, Mike, I think I will turn it over to you to get us started with todays session. Thank you.
Thanks Janet. And welcome everybody. Hopefully you can here me now. Somebody type me a note back just to confirm if you can here me, if you would. Alright, I see a few people typing, thats a good sign. Well welcome again, and thanks Janet, I appreciate the opportunity to be here. As Janet mentioned, Im a rehab technologist, in the state of Illinois. Im actually based in Springfield, and the biggest project that Ive been involved in the last year or so is the implementation of the Illinois Information Technology Accessibility Act And part of what weve done with that, in addition to adopting accessibility requirements as a state law in Illinois, is to try to develop guidelines and practical resource materials for the developers on our, the developers in the state. And as weve been working on that front, one of the hottest topics that we run into is the topic of Flash and of multimedia and of video. And its something that I wont claim to have all the answers to yet, but its a question that weve been asking ourselves and doing a lot of work to try and figure out the answers. And thats what Im going to share with you today, what weve discovered so far and as much as we know about the answer to the question: can we create successful websites using Flash? And with that I think I will bring up the slides since that''s the title of the first slide. [Rhythmic clicking] You should be seeing a blue slide that says: "Can you create accessible websites using Flash?" Is anybody seeing that? Let me try it again. Okay. Do you see it now? There we go. I think the weird noise is the sound of the clicking in the embedded browser here. So we''ll just have to ignore that one. With the first slide here as I mentioned, we''re really posing and trying to answer the question that''s presented here, can we use Flash in a way that''s accessible, and that''s what we''re going to get into today. Again, I don''t pretend to have all the answers on this front because it is an immensely complex question and issue, but we''ve learned a few things. So, I will go ahead and click to the next screen. You may have seen this one about the presentation. I will skip on actually, you heard about me, and actually Im going to take...hmm, I see a note that there is a persistent loud clicking sound. I don''t hear it. Its really loud. Janet, do you hear a clicking sound? [Rhythmic clicking continues] I will stop my microphone and see if it goes away.
Ok, yep, I heard it, Mike, coming through your microphone. Maybe now if you try it again it might have been something with your microphone. Let''s try again.
Is it back? It is back? Not back? Alright, well hope its gone to stay. I am going to go ahead and mute my speaker. Does that make any difference? Any luck? I dont hear anything here, theres not feedback, alright if it gets bad, type a note, and I will turn my microphone off and turn it back on and hope that does magic. So I just wanted to share a little bit of background, a little bit of my background. Janet, you did a wonderful job on the introduction there. One thing I wanted to mention is that in addition to working in promoting information accessibility, I have also been in the role with a small team of supporting the Assistive Technology users who are employees of the state of Illinois, specifically the Department of Human Services. And over the last fifteen years or so we have been primarily responsible for setting up and training and providing technical support to probably three or four dozen different Jaws users, a handful of them are text users and Dragon NaturallySpeaking users and a few miscellaneous other Assistive Technologies users. So the-- a lot of the lessons and a lot of the information that weve discovered has come from going beyond just the theoretical and actually working having to support users and so for example we have developed prototypes, or actually production systems, if we don''t do it right, if it is not truly accessible, we hear about it the next day, so weve learned things the hard way, and sometimes I think that makes a difference. Sometimes there is a disconnect between the theory and the practice which is one of the themes, unfortunately, that I am going to be hitting on today. So when it comes up, just remember that it comes from learning it the hard way, actually supporting users using these technologies. Switch to the next slide, you should be seeing an image in the middle that says Flash Player installed. If you''re seeing a sign that says please go and get the FlashPlayer that means that you won''t be able to see the Flash demonstrations that I am using in the presentation. However, there are really just a few in there; I tried to keep it to a minimum. So, if you are not seeing Flash Player installed, don''t worry too much about it, I will be sure to explain and describe when we do look at a few examples on the screen. So, to start out with, we probably need to lay the foundation and ask the question what is Flash, just so that we know what we''re all talking about. It sounds like a simple question, its a little bit harder than it seems because Flash is a number of different things. When we talk about Flash loosely, we refer to three major things, first is technology. Uh-oh, I am getting a flag from across the-- flag from across the hall here. Let me try turning off the microphone and turn it back on. Any better? A little better, okay just drop me a note whenever it comes back, and I will turn the microphone on and off again. Again, Flash can be a few different things. It can be the Flash technology, officially called the Adobe Flash Platform which is the underlying foundation for everything else that is Flash. It is the player, the Adobe Flash player, sometimes referred to as Flash and that is both a stand alone player and more often, a plug in for Internet Explorer, Firefox, or the other leading web browsers. And it is also an authoring tool, and this is the one that we pay for, is Adobe Flash CS4 Professional which is the current version of the Flash authoring tool. So, when we throw out the term Flash, we might be meaning any one of those three things, but obviously they''re all closely related and work together, so hopefully it won''t be too confusing. At its essence though, Flash is vector based animation for the web. Flash actually evolved several companies ago from a vector-based graphics drawing program, that is a program used to draw pictures for the computer that were based on mathematical formulas. For example, a line being described by a starting point and ending point and then the vector figuring out the connection between the two of those, rather than pixel based or raster based graphics which are basically a line as described by all the dots that make up the line and the coordinate of each of the dots. So, originally Flash was a vector based graphics program, and that''s one of the strengths of Flash. Vector-based graphics typically are smaller in size, file size, than typical raster graphics, so they can download faster and they are also scalable, that is I can zoom in and zoom out without getting the pixilation effect that we see when we zoom on faster graphics. So its origin was in vector based graphics. Not long after that there was the addition of animation, and basically animation is just images that are changing over time. So, I have a series of images or frames, just like the frames in a movie that I play over time, and it gives the illusion of movement and change. So the original Flash then was a vector based graphics program, with the addition of animation, it became something that was much more interesting. And then really probably the strongest and most important point about Flash is that it is for the web, and it has been implemented in a way that is one of the most truly cross browser software that we have, and really the popularity of Flash probably comes largely from that, just because its available on Windows platforms, Mac platforms, Linux platforms and so on and even now on some mobile platforms with Flash Lite. So really those three things which are really the core of what Flash is, really are its strengths as well, but it also gives a few insights that are important when we get into trying to deal with the accessibility of Flash. One thing that you''ll realize here is that with Flash''s roots in vector-based animation, that really doesn''t have a whole lot to do with software interface design, and although Flash has been used for interface design, its really not its strongest point. And for those of who you have worked with Flash, the idea with Flash authoring tool is all about frames on the timeline, and the way that interfaces have been built into Flash, the way that it is implemented you can kind of sense it was something added on later, that it really wasn''t the core to what Flash was. So, I think the bottom line there is Flash is very good at certain things and maybe not quite as good as some others, and we''ll come back to that as we move on. As I mentioned Flash can be used for a number of different things. Throughout this presentation we''re going to be talking in three general categories. One is animation, and we have an example on the screen here of a little montage banner, a series of images that fade in and out gradually, that really is primarily, its just decoration, and the image is slowly fading in and out just to give a feel. This was an image we actually developed for the Department of Human Services website when the secretary of the agency asked for a little wow, a little Flash to go on the website home page. So this was animation that was really added just for graphics, and we''re going to be looking at the accessibility issues related specifically to Flash animation. As I mentioned before, secondly that Flash is being used today is in interface design, as in user interface design. And on the screen now weve got a little sample here of a Flash-based sign-up form. Its got an e-mail text box, a format, a drop down box, a check box, and a couple buttons on it, and this is a, developed all in Flash. And even though, again, even though Flash is really an animation product, we''re using it here as an interface tool. So, we''re going to talk a lot about the intricacies of making Flash interfaces accessible, what you should be able to do and what you can actually do to make accessible Flash interfaces. And lastly, and maybe most importantly, at least one of the hottest issues that we have today, one of the hottest topics, is the use of Flash for video. Flash video has become probably the, almost the de facto, format for videos, certainly the preferred format for video on the web. And the example on the screen here, we see a video player showing initially a picture of a clock and if you on your own machines were to click on the arrow, the play arrow down in the left-hand corner of that image, you can actually see a little of that video. I can''t play it for you, but if you want to try it out you can see a little bit of a Flash video, if you haven''t seen enough of them already on YouTube, but heres a little example that we''ll come back to as well. So we''ve asked and answered hopefully the question what is Flash, at least have the basic idea, and I want to take just a moment to ask the corresponding question, which is: what is accessibility? And although I assume everybody on the call is familiar with accessibility, it is a question that I think is always important to throw out ahead of time. It is surprising the misconceptions and the different ideas that people have about accessibility, so to make sure we''re all on the same channel as far as that goes, we''ll throw this one out as well. Hopefully everyone is aware that accessibility is about accommodating people with disabilities. In specific, when we''re dealing with information systems and particularly websites, we''re not necessarily concerned about all kinds of disabilities, obviously someone can use a wheelchair and have no difficulty using a computer system, but in particular we''re interested and concerned in addressing the needs of people with low vision or blindness, people with limited use of their hands, you might not be able to use a typical keyboard or mouse, might need to use an alternative input device, and increasingly, and especially when it comes to Flash, people who are deaf or hard of hearing who may have difficulty hearing the audio tracks and the sounds that can be played in Flash animation and in Flash video, and then also, and increasingly, for people with learning disabilities. Ill just throw out that the area of accommodating needs of people with learning disabilities is probably one of the toughest areas, just because its not as well defined and not as well understood. And we started out addressing the needs of people with learning disabilities by looking for the technologies that we could borrow from these other categories. For example, someone with dyslexia may benefit from a system that can read the words as well as show them on the screen, since many screen magnifiers can do. But we''ll also talk a little bit, and it will come up from time to time, issues of usability that really impact most directly people with learning or other cognitive disabilities. With that said, really what we''re talking about specifically doing when we''re talking about making a website, our Flash presentation accessible, is making sure that we are compatible with the tools that are used by the people with disabilities and those different categories we just mentioned. So we''re talking about, in a web world, we''re talking about making sure that if possible we''re compliant with the font size and color settings that are available in most web browsers and operating systems these days. We''re talking about being compatible with screen magnifiers and screen magnifiers are typically third party software tools that act as high-powered electronic magnifiers that will enlarge everything on the screen, allow the user to pan around, find out what''s going on that will track where the action is, for example, if a menu appears on the screen, screen magnifiers will attempt to move their focus so that the important element that just had a change will be in the viewable part of the screen. And then to some extent screen magnifiers actually these days have built in, some built in, text to speech capabilities. But when we''re talking about text to speech, and really the main category and one of the main technologies that we''re concerned about when we address accessibility is the next category, and that is screen readers. Screen readers are the tools that are used for people who are effectively totally blind. Actually, there are people with much less severe visual impairments who use screen readers. In fact, when we''re working with screen magnifying users, if we run into somebody whose got the magnification much higher than four or five times, on a general basis, we''ll typically at that point try to encourage them to make the transition to using speech and ultimately moving to a screen reader. And that''s just because when the magnification gets that large there is so much panning that goes on that although a user can get by its a terribly inefficient way of doing things. Screen readers can be used by people with moderate low vision all the way on up to total blindness. And for those of who you have worked with Jaws or Window-Eyes, probably the two leading screen readers in the United States, you will know it is a very different experience than working with a graphical user interface as we''re used to. And that''s something we''re going to come back to as well, the fact that a screen reader experiences a web page, or a piece of software for that matter, in a much more linear fashion, they read one thing at a time, and they don''t have -- its not as easy to take advantage of the two dimensional world that the graphical user interface brought us. Looking back to the original days when working with staff who are blind in the state of Illinois, we were working in the DOS world, vocalized back then, and in some ways it was a much easier - it was a much easier problem to solve making the old DOS based systems speak effectively because the old DOS based systems were much more linear in nature, at least a lot of them were. And so it was a real challenge moving to Windows. The good news is though, that we have some very powerful tools now that [break in stream]. Can''t hear me at all? Is it back? Okay. My co-workers here are hollering at me that they couldn''t hear me. Ok, looks like we''re alright. I think I might have a bad connection on my microphone here, but I will try to hold still and not jiggle it too much. Ok, as I was mentioning screen readers have become very powerful tools. In addition to being able to simply read what''s on the screen, they are able to take advantage of the information that is provided by web pages in particular to do things like bring up an ad hoc table of contents of the page based on a heading markup thats available in html to allow a user not only to read but to effectively skim a page as a sighted web page user would do. Screen reader is able to bring up links lists, navigate from link to link, forms lists, table lists, use powerful table reading commands to identify for any given cell in a table what is the row and column header. So there is very powerful capabilities especially when were dealing with typical HTML based web pages. And so that''s one of the things too I want to point out and we''ll see how that differs to some extent with what''s available when we''re dealing with Flash-based web pages. In the category of physical disabilities, as I mentioned before, there are a lot of people out there who have physical disabilities that prevent them from using a regular keyboard or mouse. Often the mouse is one of the first things to go - you might not even be to the level of considering yourself having a disability and not be able to use a typical mouse- carpal tunnel syndrome, a little bit of arthritis, can make that, make a typical mouse very difficult. So one of the things we look at is making sure that we are compliant with keyboards and alternate keyboards or operable with keyboards and alternate keyboards, and that''s one of the basic premises thats not listed on the screen here of how we ensure accessibility. And then of course moving up a notch we have powerful speech recognition tools like Dragon NaturallySpeaking that can allow a user to navigate a web page or an interface using only speech commands. And then finally, and especially important in talking about Flash, we have issues of closed captioning. While this is not really an Assistive Technology, it is an assistive technique, maybe if you will, that we need to be aware of. And since there aren''t any tools that automatically create captions for users who can''t hear, the holy grail is to combine speech recognition closed captioning, so that closed captions can be created on the fly. But unfortunately, the modern technology just isn''t there yet, so closed captioning is not an Assistive Technology that we need to worry about being compatible with but rather an accessibility feature that we need be aware of and may need to provide, and we''ll take a look at some ways, some good ways, actually, of doing that with Flash. Just to wrap up the little chat about accessibility here, I will point out that, and I assume that most of you are aware of, that the leading accessibility standards, the World Wide Web Consortium developed the Web Content Accessibility Guidelines 1.0 back in 1999. Those are guidelines that were very much oriented to HTML, the technology of the day. Just last month in December of 2008 the W3C [World Wide Web Consortium] finally got through the update of the WCAG guidelines [Web Content Accessibility Guidelines], the version 2.0, and in version 2.0 we''ve seen an attempt to make guidelines that were applicable to more technologies, not just HTML but Flash and other web technologies. Although I think the effectiveness of that is going to prove itself in time, but it was a challenge that was hard to undertake, and in a lot of cases the WCAG 2 guidelines are very general and don''t give us specific guidance on what actually do we need to do with the technology like Flash, although those techniques are being developed as supporting documents already. Lastly, just to point out the section 508 standards which were adopted by the United States government in 2001 really are, really don''t speak much, and really in a useful way anyway, to technologies like Flash. The United States Access Board is currently working on a complete overhaul of those standards to be more in line with WCAG 2, and hopefully we''ll see some things in there that do give us some guidance for complex technologies like Flash. But I guess the bottom line here is we don''t have a lot of specific guidance. It is not as simple as looking up a standards or guideline document and saying, here, you know, we need to do A, B and C. We had some general guidance available, and then its our job to figure out how do we actually -- what do we do when the rubber meets the road, and that''s what we''ll talk about today. So, back to our question: Can we make Flash accessible? Well, let''s take a look at this. I will throw out a short answer to start with and that is in theory. And I want to give Adobe credit. They have worked very hard to build in accessibility features and accessibility capabilities, and in most cases they have done the right thing, in particular, when we''re talking about accessibility specifically on a Windows platform, we''re concerned about an underlying technology and underlying programming interface called Microsoft Active Accessibility, MSAA, and Adobe has done exactly the right thing in providing information from Flash to MSAA with the idea then being that MSAA is the bridge that provides the information to the assistive technologies. It is a good model, and again Adobe is doing the right thing. Unfortunately, the reality is that it doesn''t always achieve the end. It doesn''t always make the software, the interfaces, the web pages, usable by people using different assistive technologies in the way that we wish it would, at least with current assistive technologies. And that will be getting better, but one of the things that we need to worry about today is recognizing the difference between accessibility in theory and accessibility in practice. So as I walk through these next few slides that''s the main thing that I want to point out is: whats the way we''re supposed to do things and, from our experience anyway, what actually works. So, from there I want to jump into the first segment, and we talked about Flash kind of having three general categories: animation, interface and video, and those are a little bit arbitrary to draw the lines there but in dealing with accessibility it is helpful to break it down this way. Let''s start with the easy, one or the simpler one anyway. Flash animation. Just to be clear, animation again is really what the root of what Flash is about. It is a series of images or frames like in a movie film that change over time giving the illusion of movement. For our purposes, and we''re talking about animation to differentiate from the other two categories, animation may include text and it may include some audio, but we''re going to draw the line for this discussion at not including speech. If we have animation that includes speech, it probably ends up being addressed more like it would with videos, and we''ll get back to that. So for now, were talking about simple animation which is basically a series of images changing in time. We''re not, at this point, talking about interaction or true multi-media audio and video. If you remember the example, the example that we had looked at earlier was that banner ad that slowly faded from one picture to another, used primarily for decoration. The accessibility issues with Flash animation, to simplify them, really can boil down to three major ones. Number one, any time we have movement, simulated movement, on a screen, we have to be aware of the possibility of triggering photo sensitive epileptic seizures. There are certain Flash rates, certain colors that can actually, when shown to a user who is sensitive to it, might trigger a seizure, and so one of the things we need to do and it is really a subjective guideline is just be aware of that and make sure we don''t have any strobbing, and specifically the accessibility guidelines lay out we don''t want to have to have things that flash faster than two or three Hertz, two or three times per second. And doing that we should be able to stay away from or reduce the likelihood that were going to trigger a seizure for somebody who might be viewing our page. And again, that is not something we do technically within Flash, not something we have to turn on or turn off, it is just something we need to be aware of and pay attention to. Secondly and similarly, one of the things that we need to do in dealing with animation is try to avoid distraction. Be aware of the fact that animation and movement, the way that human sight is hard wired, animation and movement is supposed to -- we''re designed to pay attention to that, and it will attract our attention which is why, often why animation is used, especially why animation is used in ads. However, when we''re trying to create a usable and useful user interface, we need to be aware of the fact there are some people with certain visual or cognitive disabilities who might not be able to filter that out. So, that if I have a decorative animation going on over in the corner, for users with some certain cognitive disabilities, they may not be able to read the rest of the page because they''ll continually be, theyre attention will be continually distracted over to the animation. So, again this is not a feature we turn on or off but really a principle that we be aware of as were designing our animations, that we want them to be, not to be distracting, and that''s often a fine line. Third, and probably most difficult, is the fact that for animation just like with any graphic, even a static graphic, screen readers are not going to be able to read out, in most cases, the information that''s in the purely visual, the purely graphical part of an animation. And so we have the issue of needing to communicate equivalent information, in other words provide all text as we do in the HTML world for users who are blind so it can be read by their screen readers. To take a look at how we do this in Flash, there are some techniques that we can use. Again, in dealing with animation we''re looking at primarily how do we, the question of, how do we provide alternate text for a screen reader to -- how do we provide the textual equivalent of whatever information is being provided by the animation so that the screen reader can read it to someone who is blind. The first thing we need to be aware of is that there is a way in Flash to provide what is the equivalent of alternate text. Unfortunately, it is a little bit hidden, its not on any of the default layouts within Flash CS4, so the first thing we need to do is find the accessibility panel and that is hidden under the Windows menu, other panels submenu and the accessibility option. When you select that or hit the hot key shift F11 it will bring up a panel, which looks like the image on the right side of the screen here, that gives us some options on what we do as far as supporting accessibility. And you will notice that we have name and description here and you''ll see in just a moment how we can use those for alternate text. Now, to determine what we need to do with animations, we really need to break animations down into a few more categories, and just like we do with images and determining how to provide appropriate alt text we would break animation down into decorative animation, meaningful animation and complex meaningful animation. Basically breaking down with decorative animation being animations that really don''t communicate any significant information, theyre really just there for looks. The montage image that we looked at earlier was an example of that, it really wasn''t there to communicate anything, it was to provide some visual flash to the web page, really just to make it more visually attractive. In that case we want to do the same thing that we would do with an invisible or a purely decorative image on a web page in HTML, and that is we want to tell a screen user that: you can safely ignore this. So, its basically the equivalent of doing -- setting the alt attribute to an empty string in HTML, in an image element. And the way that we do that in Flash is to basically take the whole movie and uncheck the first check box, which is make movie accessible. With that check box unchecked, the Flash player will not relay any information about the movie to MSAA which in turn will have nothing to relay to the screen reader. So when the make movie accessible box is unchecked, the screen reader will basically say -- most of the screen readers will identify that there is a Flash object there, it will say, Flash object Jaws anyway, so its Flash object start, Flash object end, so its basically an empty Flash object. So this is kind of the intended way of identifying a decorative animation that can be safely skipped by a screen reader user. Now, meaningful animations are a little bit trickier, not much, though, the same way that if we had an image that was communicating something, whether it was the logo of the organization that the website was about, or a photo of something, we''re going to want to provide simple, alt text in that case and to do that in Flash we''re going to again use the accessibility panel. This time we need to check the box that says, make movie accessible, that globally turns on the ability for the movie to present information to a screen reader. And in this case we''re going to check that first box but were not going to check the next two boxes. This next box is the make child object accessible, and thats basically the question of whether we want to reveal any detail about the contents of the movie. For a simple meaningful, a simple but meaningful animation, where we''re communicating something like the name of an organization or a simple message that can be stated in, you know, a few dozen words, we really just want to provide a simple alternate text. And so weve seen in this example here, Ive checked make movie accessible and not checked make child object accessible and in the name field Ive entered, Ive entered word alternate text, but that would be the text equivalent, and just like alt text for HTML images, the text that''s entered there should be a functional equivalent- what information does the image, the animation in this case convey? Not what does it look like, I don''t care if it is blue on a yellow background, whatnot, I want to know what does it mean and the rule of thumb in determining that is if you were reading a web page to someone over the phone, what would you say? Would I say it is the Department of Human Services logo, I wouldn''t say it is the letter D, H and S with a cut out of several people in silhouette- I don''t need that much information. I want to keep it as concise as possible and that''s what can be entered in the main description. Interestingly, we do have two fields here: name and description. Effectively, there isn''t any difference between the two. In theory, name should be short and description might be a little bit longer, but when the screen reader -- when this information is revealed through MSAA, theyre typically -- almost always revealed together. So whether I put it in name or description or a little bit in each, it really doesn''t make any difference. The rule of thumb is that these things can be read as a unit in place of the content of the Flash movie, so in this case a screen reader encountering this Flash object, Flash object start, alternate text, whatever that might be, and then Flash object end, and that would basically give them a simple alternate text, same information that that animation is conveying. For complex meaningful animations, this is an animation that is kind of the equivalent of a chart would be for an image. Its something that conveys a lot more information than can simply be provided in alternate text or even in the description. You know I might be able to write a paragraph describing, but for things like charts or for some animations where we show how things move together or assemble together, change over time, change and relationship to each other, really we need a much richer way of providing that information, and unfortunately in those name and description box we''re limited to putting in just straight text. We can''t put any structural information, so in this case for meaningful animations, complex meaningful animations, we really want to consider providing an HTML alternative. And I think that its an important thing to point out when the limitations of Flash here. Flash doesn''t replace HTML. Flash again, evolved from a graphics program, added a timeline so that we could have the illusion of movement in our graphics. It is not at all like -- it is not as all a structured document language like HTML. There is no concept of headings, lists, tables [indiscernible] or structure of any kind. So, if I need to present for example the equivalent of an animated graph and really the best way to present that to a screen reader user is using a table where Ive got relationships between cell headers and row headers and data and so forth, I really cannot do that justice in the name or description field for the Flash movie, and in that case we really want to consider providing an alternative. And its kind of the equivalent of what we would do when we might consider using the long desk attribute in HTML to provide a link to the full equivalent of a complex image in HTML. So we''ve got some options to enter effectively alt text for flash animations. How does it work in the real world? Unfortunately, the news is not good. Jaws in all the testing that I''ve done is not, at least not reliably, reading what I have entered in, what weve entered in name and description fields, it just ignores it. Weve tried it with JAWS 10, weve tried it all the way back to Jaws 7. It is apparently choosing, intentionally, to ignore that information. You can check, we checked with some of the MSAA inspection tools, the information is definitely there, but its not reading it out, and that''s an issue that we actually want to follow up with Freedom Scientific about, to ask why is it being done. Can it be changed? The reality is that sometimes the screen reader manufacturers, and Freedom Scientific in particular, will maybe side step the rules a little bit in order to give their users the -- what they feel is the best experience. And its very possible that if they''re feeling like the name and description is not typically being, in the wild, is not typically being used for appropriate things, that they''re ignoring that. We''ve run into that with Jaws and some other scenarios, and so we''ll be following up with Freedom Scientific to see if that''s the case and if it can possibly be changed, or maybe make a setting. But for now, Jaws is not consistently reading name and description, and similarly Windows-Eyes, although it does sometimes read the name and the description, its not reliable. And that''s one of the most frustrating things in dealing with these technologies, the assistive technologies; they''re such complex beasts that they are often inconsistent and a little flaky. And unfortunately, while Window-Eyes is trying to do the right thing, taking that, receiving that MSAA information and reading it back out, in our testing its not doing it reliably. Sometimes itll read it, sometimes it won''t and so far we haven''t been able to figure out what determines when it does and when it doesn''t. So, in practice weve got some problems in dealing with even providing simple alt text, the equivalent of alt text for a Flash animation. Interestingly, there is a potential work around, and I haven''t been able to determine whether this is on purpose or not although we have seen that some other folks have confirmed it to be true, and that is that if we set a certain parameter on the Flash movie when its embedded into an HTML page, and particularly the W mode or Window mode parameter- if that is set to the values of opaque or transparent, both screen readers -both current versions of both Jaws and Window-Eyes- are ignoring the movie completely. They''re not even saying Flash movie, Flash start and they are instead reading the alternate content that can be placed within the object tags. Ive got a little code example on the screen, weve got an opening object tag, the W mode parameter set to transparent and then inside, before the closing object tag, I have a paragraph, it says alternate HTML content and it could be anything. It could be a table, it could have headings, it could have full HTML markup, and with this setting set, the user is getting that equivalent content which is a good thing. The only fear that I have about this is because it is not documented anywhere that we found in the Flash documentation as being something done on purpose, it may go away in future versions. So, for now we have a work around and also, actually we discovered this one as a problem because we had Flash that we were wanting to reveal some information through the name and description, and the screen readers wouldn''t read it, and it ended up that it was, it happened to be a montage image that for visual reasons wanted a transparent background. We had checked the option; the published office in Flash, to make the background transparent and it had quietly, without telling us, it added this parameter, the W mode parameter, and effectively made the flash object invisible to screen readers. So, good to know about, mostly you don''t get surprised by it when you don''t want your object to be invisible but also useful sometimes when you do want it to be. So in summary, in looking at Flash animations, weve seen some ways to provide, to use decorative animations, and clearly if animations are purely decorative they really don''t pose much problem. It is easy enough; weve got a couple of different ways, of telling the Flash not to read anything to a screen reader. So if we have a decorative animation that''s not conveying information, we are able to tell the screen reader to ignore it either by setting the, un-checking and making accessible by using the W mode setting to tell the current screen reader to ignore it. So, the good news is: there is no problem in using Flash for decorative animations. It is a little bit trickier when we come to meaningful animation because of the inconsistent behavior. Again, Adobe has done the right thing, weve got the ability to provide a name and description, it is revealed through MSAA, but because the current screen readers aren''t consistently reading that information we have a practical problem. So at this point we would probably recommend staying away from using those techniques and instead, either relying on the W mode work around if you will or just simply provide and make sure the information is provided somewhere else on the page, providing a link to a non-Flash version, providing it further down on the page, some alternative for meaningful images or animations. Maybe I will take a moment just to ask: are there any questions about the Flash animations? I see we had a question earlier about: Is there any way to find out if a user is using a screen reader through Flash? And that''s something that well actually talk a little bit about here relating to Flash interfaces. Flash unlike HTML, Flash actually can identify whether the screen reader flag and the operating system is set, so the answer to the question is yes. Flash can determine whether a screen reader is running. However, there are a couple of implementation options with that, and that is number one: it can take a short amount of time for that parameter to be read, so it is something that we don''t want to do in the first frame of a Flash movie. It needs to be put later in the movie so the Flash has the time to query the operating system and get that information. It also is only going to be true if the Flash object has focus. So yes, it can be done, theres some tricks in getting it done, but that actually is one interesting option in that, we''ll kind of talk about that as we get to the end of interfaces here. We have another question: do you know if the accessibility options that you were showing exist in older versions of Flash, specifically CS3? Yes, I think that the same accessibility panel goes all the way back, something very close to it, goes back all the way to Flash MX. So it goes a few versions back, and it looks like it works just about the same, its getting slightly better in each version. But we still do have the problems with screen readers acknowledging it, but it does work similarly if not exactly the same in a couple, in CS3 and all the way back to MX versions of Flash. Heres a question: where is the cursor inside Flash on the stage inside the movie clip when accessing the accessibility panel and choosing the options you have shown here? Thats a good question. When we''re working actually in the Flash authoring tool and want to -- we look at, let me back up here a couple of screens- and we look at the accessibility panel, the way that Im showing it right now, the focus is on the stage. So when we want to set the properties that are global, make the movie accessible, auto label, which we''ll get to, those settings, to set those settings, the focus in the Flash authoring tool needs to be on the stage. You don''t want to have any other object focused, and then youll get the accessibility panel that I have seen so far. Im going to show you in just a minute what it looks like when we have focus on a component within Flash. So, let''s jump into Flash interfaces. Again, Flash interfaces are -- we have a sound problem. Oh, Im sorry. I missed a question. I didn''t see it there. Thank you. What about using Flash for a site link menu as a work around? Well, site link menu really gets into interactions. So, let me hold on that and talk a little bit about interface interaction and we''ll come back to that. So an interface, to differentiate from simple animation, interface is something where the user interacts, basically animation in the Flash world. Its an animation because everything we do in Flash is an animation, its a timeline. But where the course that the animation takes depends on what the user does so if I may click a button and jump to frame 55. I might click another button and jump back to frame 1, thats kind of in the simpler sets. So an interface in this sense is something that a user can interact with and its made with elements such as buttons, menus, text box drop down lists, et cetera, et cetera, basically anything the user is going to interact with. The key to Flash interaction and interface is action script. And behind the scenes, without getting too deep into it, action script is a Java script like language that watches for events like mouse hover, click, et cetera and allows us to attach little snippets of program codes, functions or methods that tell the program what to do. So for example, I use action script to say, watch this button, and when a user clicks on it, go to frame X. Components and other important parts -- components to Flash interfaces are components, and components in this sense are pre-built Flash objects that mimic the standard controls that we''ve come to expect in interfaces, things like buttons, check boxes, color pickers and I have a little image here of the components panel on the screen and it shows a list of about 15 different components that are built into Flash, and well use these, for example, in building little forms. So, the accessibility issues with Flash interfaces, again, well look at three of the most significant ones. Number one: there is a usability issue. And again, this is a subjective one, and it impacts really all users, but especially people with cognitive impairments. One of the problems with Flash is that it allows users to -- allows authors to do nonstandard things. I can make a mosaic into a menu. I can do all kinds of things, and from a usability standpoint the problem we have is that a lot of users may not expect -- you know we''ve come to expect that a white rectangle is a place I can type; that a rectangle that is slightly raised with words in the middle, that looks like it is raised, looks like its 3D, is something that, a button that I can click. And theres a usability issue for all users whenever I make up my own control types that the users may not understand what theyre for. And thats again, theres nothing that we can do, or turn on, or turn off, its just something that we need to be aware of. Our users, especially those with cognitive impairments, dont understand how to use your Flash interface if it doesn''t follow the convention. Secondly, and more technically, we want to make sure that our interfaces are useable from the keyboard as well as from the mouse. We talked about users needing to use keyboard devices and its very important, and kind of one of the fundamentals of accessibility, is that if I, in addition to being able to operate an interface with the mouse, I can also use the keyboard, I can use the tab key to move from field to field to field, I can use the regular commands to type things in to the appropriate fields. I can use inter-space bar to activate buttons, check, check boxes and so forth. And then lastly, and by far the most difficult: screen reader compatibility. And for a screen reader, beyond keyboard accessibility, a screen reader user, a screen reader needs to be able to indicate that, hey, you know, this is a button, that''s a text field, this is a dropdown list, and its got so many options. It needs to be able to identify the name, the role, and the state of any kind of interactive development so the screen reader user knows what to do with it. With those main issues weve got a few techniques that can help. 1) Use standard controls. Certainly the controls in the default components list are a good start. However, there are a subset of them that are better, more accessible than others, in particular: button, check box, list, list box, radio button, text area, text input. Those fields all work relatively well, theyre kind of the most basic. Some of the other ones like color picker, numeric stepper, scroll pane- the slightly less usual interface elements, at least so far, are posing a real accessibility problem, largely because the screen readers don''t know what to do with them. Secondly, enable accessibility. This is a frustrating little step that we have to do. Basically, each time we use a type of component, and remember back to the sample form, we looked at it, it had a combo box, a dropdown box, it had a button, some buttons on it, and some text boxes. Each time we use a button or check box or combo box, we have to write two lines of action script code, and the little window on the right here shows that code, the syntax is: import FL accessibility button act simple dot enable accessibility. Basically, what this does is turn on the accessibility features that Adobe has built into these types of controls. The explanation as to why its not enabled automatically is slightly lacking. It is pointed out that it is not enabled automatically, the reason given in the documentation is that its because it is hard to remove once its enabled. My guess is it has to do with the additional resources and file size that comes along, but I may be wrong about that. But for whatever the reason is, in order to use accessibility features even of the standard types of controls, we need to write some custom Java script code for each Flash interface that we build. And for what its worth, interesting to point out, there are a couple controls that don''t require these lines of code, in particular the text area, text input, and label controls, the accessibility is automatically enabled. And from trial and error it appears that buttons work pretty well without the accessibility enabled button. For good measure, since the documentation says do it, we''ll go ahead and assume that we need to do it. So, in addition to turning on these technical accessibility features, we also need to make sure that, just like in an HTML form, that the form fields are all labeled appropriately. And there are a couple of ways we can do label. If you can remember back to the original view of the, the original accessibility panel, that we looked at when the stage was selected, one of the check boxes there was auto label. And when that box is checked, its a global setting, and when that box is checked, Flash will do kind of what the screen readers used to do and that is, when it sees a text box, it will look above and it will look to the left and it will see if there is some text sitting on the screen and itll use that as the label for the text box. So, when a screen reader user comes to that text box, it will say, name, text box, description, list box, shortcut, text box. It will try to automatically associate the right label with the field so that the screen reader user knows what to enter in that field. Unfortunately, like most auto magic, auto label works sometimes and doesn''t work other times. It has to do with how close the field is, if it is to the left and/or above and pretty close it usually works well. If it gets very far away, Flash can make a mistake because its just guessing. So, unfortunately in Flash there is no way to explicitly associate a piece of text with a field as its labeled, so we have to do, basically do it the hard way, and that is we have to enter for each field something into the name attribute for that field. So, by providing a name for a text box, we can unequivocally tell the active accessibility what this thing should be called, which can relay that to the screen reader. And when Flash sees that there is a name present, it will not even bother trying to do the auto label. So, auto label is nice when it works, but entering in names, although it is redundant and extra work, is more reliable. Mentioned before, one of the reasons that we want to avoid using custom controls, I can make almost anything into a control in Flash, but whenever we do that, we have to revealwe have to do a lot of -- we actually have to program the controls to have things like names and roles and states and that''s something that gets very complex and very involved. And we wont spend any more time on that. Lastly, in dealing with interface accessibility, we have the issues of reading and tab order. And this is the issue of, not only again, not only can the screen reader read what''s on the page, but it needs to be able to get it in the right order. Reading and tab order is a little bit finicky with flash. Recommendations to make sure that things read in the right order include limiting the size of the stage. If you have a simple single column or single row, like the accessibility panel is an example what that would be like, even though its not done in Flash, that''s likely to read in the right order. However, if you get anything much more complex than this, a lay out much more complex, you will very quickly get things reading in the wrong order. The good news is that Flash does provide this tab index field, so right now we''re looking at the accessibility panel with an object selected, and in this case we have some of the same things that we saw before, make objects accessible, make child objects accessible, main description, et cetera. Now we also have a tab index setting which is supposed to be used to --for us to specify the order in which the elements come. There are some tricks and gotchas in that, however, and unfortunately we have not had good reliable luck in getting the tab index feature to work correctly. The documentation indicates that there are certain element types that can have tab index and certain that can''t. For example, static text on a page can''t have tab index, and at least in the older versions of Flash, the problem was that if you had even a single element that couldn''t have tab index, such as a static text like the title of the page, that would remove, effectively remove, the tab index for the whole rest of the document. There is some suggestions in the CS4 documentation that it should be working better now, again, we''ve not had consistent luck with it yet, so we''re still working on that. Again, in theory tab index is there and does the right thing. In practice, it is not working reliably for us yet. Lastly, there is some suggestions in the older documentation using an alternate off stage interface, which if it got to that point where I was having to duplicate my whole interface off the stage where it is invisible, I would probably recommend not using Flash at that point. Its possible to do some very custom things, but the amount of extra work to do that really makes it not a good solution. Last issue we''ll point out here with interface accessibility is, so far we''ve been talking about the technical issues, but there are also conceptual issues. Again, as I mentioned earlier, screen readers are linear, graphical user interfaces are two dimensional, and when we add in this dimension of time, animated GeoEyes, are three-dimensional. We always have to ask ourselves the question, even if they''re technically accessible, conceptually is it going to work? We ask the question, could I find what just changed if I couldn''t see? If I click on something and it causes something else to happen on the page. For a screen reader user, if Ive already read past that portion of the page, I might not ever think to read back and say, oh hey, the whole top section of this page has changed because I just clicked something down below. So, the question is, could I find what happened - could I find what changed if I couldnt see it? And thats a very difficult conceptual issue to deal with and thats true actually in complex HTML forms as well, dynamic HTML forms. So, in practice, I think the unfortunate reality is except for the simplest examples, making Flash interfaces accessible is very difficult at best. We will keep looking for examples of where it is done. The -- I am afraid what we''re finding at this point is that there is so much extra work that goes into doing it, that we really just need to reconsider whether it is worth the effort to do this. So, again, Adobe has done the right thing. They''ve built in the information and revealed it through Microsoft accessibility and unfortunately in practice with modern screen readers, with current screen readers, its just not getting the job done. If we do want to make Flash interfaces, the best practices are to keep it simple and then just recognize that you''re going to have to test it with a screen reader. No matter what you''ve done, you''ve done everything the right way, the reality is, is we don''t know how a screen reader is going to react until we try it. So, if you do build Flash interfaces, plan to test with all the screen readers that might be being used by the people in your audience. And I see Participant had asked a question earlier that I think is related to that. He said: If I understand correctly, Adobe has done everything right, and the problem is with MSAA not revealing the appropriate information to the screen reader. Rather than staying away from the techniques you just described, wouldnt it make more sense to use those descriptions anyway, so that when MSAA finally gets it right we wouldn''t have to retrofit. It is a good question and its a very difficult question. I think you''re essentially right. I think in this case even MSAA is doing the right thing but the screen readers are not. They are either intentionally not always picking up on the information revealed by MSAA, and that''s my suspicion. And in the Jaws case or Window-Eyes case where it is more intermittent behavior, there may be some technical issues that are interfering with it. Certainly it makes sense to do things the right way. And we''re constantly balancing doing things the right way, but then also recognizing what is the real world impact of this. So, yeah, absolutely we should do things the right way so that somewhere down the road hopefully things will get better, but we need to also recognize that that may impact -maybe that today we have to provide an alternative to a Flash interface because even though we''ve done things the right way, it might not get the job done. And Participant asked a question: Is MSSA a cross platform? No. MSAA is Windows only, and it may even be Internet Explorer only. I think there has been some talk of Firefox supporting MSAA, but I am not positive about that. To be safe, absolutely MSAA is Windows only, and to be safe I will say it is Internet Explorer only, although that may be changing. So, Flash accessibility in other operating systems is a whole other can of worms, and it is going to be probably even more problematic than what we''re seeing in Windows, unfortunately. Well, before I run us out of time here, let me run into one of the most exciting areas, and that is Flash video. When we''re talking about Flash video we''re talking really about audio video, something to record off a camcorder or capture live from the screen of your computer. We''re talking about having audio to go with it, so it is really multi-media, and specifically we''re talking about the, really, industry-leading Flash video, FLD and F4V video formats which are all over the web, YouTube and Google videos and you name it, just about everything is Flash video any more, primarily because it is so cross platform and relatively easy to include. Definitely it is the leading format out there, and the good news is we can do a lot better than we can with the other areas of Flash accessibility. So, just to jump into this one fairly quickly, the issues we want to deal with in looking at Flash video, number one, we need to realize that Flash video consists of two parts, the video itself and the playback controls, the play button, the pause button, the closed caption button and so forth. So weve got really three major issues. One, are the playback controls keyboard operable? Are the playback controls compatible with screen readers? And lastly the video itself, if --since there is audio in it, by out definition here, do we have a way of providing captioning? And Im excited to say the answer to those three questions is -- seems to be, yes. First technique we''ll talk about here, use the Flash CS4 playback controls, the skins, the play button and so forth that you can slap onto a video. The playback controls that are included in CS4, and I don''t believe this is true of earlier versions, but in CS4 these skins are both keyboard optimal and screen reader compatible. Weve tested it with a variety of tools, they seem to be working very reliably and consistently, and hopefully we won''t get surprised on that one, but the good news is that the built in controls, the built in playback controls seem to be working well. Also, most --some of the built in playback controls have options to have the captioning button built right in. So I would certainly recommend using the built in controls that have captions available and we''ll talk a little bit more about that in just one second. That little image that we have here is the skin selector, and that drop down list for skins there, there is five or six dozen choices there, and you can pick different colors and different combinations of buttons, and so forth, and they seem to all be working well. Secondly, use the FLV playback captioning component. This is a component that is built into Flash, kind of like how we saw the user interface components, shows up in the component panel, and it is a control that is designed to work with the FLV playback component which is the one that shows your video and applies the skin to it. And basically all you need to do is drag this component out of the panel, slap it on the screen and you''re ready to attach external captions. We see the little image here of the component inspector, it shows us the properties of this component and the important one here is the one at the bottom, source, and we''re pointing to actually an XML file that is sitting next to my Flash movie and in the directory that Im inserting it from. But this is a very, very big step forward for captioning. Used to be that we could manually put captions in by putting text on the screen and changing it over time, and it was a real chore, and if you discovered that you transcribed something wrong, got the wrong word somewhere, it meant going back into your Flash movie file, fixing it, recompiling it, republishing it. By using the FLV playback captioning component we can point to an external XML file. You find it there, go on edit the file and you don''t have touch the Flash video. So it is very powerful, very reusable and efficient way of doing things and also uses an industry standard format called time text or DSXP which also is another big plus because it is an industry standard. Because it is industry standard there are some emerging, some interesting tools that allow us to create the caption files. One with a funny name but a very effective function that we''ve run across is called Subtitle Horse at subtitle-horse.org. It is a free Web-based service that produces time text captions, as well as some captions in some other formats including SRT which is the format that YouTube uses for subtitles. And Im just going to show a couple of screen shots and Ill leave it to you to go and explore that a little bit. Here is a screen shot of the movie that we saw in the earlier example, basically you point Subtitle Horse to your movie, and it will play the movie, give you down below -its hard to see in this picture- but down below it are the times stamp as the movie is playing, you pause the movie, you listen to it what it is saying, you pause the movie, you type in or paste in the appropriate caption, click create, and then it creates what''s shown on the right side of the screen just basically a running list from two seconds to four seconds show this line, from five seconds to six seconds, show this line, and it creates the whole synchronized caption. And in the next screen I will show here real quickly is the export screen, so once you''re done, you pick what you want to export to, Ive got time text which is the format that Flash uses, it creates the XML file. I save that to my drive, and I point my FLV playback component to it, and I have captions. If you''re interested, wont do it now for a second time, but if you''re interested, go back to the original example, hit play on that and make sure to turn on the little closed caption button in the right and you will see how the captions work there. Again, it is an XML file that is very easy to create and maintain. Subtitle Horse is a neat, free, web-based tool that does the job. There are some other tools out there. MAGpie is kind of the old stand by, its a good tool, its a little bit hard -its a Java based tool- its a little bit hard to install and get it working, but it is a good tool and it is free. Caption aid is a commercial product; I think its $60 for a single license that is a very effective tool. High captions by High Software is a slightly older commercial tool that is also more expensive, but youve got some options, but certainly play with Subtitle Horse and see if that doesn''t do the job for you. In summary, Flash video good news, the CS4 playback controls are accessible. The playback captioning component makes attaching caption says easy, and weve got some free tools to help us create the captions. So, on the Flash video front, Adobe has made tremendous progress and were really excited to see what''s happening there. I have a question: Can you point the Flash file to multiple caption XML files, i.e. an English file and a Spanish file? That is a good question that I don''t know the answer to. In that component inspector there is only a place to put one there, a single file, but again I apologize I don''t know the answer to that one, but it seems like its reasonable. I am not sure if the tool is that sophisticated yet. We''ll have to leave that up to you to research that one. So, I see weve got just a few minutes left here. I do want to talk about a few special topics and just save a few minutes for some more questions at the end. So the things we''ve been looking at so far are techniques that are available within the Flash CS4 professional authoring tool. That is the main tool thats used when youre creating Flash, but there are a couple of other tools out there that can also create Flash-based movies or interfaces for the web, and I want to take just a real quick look at two of those files, two of those softwares, both from Adobe. First one I want to mention here is Adobe Captivate. Adobe captivate is a tool that specifically targeted to create Flash-based E-learning presentations, and particularly unlike Flash Professional which is a very technical tool, and I am writing action script and so on and so forth, Captivate is aimed at the non-technical user. Its aimed at trainers who develop E-learning presentation content, so it is a -- simple is maybe not the right word, but its a less technical interface and you don''t have to get into dealing with scripting code and what not. Its also, actually Captivate is an evolution of a tool called RoboDemo if any of you remember that one, but from that tool it inherited a very powerful screen recording feature which has enabled both to-- basically its to be used for doing training of software. So basically I bring up a piece of software on the screen, I turn on the screen recorder, I walk through, you know, here is how you open such and such a menu, heres how you enter such an such a field, and it is able to record both what''s happening on the screen, what''s happening -- what I am saying, in the microphone, and it puts those together in a very efficient way. It will use Flash animation when it can to keep the file size down and it will automatically switch to full motion recording when it needs to, to capture things like scrolling or dragging and dropping. Very powerful screen recording tool. It also has a top notch closed captioning tool on it. It is actuallywere hoping one of these days we will see the Captivate closed captioning tool built into Flash. Let''s take a quick look. I got some screen shots here that captivate desktop. We''re using it here to create a simple slide show for a software system called web-based application called E Cornerstone. On the left side weve got a series of slides and the center weve got kind of like PowerPoint in feel, again thinking of what audience its targeted to. It creates slide shows, and actually this screen shot here of the slide show, first page of a slide show, is actually a link to a slide show, and I am going to go ahead and fire it up. So you should see -- it may take a minute to load on your screen here. But you should see after the loading progress bar goes away, screen says agency business hours and the continue button. I can''t click the continue button for you, but if you want to click the continue button, you will get a little taste of what a captivate presentation is like. Basically, Ive got a screen here with a button, I can click it, use the keyboard to activate it. On the second page I have some narration. I don''t know if you can hear it over my microphone or not. I will leave it to you to explore this since we''re short on time here. It can have narration and the next slide; if you click continue again, you will see the beginning of a full motion recording. So, I am going to go back and get back to the slide show. Back to the slide show, you should be seeing the slide show now. You can feel free to explore that Captivate presentation; Ill leave that example up. You can''t hear me? Clicking? I am going to turn my microphone on and on. Is that better? Alright, I wonder...maybe it had something to do with the Flash, who knows? Ok, but moving on, the thing I do want to show you here is we have a screen shot of the closed captioning tool thats built in to Captivate. And again, this is about the best captioning tool we''ve run across, and since Adobe knows how to do it here, we''re hoping that well see it in other Adobe products as well. Basically, it shows me the wave form of the sound file, so I get a little indicator - you know, I can kind of visually track where I am, it allows me to play the sound file -kind of like Subtitle Horse did- allows me to play it and the neat thing is rather than having to pause it and type stuff in, the little one and two indicators that are above the wave form, I can click there, put in my sound file and then I can drag those back and forth. So, if I dont and one of the hardest things in making the captioning files is getting the time just right; Youre always -- if you''re a little bit slow on the click and you get in the wrong place, well with this tool when you do that, all you need to do to get it in the right place is drag it forward, drag it back backwards. We will point out that none of these captioning tools have the magic that we hope we have someday and that is the ability to listen to a presentation and automatically caption it for us. Interestingly in Adobe''s Creative Suite 4 there is a tool called sound booth that''s included, and one of its features is the ability to do just that. However, in our experiments with it we are getting something around the range of 20% accuracy, so it is not to the point yet where, at least for general use, it is not worth the trouble of doing it. One thing I will point out, that if when we''re doing captioning, you either are going to do a lot of typing, or what we recommend and we do training for Captivate users, is most of these presentations start with a written out script. Any good trainer is going to know that youve got to write a script before you walk through a program and narrate it. If you can save that script, the process of doing captioning becomes a copy and paste process rather than a franticly typing process, and it makes everything a whole lot easier. So, if you can save or get the script that was used in creating the presentation, you can just copy and paste that into the right points on the timeline. So, bottom line, Captivate has some very neat tools that are designed -- create Flash-based presentations. I will say in practice, again, all is not rosy. There are a whole bunch of - in the documentation, theres a whole bunch of information about the accessibility features in Captivate. Unfortunately, a whole bunch of them are broken. For example, there is no way to use simulations, theres no way to use the built-in quiz questions. However, enough of the things do work that we''re able to make effective presentations, and it is still far better than any other tool weve used down that road. If you are interested in using Captivate weve actually, based on the course that we''ve done, we started to write up the techniques and how to use Captivate, make it accessible. Ill jump real quick to this page, weve got a write up here of basically what you can and can''t do. In the center of this page weve got a whole list of the major Captivate objects, which ones do work, what you need to do it, from the accessibility standpoint, what you need to do to make sure they are accessible, which ones are a little bit tricky and which ones just appear to not being able to be used. So, if you''re interested in Captivate, weve got that information. Weve also got an involving Best Practices on how to put together a presentation that goes along with the training that we did for a training organization here in Illinois. The last thing I wanted to mention here, another development tool that creates -- designed to create --uh-oh, clicking gone? Clicking gone? Ok good. The last tool I want to mention is Adobe Flex. I will be honest that we have just really scratched the surface with Adobe Flex. Flex is designed as an integrated development environment for Flash-based rich internet applications. It is designed to build interface. The exciting news is that the documentation is very enthusiastic about claiming that Adobe Flex supports accessibility, they say that there are 28 accessible interface components built right in. We saw that there were a little more than half a dozen in Flash, and we''re talking about things like sliders and progress bars and whatnot, and Adobe indicates that 28 of them are accessible. There are actually custom Jaws scripts that are available from Adobe. Theyre actually developed by SSB Technologies to make Flex work with Jaws. In practice, again, we just started dabbling with Flex, and there are some examples out there on the web...theres some examples out there on the web specifically theres one called Tour de Flex. None of the examples weve had opportunity to play with are working with Jaws. It might be the problem that we''re using Jaws 10 and the scripts were written before Jaws 10 was out. I will say that its slightly concerning that they are relying on additional scripts. We''ve had some experience with that with some custom systems developed for the state of Illinois where we had developed scripts, and there is a huge problem in making sure that the users have the right scripts and getting them installed the right away, and then in keeping them updated. And I think that part of the problem we may be having is that the scripts, although they claim on the site to be for Jaws 8 and higher, they were released back in February of ''08 which was before Jaws 10 was available. So, and unfortunately the scripts were provided in a way that its hard to reverse engineer them to tell -- to try to tell whether they''re going to work or if they don''t work, what needs to be done to keep them up to date. So, interesting, its interesting that Adobe is really pushing the angle to Flex. Were going to wait until we see some proof that it actually works, but it is something that may be on the horizon. So, to wrap it up, just want to point out, there are some good resources out there. Again, Adobe has a lot of documentation at the Flash accessibility site. You see the link here. I am going to click on that link just real quick. And I want to point out there is a trend that we have noticed in some of the Adobe documentation. It is very, very useful stuff, and I dont -- and I want to give them credit for putting it out there. It does appear, however, that often the documentation, when new versions of the products come out, the documentation often gets updated simply by replacing the old name with the new name. We had this problem with the Captivate documentation that a number of the things that appeared to work, from an accessibility standpoint, in Captivate 2, and then the Captivate 3 documentation basically said the same thing, but it no longer worked in Captivate 3. It appeared that the documentation was updated but just by replacing the version numbers. And its a little bit hard to tell, suspicious of that in some of Flash related documentation, it seems to be talking about older versions of Flash. We''re still trying to figure that out. This is the main, central site for Flash related documentation and I certainly encourage you to become familiar with it. And then weve also got links here to MSF&W our own company''s techniques, including that Captivate technique and we''ll certainly be writing a Flash technique to go along with that. And of course the Great Lakes ADA Center, which is a wealth of resources. So, with that I think I have covered everything that I wanted to get through, and I see weve got some questions here. Ok, [Callers] question from earlier: What about using Flash for a site link menu if the work around is used? If Im understanding you right, we''re talking about, what about making the dropdown menu to navigate the site, doing that in Flash, but then using the W mode work around to make that invisible in providing the alternate content within the object. I think in theory, if Im understanding it right [Caller], in theory that is a -- sounds like a workable solution. The only caution Id throw out there is because again, I havent been able to confirm that the W mode, transparent and opaque, making the object invisible - I don''t know if that''s on purpose or not. So, my only fear would be that could go away. So its just something to be aware of. Not - [Caller] clarifies, not a dropdown but a series of buttons. Sure, whether its dropdowns or buttons, whatever. If its a Flash interface, an approach that could work would be whatever the Flash interface is, set the W mode so that the fall back content is revealed to screen reader users. In theory it sounds good. You want to be careful of maybe something getting fixed, and the alternate content not showing up. Probably something that, again, as we talked about in interface, is, one of the rules is: plan to test. So, I think its a good concept, and I would certainly test it thoroughly to make sure it works, but it sounds like it could be a reasonable approach. Any other questions? And if you want to raise your hand I can give you microphone control as well, or if its just easier to type, thatll work too... Ok, well, I appreciate everybody hanging with us for an hour-and-a-half here. I didnt --wasn''t sure I was going to be able to fill the time. Here is a question that came up: Have you had any experience with Flash Chat Widgets? You know, we haven''t. We haven''t worked with Chat Widgets. I would expect that the same interface issues are going to apply, plus we have kind of the conceptual issue of timing. Typically, weve got a screen, well, like we have here, a screen where weve got a rolling record of what''s being chatted, and I then Ive got a separate box where I have to type stuff, and the challenge in general for chat applications is, when the screen reader users focus is in the typing area, they then have to some way -- get their focus back up to the chat log area in order to see what the response is. So that, conceptually, presents a challenge of how does the user going to ask that question? Would a user know that something has changed? In this case its even tougher because things are changing. The user on the screen reader end is not necessarily even doing an action, its something that is happening externally. So the trick would be -- the question asked would be: how would the screen reader, one, know that a new message has appeared? And two: how would they get their focus out there to read it. Clearly in that case they wouldn''t want to read the whole transcript again but read just the last one. So, no, I haven''t worked with Chat Widget directly, but probably its going to be a challenging one. Itd be interesting to see if anybody has examples that we might look at and see if we couldn''t make them accessible. So, thank you, [Caller]. I hope that was an okay answer there. Well, weve got one more minute for questions. Janet, were you raising your hand? Ok, heres the microphone Jan.
Im going to give people just another second for questions. So, Im not trying to cut it off early, but I am going to put up the evaluation in the chat area, and you can go ahead and click on that straight from the chat area and fill out the evaluation when you''re done with the session. And as I mentioned, this will be archived, and I will send out that information as soon as the archive is available. Mike, I think this was very informative, and if theres any last questions...? I don''t think there are, so I want to thank you on behalf of the Great Lakes ADA Center and thank you to the participants for the great questions. I think this was useful. Thanks.
Thanks, Janet. Thanks, everyone, for participating.