Transcript of Webcast: Web Accessibility for Community Colleges: Part 2--April 19, 2005

Presented by Paul Bohman of WebAIM

Sponsored by the Great Plains ADA & IT Center

Pamela Cress: Welcome to Web Accessibility for Community Colleges Part 2. I'm Pamela Cress, with the Great Plains ADA and IT Center, the sponsor of this webcast. I would like to begin by thanking the University of Kansas Continuing Education staff for managing the technical aspects of the webcast. If you have any technical problems during the webcast, please contact them at the email address or phone number found on the webcast page.

The audio file and transcription of the program will be archived at our website if you wish to review the program or if you know somebody who was not able to join us today. Also on that website is an on-line evaluation form. At the conclusion of the program, please take a moment or two to complete this form. We'll use that information to help us schedule and plan for additional webcasts.

I would like to introduce you to our speakers today, Paul Bohman and Jared Smith. These gentlemen are from the WebAIM project at Utah State University and are experts in web accessibility issues. If you have questions during the webcast, about the information that they're sharing with you, you can email Paul Bohman by clicking on the link that is on the webcast page.

So, since we only have an hour, I'm going to turn this over to Paul and Jared and let them share their information with you.

Paul Bohman: I'm glad to be here with you for this next hour. I have been with the WebAIM project for six years now and not too long ago I gave another broadcast, an introduction to web accessibility for community colleges and went over some of the basics for web accessibility.

I introduced you to the issues regarding disability types and some of the basic things to keep in mind in terms of web accessibility. Because today's broadcast goes into more detail, it will be a little more technical than the previous broadcast, but at the same time I'll try to keep it on a level that will make sense for a broad audience. I also have Jared Smith with me and I will let him say a few words about him self.

Jared Smith: I have been with the WebAIM project for four years, my background is in education and I guess through my education there and continuing education, I really began to realize both the power of the web, and the inability some individuals with disabilities have in being able to access that power of the Internet. I’m really interested in this and I'm excited to be able to be on this webcast with you today.

Paul Bohman: For those of you who did not tune into the previous broadcast, we're not going to review everything we talked about, but the archives are available on the website. I'm going to start from a pretty basic perspective and for those who still have a web browser open, you can follow along with some of the notes that I've prepared for this webcast.

On the same page where you clicked to access the audio stream, if you go further down, or at the top, they have a link that says support materials. You can click on that. The first heading I'll talk about is accessibility basics and the principals of accessibility. This is a working draft of web content accessibility guidelines. Version 2. So this is not an official document, but the concepts they have outlined I think are very helpful for web developers to understand the reasons behind web accessibility.

The first of these principals is perceivable. What that means in this context is that the content on the web has to be as the word says perceivable by people with disabilities. That means different things to different types of disabilities. Someone who is blind, obviously cannot use the eyes to perceive the content, they will use generally a screen reader, which is a piece of software that converts text into voice output. So in this context, making something perceivable to someone who is blind means putting it in a text format so that their software can convert it into sounds.

For someone who is deaf, it's a different situation. Where you have say multi media or video or audio, anything that contains an audio component, that would not be perceivable to the ears for someone who is deaf, so you provide a transcript or provide captioning as we are doing in this webcast. In order to understand it, which is one of the other concepts, first you have to be able to perceive it.

The second one, operable, deals with the idea of being able to make it work. So once you perceived it, you have to then be able to interact with it. For example, if you're someone who cannot use the mouse, perhaps you have a motor disability or you don't have use of the hands, or you're blind and have no use for a mouse and you're using the keyboard instead, web content has to be operable by the keyboard and not just by the mouse.

The third example, understandable, is across the board for all disability types. Beyond being able to just know that something is there, which is perceivable, being able to interact with it, which is operable, you want to get to the point where the content is actually understandable and makes sense. Now for someone with a reading disorder or with a cognitive disability, understandability is a big issue. Even people who do not have cognitive disabilities or reading disorders or other abilities or disabilities that effect the mind, you can still have understandability problems. Someone who is blind, if you have content that is presented in an order that is not logical, even if it's perceivable and you can interact with it so it's operable, if it's not in logical order you won't be able to understand it. There is an example here.

The last category is robust. Generally, this refers to the idea of making the content work across browsers, across platforms, if you're using Windows, Windows-based computer with Internet Explorer. A web page will work in that technology and it would also work in say a Macintosh, using Linux, make it as robust as possible, across technologies and this generally means some forward and some backward compatibility. This way it doesn't fail completely, but it may not look exactly how you intended it to look in the older browser, but the content will still be there. Sometimes they refer to this as degrading gracefully. So that is the backward compatibility.

The forward component means you're putting the mark-up together based on standards so that you're not relying on some of the quirks in browsers, and there are plenty of them, to convey content or to render it the way you were hoping. So standards based design is one of the key concepts. In addition, in the robust category, you want to make sure that for example, if someone commits an error as they submit a form, misspell their own name or put in a wrong phone number and hit the submit button, make sure there is some sort of error recovery mechanism. Make the application itself robust and I’m not just talking about technology, but the whole interaction with the computer and with the web content should be robust.

So those are the basic principals, and to run down the types of disabilities, the general categories are:

Number one: visual, which includes blindness, low vision, color blindness.

Number two: motor disabilities

Number three: hearing

Number four: cognitive

Number five: seizure disorders. If you build in a strobing or flickering effect, it might cause a seizure.

There is a bit of review of some of the basic concepts and those are important to keep in mind as we go through some of the details and techniques.

I’m going to refer a little more now to the notes that I have in the list of resources. There are plenty of resources on the WebAIM site, www.WebAIM.org. One of them is a video that talks about the different disability types. Going down to number 2 in the list of notes, Planning Evaluation and Retrofitting. This is one of the areas that often gets neglected when people talk about web accessibility. It's one thing to be able to say that you're going in and creating fixes for errors and accessibility and quite another thing to say that you planned it ahead of time. The key really to an effective long-term strategy is to plan ahead and put the effort in to begin with rather than take alternative approaches, which might be to bolt it on afterwards, to use that metaphor. It’s easier to do it up front.

To use an analogy, a lot of times the type of fixes that people will put in after the fact, after the website is created, are similar to saying, “Well I'm going to go ahead and build a house and then I'll worry about whether the doors are wide enough to get a wheelchair in or whether the hallway is wide enough to get a wheelchair through.” Once you built the house and then say, “Okay now it's time to fix it for accessibility,” then you have to widen the doorways and hallways and make accommodations that would be unnecessary if you had planned for it in the beginning.

That is the overall approach that I hope to convey to you. Now we'll go into some of the tools that are used to evaluate for web accessibility. The first one that I'm going to talk about is called Wave 3.5. There is a link to this tool on the website. This is a tool that WebAIM has been working on and it was originally developed at Temple University. The purpose of this particular evaluation tool is to help developers see where the errors are in the context of where they occur and to identify some of the possible areas where there may be errors or may not be.

Kind of an interesting statement. Obviously if you have an image that doesn't have alternative text, that will be bad for someone who uses a screen reader. They depend on alternative text to understand the image. But, beyond that, you have the problem of making sure that the alternative text is appropriate, accurate, that it's concise. Those are three keys to making good alternative text, appropriate, accurate, and concise. Wave has a few checks to allow you to flag suspicious alternative text. It won't flag every suspicious text, but if you put in phrases like image of and then fill in the blank, what ever it happens to be, this would be flagged as suspicious alternative text because scan readers notify the user this is an image.

That is being redundant. If you have the file name of an image, that would be an example of suspicious alternative text because the file name doesn't contain much information. Wave will flag some of those. The idea behind Wave is it inserts icons that have specific meaning in the places where the errors occur. Some of these icons are red, some yellow, some are green. And the color-codes for errors, possible errors and accessibility features.

And for those of you who may be wondering, yes, there is a way to tell for those who are blind, which ones are the errors, possible errors and features, besides color. That is an important concept, too. You don't want to just use color to convey meaning, so we have the colors, plus we have the alternative text for the graphics that convey the meaning.

There are other tools as well. One of them is the W3C HTML validator. This tool tells you whether or not your HTML markup is up to standards, if it complies with HTML 4.0 or whatever the version of HTML happens to be that you're using. And you may be wondering what does that have to be or what does that have to do with accessibility? As it turns out, one of the requirements for passing a validator for HTML is to have alternative text for the images. That is one of many different accessibility requirements, but it is an important one and if you are making sure that your code is accurate and that it passes the validator, you're also paying some attention to accessibility issues.

Now beyond that, some of the tools that people with disabilities use to access the web require code that is accurate. So for example, if you have poor HTML markup that doesn't meet the standard, the tools that people with disabilities use may or may not be able to interpret that correctly. Some of them will guess correctly, some of them will not.

They depend on you to have consistent and correct mark-ups.

A couple of the other tools that I have in the list. Firefox developer’s tool bar, which I find valuable. If you're developing for the Firefox browser, the developers tool bar is a component that you can download for that browser and I won't go into detail, but it will give a lot of information on the mechanics of the web design and allows you to turn images off, turn styles off, and it really gives you some nice manipulation tools to find out what some of the errors are.

Jared Smith: I was going to add a quick comment in regard to HTML validation and insuring your standards comply. For those of you that are developers, if you have not made an effort to be standards compliant with the HTML establish cards, you might be surprised by the feedback you get from the validator. It might be overwhelming, mostly because the tools you're using to develop the pages probably do not support the standard. As a developer, I would strongly encourage you, even though it may not have a great impact on accessibility, I give you the challenge to insure your web pages are compliant with the standards. And what you will find is that makes your job easier as a developer. As Paul talked about some of the issues being robust and operable across platforms, you'll find HTML compliance solves a lot of those problems, especially across browser compatibility, across operating systems, as well as compatibility with emerging technology; cell phones and PDAs which require that the web content be more standard compliant. You'll find as a developer that it makes your life easier plus it supports accessibility.

Paul Bohman: I will mention one more tool. There are plenty of them out there and by mentioning only a few I'm not necessarily endorsing these; they are some of the tools that I do use personally and that is why I'm mentioning them here. Some of them are free, some you have to pay for, and it just depends what you're looking for. But the one final tool I will mention is the AIS Accessibility toolbar, which is developed by a group in Australia. They have put together a combination of a lot of these tools. For example, references to Wave and references to Bobby, and several other tools are available from this one tool bar. And I think it's worth looking into. That one works with Internet Explorer.

Okay, I’m going to go down to Roman numeral 3 in my list to techniques and images, and I've mentioned a few things providing alternative text for images is the key, the basic part if you haven't done that, you haven't done the bare minimum for accessibility, making images accessible, there is more to it than alternative text. Number one in the list, use graphics to enhance comprehension. A lot of times people have the misconception graphics are a barrier to accessibility, because a blind person can't see a graphic, so that would be a problem, right? Well, sort of, yes, but mostly no.

You can put in alternative text for images. The blind person can access at least the meaning of the image as determined by the content author, through that alternative text. It's a matter of then making sure that the alternative text itself is meaningful, and then beyond that, you can add as many graphics, illustrations or whatever that you need to increase the accessibility in a different way. Going back to those that have cognitive disabilities and reading disorders, they will probably have a difficult time accessing a page that is text only. Kind of the opposite problem of someone who is blind. But, because you can put the alternative text in, you can use the same version of a web page to accommodate a blind person and the person with the reading disorder. By providing illustrations, you give the visual aspect to someone with a reading disorder and by providing the alternative text you give the blind person the benefit from the description of the image.

The second part, again in graphics, this is to insure sufficient contrast. And by that, we're talking about if you have an image that is done in low-key colors, someone with low vision can see the image but not perhaps very well. If you provide enough contrast in the image, they will probably be able to see the image better.

Number three, limit or avoid text within graphics. What this is referring to is when you have a regular text heading, you might decide to create a heading using a specific font to make it look fancier, but when you enlarge that, what you find is it becomes blurrier or more pixilated. Someone with low vision that would be using a screen enlarger may have a difficult time understanding what the text says because of the nature of the enlarged images.

By contrast, use real text, then it will enlarge well and the person with low vision will have less difficulty reading that text. Going down the list, avoid strobing effects. Someone with a seizure disorder, for instance photo epilepsy, might come across a strobing effect; you may be responsible for causing a seizure in some of the people. It is rare, but it can happen, so it is something to be aware of.

Now we come to the one that is usually the first one on most people's list, that is add accurate, concise alternative text. You don't want to overload people who use screen readers with all kinds of descriptions. They say a picture is worth 1000 words and that is true, probably even more. But if you go on for 1000 words, you've probably described way too much about the image. Describe the important parts and move on, let the screen reader user move on as well. Then finally, if you have an image that does require a really long description because it has complex information such as a graph or chart, or a map or something along those lines, you might be able to, you might need to provide a link to a long description. All the specific information on this is located on our website under our tutorial for accessible images. Images are important in terms of accessibility. I don't want to give the message you should leave them off, you should include as many images as you can and provide good alternative text as necessary.

Moving down the list to tables, there are two different types of tables, one of them is the layout table, and the other kind is the data table. With layout tables, the truth is they were never designed to be layout tables. Having said that, the impact of using a table for layout is relatively low in terms of accessibility for the most part. The only thing you have to keep in mind in terms of accessibility is the reading order of the table, and if you use Wave, you can have it print out the reading order of the table as well.

Another way to look at it is if you go in the HTML mark up you will see the order of the words in that mark up. If you ignore all the code, the pointy brackets, if you ignore those, that is the literal reading order the scan reader will access the content. That is an important point. The code is the order the screen reader reads the content. So, if when you evaluate the reading order you find that it makes sense if you were to listen to this, without having the opportunity to see it, you want to make sure that it makes sense.

Okay, when you get into data tables, it becomes more complex. What you have with the data table is some cells that are used as headers for rows or columns, and then you have a matrix of data cells referenced by those header cells. For example, if you have information in a grid with headers on the top and headers on the side, then every cell within the middle is referenced by the header cells. And visually you can see that quite easily. If you're listening to it, then there are some potential difficulties. The first one being that there is no obvious link between the data cells and header cells because what the screen reader does is read right linear order as if there were no table structure.

The data cells are the code. The code for table data, <td>, for table headers is <th>. You convert the ones that are supposed to be used as headers into <th> and then you link them, for example, to the code that says ph, then a space and then you say scope equals if it's for a column, col, or scope equals row. It’s a little hard to explain in an audio format, which is what we're doing at the moment, but there is more detail on the website tutorial on exactly how to do that.

Now, there are other ways of doing that that can be used with more sophisticated tables. If you have multiple layers of headers or you have a couple headers at the top and a column headers below that, and data, then use a different method, and again that is explained in more detail in the tutorial.

Jared Smith: Just to interrupt, what that does is allow someone using the screen reader to at any point when they're in this jumble of data in this complex table, to either hit navigate through the table and have the screen reader identify for them what the headers are, so for instance, this is the first day of Jared Smith, this is what this data means. The screen reader can associate a piece of data with the appropriate headers. Not only does the table data associate it but it allows the technology of the screen readers to identify what those associations are at any time.

Paul Bohman: Right. So what in effect it's achieving is the same thing that is already achieved by visual users. The whole purpose of the table is to put the data in a visual format. So, if you think about it, data tables have no meaning what so ever for someone who can't see them, but visually it helps to organize content. What we're doing by providing the headers is making up for the fact that we have used a visual metaphor for displaying data and allowing them to hear how that data has been associated with the proper headings or headers.

Now moving on to the next one, we're getting into forms. The concepts behind these are simple. The actual process can be a little more complicated than that, but let's start with the simple part first. The basic concept is that every form element when you're inputting text or when you're choosing between options such as check box or radio buttons, you want to make sure every one of those options has a label. Now most people simply put text next to the form element and use that text as a label. For example if you fill out a form with your name and address and phone number, then in the first field it might say first name, then a place to type your first name, and last name, place to type in and so on. Those are labels; the problem is that they're not associated with the form elements unless you explicitly associate them. And the way you do that is to use the label tag or the label element. These get wrapped around the text, so again to use that example, if you have last name, you put those words last name, inside the label tag, and then you associate that label text or that label tag with the form element. The way you do that is by giving the form element an id. You then link that id to the form label. This is explained in the tutorial with examples.

Again, from the screen reader perspective, if you're listening to a form, it's all presented linearly, so if you have a whole bunch of form elements, the screen reader may or may not be able to associate the text with the form element appropriately. If you only have one form element, it might be obvious. But at the same time, most forms aren't built that way. Most have more than one element which creates the possibility that the user could get confused as to which label belongs to which form element.

So when you listen to the screen reader, if you have used the form or the label tag, then the screen reader will tell you here is an input and here is the label that goes with this input and the user will be able to know what data they need to put into that form. The same concept applies whether you're inputting free form information such as a first name or address, or if you're choosing between various options such as check box or a drop down list or radio button, or whether typing in a whole paragraph as with a text area, all of these elements need form labels.

To take form accessibility further, one of the keys is to make sure the forms are also keyboard accessible. Some of you may already know how to tab through a form and enter in the information. Some of you may never have even tried; you may have been using your mouse only. Not everyone can do that, though, so you want to make sure you can tab from form element to form element. This way the form is keyboard accessible from start to finish.

One of the problems that can come up with forms that can ruin the keyboard accessibility is if you have what we call jump menus. These are drop down lists that are scripted, using JavaScripts to take you to a different page as soon as you select something. Now these drop down jump menus work just fine if you're using a mouse because you click on the form element, it shows you the drop down list, you select an item and it goes to the next page. However, if you're using the keyboard, it's not that simple. You can tab into that form element, but as soon as you use the up or down arrows, to select the options, the way that the form elements are scripted it will go to the first thing that you selected. Even if you didn't mean to select it. Just as you're going through from option to option, it will assume that you meant to choose those options. And it will jump you to the first one as opposed say the third one, if the third one is what you wanted, that is too bad, you went to the first one. So you want to make sure you don't use these techniques that ruin the keyboard accessibility component.

Jared Smith: One thing I would add is that a screen reader user or someone using a keyboard isn't necessarily, a screen reader user, we have the luxury of being able to see a text element and see the label that is next to it, for example first name or last name. As the screen reader user is navigating through the page, they're going to hit the tab key to navigate. When the screen reader reaches the text box, it will not have read first name. It skipped over the text that happens to be next to the form element. So for instance if they were navigating through a page that did not have labels, the screen reader would say something like text box, text box, radio button, form menu button, something along those lines, whereas having the labels they can navigate through the form elements and have the label read and identified with those elements, for instance text box, first name, to indicate what that is. So it's beneficial when they're navigating through the form area of a web page.

Paul Bohman: I have a question from one of our participants. I'll read the email. “One thing that is not on your notes for today is a subject of skip navigation. I found people prefer invisible skip navigation links, because they don't interfere with the visual layout. Others say this isn't a good idea in terms of accessibility. What are the advantages and disadvantages of each approach?” This is a very good question. In fact, I'll start with the advantages and disadvantages of the hidden one.

The reason for a hidden box or skip navigation is to provide for people who either are using the keyboard and not the mouse, or people who are using a screen reader to skip past the tabs or navigation links, main navigation features of a web page or to up jump to the main content. Visual users do this with the eyes. They can see there are links and that those links are not the main content. Their eyes focus on the main content. Skip navigation links are just simple hypertext links that take you from the top of the page further down where the content starts.

One advantage in using the invisible version of skip navigation links is that it does not ruin your layout visually, you don't have to add that text that some developers think looks ugly and add information that shouldn't be there visually and to some extent, that is a logical and correct assessment. However, it doesn't accommodate the broadest array of users. Those users who do have their vision but don't have use of their hands are probably going to be using some feature that emulates a keyboard. They may use a track ball mouse, a mouse stick or some other device that doesn't act like a keyboard. So in general, it's better to make it visible at some point. Now the reason I say at some point because one of the techniques that I tend to prefer is to have a skip navigation link that is hidden until someone tabs to it.

Now, there is a technique, which is described in an article on the WebAIM site, if you go to the WebAIM home page, www.WebAIM.org there is an article called making or hiding content from visual users but still having it be accessible, that is the gist of the title. It's a technique I used before, it's hidden until someone tabs to it and shows up and then everyone can see it's there and everyone can use it, whether they're using a screen reader or a keyboard. The advantage of that particular type of system is that beyond the fact everyone can use it, is that it doesn't confuse people who wouldn't need it. Someone who has never heard of web accessibility who does not have a clue what skip navigation links are might be confused when they see a link that says skip navigation or skip to main content, and they click on it and they won't see much of a difference. And so in some ways skip navigation links have a drawback for visual users, but by having it hidden until someone tabs to it, that allows everyone to use it even those that do have vision, and including those that use screen readers.

Jared Smith: You can see an example on our website. All the things we talked about so far today, none of them impact the visual design of your page. We found most web pages can be made accessible without changing the way they look or the way that they function because most of these things are hidden in the background. This is one of the few things in web accessibility that is going to not impact the visual and the navigation of the page, so this is a benefit to a lot of users and we highly recommend it.

Paul Bohman: One thing I'll also say is that you can provide similar functionality to screen reader users by providing headings in the document. They come with built in functionality. This is another way of accomplishing the skip navigation goal. It won't help people who use a keyboard but not a screen reader, because browsers don't have that ability built into them, but it will help people who use a screen reader. They can go directly to your h1, first heading, and then from heading to heading, getting an overview of the web page that way.

Going on to the next topic, cascading style sheets. Cascading style sheets are one of the best inventions for the web in terms of being able to make sure you can maintain the site and separate presentation from the actual semantic content. With CSS, most of it is rather neutral in terms of accessibility. You can have CSS based web pages or websites that are very accessible and ones that are very inaccessible, it's rather neutral. One of the areas where you can get into trouble with CSS is when you manipulate the visual layout in ways that make the visual order different from the underlying order in the code.

If you remember, I said that screen readers pay attention to the literal order in the code. So, if you manipulated the visual reading order by moving around the boxes of text using style sheets, what you've done is altered one method of display, the visual, but you have not altered the other method, which is the underlying code. So the way you want to get around that is to make sure that the visual presentation is in a logical order with the semantic mark-up in the HTML itself. Whatever logical happens to mean, both of them should be logical for the different users. I think that is all I'll say about CSS.

Jared will take over now and discuss a question that is related to what he will talk about next, which is JavaScript. I'll read the question and have Jared respond. “If divider tags or div tags, (div is a way of marking a section of the content, are used to hide form elements until a user clicks on a link, is this usable for screen readers? Similarly, if screen elements are drawn on the client through JavaScript, are they accessible to a screen reader?”

Jared Smith: Two very good questions and I will answer them fairly briefly. There are several methods for hiding things in HTML. The most common is using style sheets, for either visibility, or positioning elements off of the page, then moving them back on to the page using something like JavaScript.

We refer to that to dynamic HTML, a combination of cascading style sheets and JavaScript to manipulate elements on the page. A more direct answer to the question is it really depends. If you're hiding it truly from a screen reader using style sheets and clicking on a link is going to change some style sheet attribute that makes it visible or accessible to the screen reader, the biggest problem comes in how does the user know where it is, and second, how do they actually get to it from the point where they click on the link? This takes a lot of user testing.

There is a JavaScript tutorial on our website. It goes through several of these where feedback is hidden in the page until a certain JavaScript event happens and then it displays. You can look through those and remember, it will take user testing for the most part to see what works. The second question. Are screen elements drawn on the client's using JavaScript accessible to the screen reader? For the most part, yes, if you're using standard JavaScripts, most screen readers will read those. I'm assuming that the end user does have JavaScript and the JavaScript is enabled and if that is not the case, if they have a browser that doesn't have JavaScript or disabled JavaScript which a lot of users are doing for security reasons and convenience, then content will be inaccessible to everyone that fits into those conditions, not just those using screen readers.

I will, however say that most screen readers are built on to Internet explorer, which by default has JavaScript and has it enabled. The direct answer to that would be yes, the caveat would be as long as they have JavaScript and it is enabled. We have a tutorial on our website on JavaScript. For sake of time I'll move on to macromedia Flash and talk briefly about Flash.

We talked earlier about principals of accessibility and perceivable, operable, having the content be understandable and robust. When we relate that to Flash, we find that Flash uniquely meets all of those four points. Flash works the same across all plat forms, can be very universally accessible, almost everybody has the Flash player and can access the Flash player, plus the ability to present content in multiple formats and modes through audio, through visual, can make it be a great benefit to accessibility and it can do great things in regard to accessibility. However, in order for that to be realized, it has to be developed with accessibility in mind. As we mentioned a few minutes ago, most web pages can be made accessible without any great change to the functionality or visual display of the web page.

This, however, is not often the case with much of the Flash content that is out there. Most Flash content will not, cannot be made accessible to screen readers without usually fairly significant changes in functionality or presentation. The reason for that is web pages are linear, they're very static, they don't usually change over time, a screen reader can access a page and read through the text from top to bottom, left to right and get all the content. Flash is very non-linear, time-based and things change based on time or based on user interaction, it's more like a movie, more like television than it is a static page such as HTML. So because of that very nature of Flash, it sometimes is hard to make content accessible to screen readers.

So I have three recommendations or three ways in which Flash content can be made accessible to screen reader users. When we look at other users, not screen reader users, all the same issues and principals we talked about with the web apply to Flash. Using contrast, insuring keyboard accessibility, using colors appropriately, and so forth. My three ways of making Flash content accessible to screen readers build into Flash the little components and codes that are needed in order to make it accessible to a screen reader. Adding alternative text images, the screen reader will read alternative text and work in the Flash file itself, so that it presents the correct information to a screen reader.

The second method is to get rid of the need for the screen reader altogether, to make the Flash content the screen reader itself. What that means is somebody could come to your Flash, a Flash movie you've developed, and all of the content is presented both visually and audible. You build audio files which describe things on the screen, describe the keyboard elements or shortcut keys that need to be used, so the screen reader user can hit pause on the screen reader and listen to your Flash movie and receive all that content. There is great power in that Flash files could be very beneficial to a lot of users. Many people are visual and some are auditory users. Presenting that content in multiple ways can be beneficial.

The third option. If neither the first two options work to make the Flash content accessible, which is going to be the case with some complex content, you can provide alternatives. Usually a web page and something that is accessible that provides the same content, graphic, colors, and other elements that are accessible. Going beyond that, inside Flash there are things you can do to make Flash accessible. There is a tutorial on our website that describes those principals and techniques that you can use.

Moving on quickly to our last point, and that is in regard to captions. We found captions help not only those that are deaf and hard of hearing, but they help everybody. And the real problem with captions are that they can be time-consuming, they can be difficult to develop and create. Whether you're talking about archive captions or real-time captioning such as what is happening with the broadcast today, and we applaud the people hosting the broadcast today for providing that real-time captioning as a service. But there are no standards, there are no guidelines for web captioning, each of the major players on the web and we talk about Windows Media Player, RealPlayer, Quicktime, Macromedia Flash as being the primary means for delivering this multi media on the web, each of them handle captions differently. But it is possible, there are tools out there that can help you out and make it very easy or easier for you to develop these captions and present them to the end user over the web. That is a brief overview on captions and I will refer you back to our website, we have specific tutorials on each of those players describing the captioning techniques and technologies.

Paul Bohman: Just to wrap-up, one thing I am going to mention is that we have in addition to our website, we're also have a training CD that is available for purchase on our website which contains actually quite a bit more detail than either what we presented here or from what is available on the website, that is an option.

We'll answer one last question that came in at the last minute. The question was whether we recommended the use of the Microsoft plug in, not created by Microsoft, for making Microsoft presentations, PowerPoint presentations and Word documents accessible. It works quite well for PowerPoint and quite poorly for Word. If PowerPoint is your main concern, I think I would recommend it. If your chief concern is Word, I would recommend not getting it.

I appreciate your attention and I'll let Pamela take over from here.

Pamela Cress: Thank you both; this has been a very, very informative hour. It seemed like it went really fast, I hope people have gotten some of their questions answered and that they all follow-up, check out the resources that you've provided to get any additional questions answered. I do want to thank Caption Services of Kansas for the excellent job that they have done in the real-time captioning today. It is not easy to keep up with this speed and content but they did a beautiful job, I thought. Again, thanks to Paul Bohman and Jared Smith.

There will be an archive version of this webcast on the website that you used to connect in the first place today. We'll also have a transcript, a text version. I would then ask that you go now to that web page, if you aren't already there, and click on the evaluation form and complete that. That would be very much appreciated. Thank you so much for joining us, bye now.