ÿş<html><body><h1>Evaluating SoftWare Accessibility: Is Anything Truly Accessible?</h1><h3>Robin Jones</h3> <p>Thank you. Welcome, everyone. First and foremost, I need to apologize for the problem we had with the call-in number today. I take 100% responsibility for that. I transposed, or I gave a 6 instead of an 8 for the call-in number, and it did not get caught until everyone was trying to call in. So I apologize for those of you who are frustrated and hopefully everyone is getting the message as my staff and staff from various other centers across the country are trying to contact people to make sure they can get in okay today. So again, I sincerely apologize for that and it is an error that I hope won''t happen again. I do welcome you to the session fully titled Evaluating Software Accessibility, Is Anything Truly Accessible? Our speaker today is Debbie Cook. I will introduce her in a minute. As you know, the session is 90 minutes in length. We will have a portion of the time spent with our speaker and that will be followed up with a question and answer period. Lamont, our operator will come on at one point and give everyone instructions on how to ask questions. This is a collaborative effort of the 10 disability and business technical assistance centers across the country also referred to as Americans with Disabilities Act (ADA) and Accessible Information Technology (IT) centers. This is our fourth year of offering these programs and I hope many of you have joined us in the past and will continue joining us again in the future. As a reminder, this session is being recorded. A recording of it will be available on our website following the session. In addition, we have real-time captioning via the Internet available during this session, which you can connect to by going to our website at www.adagreatlakes.org, and following the links for the real time captioning. Following the session, we will take that transcript, edit it and also post that. All of the transcripts of the previous sessions, as well as the recordings are archived on our website and are often found to be a valuable resource for people on a variety of different topics. This is a monthly session, which we hold on the third Tuesday of each month for 90 minutes on a variety of different topics. As I indicated, our February session is on evaluating software accessibility, an issue I know our office and many of the ADA IT centers receive questions on because one of the key issues we find is that oftentimes, the hardest thing people find is finding software that is accessible and the question being, well how do I evaluate its accessibility and what standards should it be following. So in keeping with that, we''ve asked Debra Cook to join us today to provide some of her insights, expertise and experience on this topic. She is a technical assistance coordinator for Access IT, which is the National Center on Accessible Information Technology in Education. That is a mouthful all by itself. She is nationally recognized for her expertise and leadership regarding a wide range of IT, information technology policy development and service delivery issues, including accessible design of hardware, software and web-based technologies, telecommunications product design and service delivery, laws, regulations, and best practices regarding access to IT and accommodations for people with disabilities in education and employment, and standards for provisions of assistive technology services. I have worked now with Debbie for the last couple of years through our collaboration with Access IT and have found her to be a wealth of expertise. Many of you that have joined our sessions in the past know, Debbie has presented in previous sessions on various topics around policy and policy development related to accessible information technology. So I think you''ll find her expertise and experience on this subject equally as enlightening as she has been in the past. We will have a question and answer period and ask that if you are interested in asking a question, please keep track of that, and as soon as we give instructions, get yourself in the queue so we can respond. At this time, I will turn it over to Debbie so she can share with us her expertise. Good morning on the west coast, Debbie, and thank you for joining us.</p><h3>Debbie Cook</h3> <p>Thank you, Robin, and I''m glad that everyone has made it here. We all had a little problem in the commute. I will just look at it that way. So that, we got here and a little scratch late, but we survived the commute and we are here and now we are ready to go. That is just the way life goes. I''m delighted to be here to talk to you about one of the most interesting topics that I know of, but actually also one of the most complex topics. We are even going to make this more challenging because we are doing this by teleconference. Usually when I present this topic, I use lots of overheads and I use lots of software and I use lots of other tools to demonstrate various points. So we are going to see how well, I do at describing the issues and the process to you via teleconference. So this will create an additional challenge that I think we''ll all need to rise to and may in fact impact your questions. I realize this is complex and you may find that some of the things that we talk about are difficult to understand in this context. I''ll try the best I can to make those things real clear. First of all, I want to start with a little bit of history and overview of the notion of how people have traditionally looked at accessibility of information technology products in general, and we are focused on software today by Robin''s request, but actually the process has followed fairly similar processes in terms of origin all the way across the information technology spectrum. Certainly many of you are familiar with the Federal Government Section 508 of the Work Force Investment Act which is the standard process, the law by which the Federal Government has developed standards to evaluate accessibility of information technology products. That law was derived from a variety of standards and guidelines that were in practice by other entities around the world and was brought together in terms of the components that are now part of that, and many of you are familiar with that law. I''m not going to go through that line detail, because I think there is a lot of information available about that. If you want to explore that significantly, I would encourage that you visit the Section508 website, which will provide you loads and loads of material on that. But what I want to talk about a little bit in relation to Section 508 is the processes that are used within the Federal Government, at least, to determine accessibility against those standards. And I guess I would say that obviously the first step for the Federal Government was to establish a standard at all, and one of the things that happens is that when people are looking at software accessibility, they come tome and they say I want to know if such and such a product is accessible, or can you tell me how to determine if such and such a product is accessible, and the first question that I ask is are you trying to comply with or adhere to a particular standard with respect to accessibility because if you are, we need to measure your product against that. That may not be an easy task either, but that is what we would need to do. So in the case of the Federal Government, of course they have a quick answer, which is yes, there is Section 508, but for many other entities that either is not the answer, and in some cases really should not be the answer because maybe what users need to do is not covered by that. So we''ll talk a little bit more about that later when we particularly talk about accessibility in education and that would certainly also apply in some other venues. So essentially after we then look at that, there are three basic processes that the Federal Government uses to look at this. The first one is that the Federal Government, in some cases, does their own internal testing. So some federal agencies have developed testing teams who actually sit down and go through a variety of processes with the product, you know, whether this is software or hardware or what have you, and they actually go out and they test a lot of, a lot of the processes of the product. And they usually ask a set of questions related to that and try to come up with an answer. So that would be a user side evaluation process, and that has a lot of value because you actually know yourself whether something did something. It does require a certain amount of expertise, and that process is usually implemented most effectively as a team approach where you have perhaps the expert on the application that you are testing, the expert on sort of usability by different people with disabilities and familiarity with the assistive technology that might be deployed to use the product, and that means more than just one piece of assistive technology and more than one disability group. So often that means more than one person to provide that expertise. That might be perfectly reasonable. And then it is ideal if you also have someone who is expert in the activity that needs to be performed so that they actually will be able to help you use the product correctly and demonstrate it to you correctly as you are looking for the different accessibility features. Again, in this kind of user testing, you are not looking for, does the product work specifically with this screen reading product, this screen magnifying product, this particular alternative input device, etc. What you are really trying to look for is does the product, regardless of how well it works with each individual assistive technology, does the product actually meet whatever your standard or guideline is that you''ve adopted. So that is the user end approach to testing. Another approach that the Federal Government deploys is called, using the Voluntary Product Accessibility Templates, and, or VPAT, and these are developed by industry. They are voluntary, obviously, so every industry doesn''t do it, but many industries who want to sell to the Federal Government have followed the practice of responding in a template form to the various standards that are posed in Section 508. And you''ll see examples of these at the Section508 website, and you may also find-you would find examples of these on many sites of product developers. I know that, for example, IBM uses them. Microsoft uses them. Panasonic uses them, and many others. I''m not trying to leave anybody out by only mentioning a couple of names. There a quite a few. You can see all of them linked to from the Section 508.gov website. That is industry''s perception of how well it is doing for accessibility. That is a very valuable perception to pick up, because if industry has in fact designed a feature into a product, which will contribute to its accessibility, then they are hopefully going to want to tout that and let you know that that is the case. Sometimes the industry response is what they hope will be accessible. So sometimes they''ll tell you, well, we have our material, our documentation available electronically on the web, but what they don''t tell you is that that documentation is available only in PDF and that the graphics in the PDF file are not actually accessible, that they were not provided with alternative text. So therefore, the manuals there, and you can read the words, but the words will have no meaning but the pictures are not described in the pictures. They are really part of the manual in this case. That is probably more true for hardware than software, but I did pick up apiece of software the other day that about every other phrase was look at the screen shot in figure, then they were mounting numbers to represent the different figures, and they had absolutely-you know, there was no other description of how you use this. You were supposed to look at screen shot to screen shot to screen shot. This is really a useful piece of documentation, but yes, they did in fact provide it online and they then touted that in their documentation of what they had done for accessibility. So I guess my bottom line on that one always, of course, with anything that a manufacturer of on product tells you is don''t just assume that because they say it is so, that it is. All us smart consumers who have learned things the hard way, we know that is true, but this is, again, another wonderful resource that is available. If you are in fact procuring or advising people to procure products that are accessible and if they in fact show up in this list, it will at least give you the idea that the developer is really thinking about accessibility and trying to fit their product to that. And probably honestly has done something to meet that standard to the best that they can. Sometimes meeting a standard is an evolving process because products change over time and we may want everything to be different at once and sometimes developments cycles will preclude that, but this certainly is an additional tool in addition to your user testing. In fact, it is usually the place that I start. I usually go, if I''m assuming that Section 508 might be an applicable standard whether the entity has applied it or not, I''ll start by going to these Voluntary Product Accessibility Templates to see if a developer has done one for a product. Coincidently, these are only being kind of fostered and allotted for Federal Government procurement, so therefore, I''ve not to date, and someone may be able to correct this, but I''ve not seen another entities that specifically goes out and solicits this kind of vendor feedback, or developer feedback. So if you are buying something like education software, you will probably not find those kinds of products up there because they are not generally purchased by the Federal Government. But it will still give you an idea of how those look. The third area, of course, is to employ an independent testing organization of some kind and there are a couple of those that are doing some testing for Federal Government agencies, and sometimes other people will also market themselves as independent product testers, and what I would want to know about any kind of person, or organization, that comes to sell that kind of service to you is, of course, what does their process look like, does it in fact deploy a variety of processes that would give you an across the board look at this? How do they test for standards? How do they assure things like reliability and dependability of their process and what are the qualifications of the people who are doing this? So is it going to be, is it going to look at a spectrum of accessibility features, or is it going to be more focused on, for example, accommodation needs for particular users, which again is a different issue than is the software compliant with accessibility standard. Will the third party, as part of their testing be able to test the product with various assistive technology that might be typically used with the product, because that is kind of your final acid test with what to expect in terms of accessibility. Shouldn''t be the only way that you test it, but it certainly should be included in that. So all of these different kinds of factors get deployed to one degree or another within the Federal Government. My view of the world, of course, is that if you can bring together a set of mechanisms to evaluate your products, that is probably the best. There is certainly some real value in doing some actual work around that internally. There is value in finding out what the vendor says, and if there is any third party sort of neutral information available about the accessibility of the product or concerns about the product, that is great to acquire. So that is a very good idea. Now, I want to talk a little bit about software, the process a little bit and some other entities, particularly what happens in sort of other places such as state government, education, and other kinds of places. Many states have adopted some kind of standard or guideline or policy or law. They are different; they are different in different states. I''m not going to talk about them at all in the context of this teleconference. If you would like to learn more about what has happened in the states, in particular, I would recommend that you visit the I tech website at ITTATC.org. They have quite a bit of information about state information technology accessibility and they try really hard to keep that information updated and current and they do a good job with that. So I''m not going to talk about that a lot except to point out a couple of the issues as it does impact accessibility evaluation for a product. And that is that all states have not adopted the same standardization, or the same language for their accessibility considerations. So, for example, some states have adopted language that relates to particular products. Some states have adopted language that relates to specific disability groups. The most common of those is some states that have adopted some language that they call non-visual access, and so then it actually relates to a particular group of folks. Some states have adopted a hybrid of Section 508 or Section 508 pretty literally, but at any rate, the challenge that this creates is that because everyone has not adopted the same language, there may at times be some confusion, or the potential for confusion for developers and for evaluators. What we don''t want to have occur, and what I don''t think has been occurring too much in practice, at least based on outcomes from the laws, but what we don''t want to occur is for something to qualify as accessible in one jurisdiction, whether that is a state or a school district or a city block, you know, however we are going to divide this out, and then not qualify as being accessible in another jurisdiction. So that is confusing for those of us who evaluate products and those of us who advise developers and advise different entities around software accessibility or product accessibility in general. So to know that the language varies in these things is very, very important, and basically regardless of what the language says, it is incredibly important that that process is identified for how one will actually know, you know, whether something meets the particular set of standards that you have setup, and how developers will be able to know whether they have. So, you know, clearly that is a little easier for entities that adopt Section 508 because the government, the Federal Government has done quite a bit of work that supports it. But it is a little more problematic when you adopt a different standard, and there may be very good reasons, political, practical and other why adopting a different standard might be really appropriate to do. I''m not making a critical comment about that, but I am making the comment that the more different it is, the more you''ll need to be sure and cover those issues as you work through your process. So that is another issue to consider. In education, there are fewer entities that have actually adopted a software accessibility standard. There certainly are some, in some cases the laws or policies that were adopted by states are applicable to education, but in many cases, they are not. And again, I''m not going to really spend any time here on the policy structure about that. I''ll be glad to talk about that in the questions, but the point that I think I want to make about this, that is important is that basically our problem here is again the issue of difference of definition of things, of whether things apply and whether the existing standards can even apply. For example, in education, there are issues that are faced by students in school that are really not faced by employees in, say, the Federal Government or not faced routinely by the people who need to access Federal Government sites. So, for example, one of the examples that I often give for this is if you try to apply the current standards for accessibility to education and you say that, for example, everything that is auditory in a piece of software, or on a web page must have captions and you have a person who is speaking and you are, you know, you have software for small children, say, K-3rd grade and you are now going to have a story told and you want to caption that story because you want to make it accessible, that still may not be very accessible to children who are deaf in that age range because they may not have the reading skills to use that. Did you make it accessible? Probably no. Did you follow the standard? Probably yes. So what we are really looking at is that in education, there probably is not really now an existing total standard that you can adopt and so that basically what you have to figure out as you are going is what is going to need to be in place in terms of the design of the products so that it will best accommodate the users that I have, the age range, the fundamental skills that you would expect of those children and the needs that they have. And that becomes, of course, a much-a very, very challenging issue to deal with and beyond kind of our scope here, but certainly something to think about. So sometimes education entities, particularly K-12 say well, we are just going to adopt Section 508 and then they wonder later why things haven''t really gotten necessarily much more accessible f or them. So that is a challenge that we have to face nationally and that we not have resolved entirely yet. So that is, that is basically the situation that we are in. I''ve already kind of talked a little bit about the idea of other standards other than 508 for, for evaluating software, the fact that some entities have developed things they call non-visual access standards or have developed other kinds of guidelines or standards that they use. There are also, and we provided some of this in our resources. There are guidelines that developers can use that will lead to more accessible software development, and they are-those pretty much precede Section 508 in terms of their development or are part of how Section 508 came about. So there are other standards that are used. Actually, a few other countries have designed some standards and have been working on that. The next thing I want to move to, and this is the part that is really tough to do when we are talking without being able to be sort of visually connected better, is to talk a little bit about actually things that you could do on your own to test out accessibility of a product. Even without-and this is not a complete list. So I want to caution you that the things we are going to talk about here are just examples and they are not, not the case that if you were able to do all these things, that you would have solved it. However, they are the place that many products fail right from the get-go and usually if these things have not worked out right from the get-go, I can pretty well assume something else hasn''t. And they are some of the easiest ones to describe and to test. So probably what we should have requested today is that everyone have access to, to a computer workstation of some kind so they could pull open some application on their desk, like a word processing product or a spreadsheet product or their e-mail program. I''m not going to be too picky about what you pull open, but if you can do that, that would be great. Otherwise, go back and do this after the fact and we''ll look for a few things in that application. One of the things that are really critical to accessibility is the ability to navigate all of the parts of the application with the keyboard, all of the menus, all of the toolbars, all of those kinds of things. And this is something that really poses a barrier for lots and lots of people. Obviously, there are many people with disabilities who for one reason or another, can''t use the mouse, and certainly that would include people who are blind or who have sufficient vision loss that they are not able to coordinate the hand-eye thing about the mouse. It can be sometimes that you are using a laptop, like my laptop that has almost no mouse. People always, when they borrow my lap top, they want to get a keyboard equivalent for something because they can''t figure out how to make my mouse work. So that is a pretty valid thing. Actually, there have been studies, and I don''t have access to this information right now. I would be glad to share it if I did, but there have actually been some studies done of individuals in office support and clerical positions and showing that if people do their word processing predominantly from the keyboard rather than functioning with a mouse, they will actually be more productive. We need to find those important studies. Basically there are people with many physical limitations, who have difficulty manipulating a pointing device and there are many people who benefit from having macros developed, so, for example, a number of functions of a piece of software can be automated and you can only do that automation if there are keyboard equivalents for the major function. So how to figure out whether those things exist in a piece of software is not really difficult and usually not something that evaluators disagree on too much if they follow a good process, and the first place I always actually start, frankly, is by looking at the screen. Many applications that have software equivalents for functions in the tool bars and menus will show those with a little underlining of particular letters or upper case of particular letters or little indicators connected to a specific letter on the screen that shows you that is activated with the alt key and then the control key. Then I think it is good to test a few out. Usually your top menu bars are activated with the alt key and lower tool menu bar options with the control key. The ones that drop down are often activated with the control key and the appropriate letter. This varies a bit from application to application. Some have shortcut keys that are embedded into the function that have absolutely nothing to do with any mnemonics or letters in the product. I have a product on my desktop that a major function of it is activated by pressing F-2 and another one by pressing F-5, the function keys. There is no mnemonic to that, no logic to it, but that is how it works and it definitely does. And it shows those shortcut keys on the tool bar so that someone could see that those exist and they can either click the item or enter it with the keyboard. So another way to check this out if the application doesn''t offer this to you obviously, is to of course examine the documentation. This information absolutely should be documented either in documentation that accompanies the application or in a help file, or on the website or somewhere. And if it is not documented, I always assume it doesn''t exist. Sometimes that is not true, but I usually say if you didn''t write it down, you didn''t do it. So this is a very critical feature and it is one of the easiest things to check and one of the easiest things to articulate back as a requirement that I need functions to be accessible from the keyboard bandit is very easy to test that. So that is the other issue that we can look at is actually navigating around on the screen, whether the focus follows the tab key, for example, whether the focus follows the arrow keys and whether those things actually work. So if you are in a menu and you were to use the arrow keys, do the menu options change or do the arrow keys not really do anything, does the tab key move the focus around, how well do those kinds of things work, and so it is also useful to check that out. If it allows you to enter text, is there a clear carrot or curser that you can see? This isn''t always going to tell you for sure that it is going to be relatively accessible, but it is definitely a clue. There are other tools that one can use to help evaluate some of those things, but again, just getting a visual cue that is useful. This is also an especially useful attribute to check with using screen reading technology, in particular, and so if you have someone on your evaluation team who can do this for you, screen reading technology is very, very sensitive to whether or not the application tracks the focus very effectively for navigation and whether or not that is possible and so, for example, if the screen reader user uses the tab to move from field to field, does anything happen, if the screen reader user uses the arrow keys to move up and down in a menu option, does anything happen? And one caveat to that, of course, is that screen readers certainly can be programmed so they will respond better. They can have programming written for them just like a software has it written for it that compensates for the errata in the software, the inaccessibility in the software, but we are not talking about does this all work after someone went and fixed the assistive technology. We are talking about does it work more or less from the get-go and how big a barrier is that going to be for us. That does lead to my last option that we''ll talk about here, which is the really basic, which is the compatibility with the accessibility features in Windows. This is also very, very easy to check. Under the accessibility options in the Windows control panel, you''ll find a number of-if you are using other operating systems, you''ll want to check this as well, but we primarily have been looking at this in Windows. But essentially if the operating system that you use offers accessibility features, can you turn those features on and still use this product? The one that I usually test with, which is the most problematic, is high contrast. So when I set the options for high contrast and then I load the application, can I still display everything, does everything work or does it become washed out and grayed out and I can''t see it anymore. If I choose some particular user colors or user fonts or other features in Windows in the appearance, will they still stick when I load the application, or does it force me to use particular colors and sizes and fonts and things that might not be very useful for someone? There are also ways to check out, obviously you can check for the presence of captioning. You can, if the product has audio, then accessibility would naturally call for the presence of captioning. That is pretty easy to see. There it is or isn''t. There are many things that are really challenging to try to evaluate, and they actually require significantly more expertise and significantly higher degree of planning. Things that relate to how different processes within the software application are called, how it communicates this information inside of Windows. There are ways to find this out, but they are not always readily apparent. So they require some skill around the understanding of the applications process and understanding of the development process and it is certainly something people can learn to do, but it isn''t something that most people who are, say, working in a classroom or working in an office will find really easy to do, particularly without a lot of assistance around that. The other item under this that I wanted to mention that I nearly forgot was the issue is accessibility of the icons, whether the icons on the screen all have text equivalents. Depending on the application, sometimes you can tell by moving the mouse over the icon. Sometimes there are other products that can be used for that. There is a product called Inspect, which is part of the Microsoft Developers kit and that particular product will allow you to analyze the accessibility of various graphics and icons on your screen. Generally, if there is text associated with a particular menu bar or tool bar, then that menu option will probably be accessible or pretty readily made accessible to people using assistive technology. So that would be the other fairly simple thing to test. We have already mentioned a little bit about some of the complex issues in assessing things for accessibility. The issue of accessibility versus meaningful access and we''ve already kind of given an example of this in talking about, for example, the student who is deaf, who is in the third grade or second grade and doesn''t have adequate reading skills to read the fine captioning that somebody put up there because words are too big, and those things are barriers also. Any time that you are requiring the individual to go beyond their fund of knowledge, particularly in education settings, this is challenging. So the same issue might be true, the same example, flipping it to a different situation if you had a blind child who was being asked to comprehend something that is part of a description of a graphic that was beyond the kind of fund of knowledge of what children understand and particularly children maybe who haven''t seen and who haven''t sort of developed a visual vocabulary. So there are some barriers that mean that essentially even when we do what we should do about accessibility, that we may not have in fact solved all of the problems for individuals around usability. This usually gets a little bit less complex for adult content materials, but it can also be the case there because, for example, if adults are being asked to process a variety of information simultaneously, but they are only able to get it in audio form, as, say, would be the case for a blind person, or in visual form which might be the case for a deaf person, would be you were streaming a variety of contents to them, like, for example, in an online meeting application, this might be really complex. So the blind person, you might have developed an accessible web page and accessible audio content and accessible visual content and all that, but if you are streaming it to the person all in one way, that poses a usability problem, even though the product may be really quite accessible. So it is important to separate out the issues of accessibility and usability and know that sometimes just meeting the standard is not enough and probably a better title for this would have been accessibility, is anything really usable, because there are probably lots of things that meet the standard for accessibility and the question is are the users for whom the accessibility was put into place, are they totally able to use it? That often varies. It varies with the user. It varies with a variety of things, so there are many, many factors. One of the things we are seeing a lot in education these days is the complexity of web content all being combined together so that-this actually was not in an education application, this was a work force application where it would be really hard to know what the thing was. It was definitely software. It actually ran in power point, but it utilized the Browser. It had a web kind of look and feel, but it wasn''t web content and basically in evaluating its accessibility, I had to use all the applicable standards. So not only did I need to use the standards for accessibility of software, but I also needed to use those for web content and for multimedia, because it actually had characteristics that applied to all of those factors. It wasn''t pure software anymore. So when we think about products, we think to need-think about what all is in the product. Is it just, is it pure software, that is, it doesn''t have any other component to it, or is it in fact a hybrid? More and more things are becoming hybrid. The example on the hardware side is a personal data assistant, which has hardware, software, has telecommunications properties, and has many, many elements to it. So those are all factors that we have to consider. I want to talk a little bit about some of the issues that people face in dealing with the whole issue of accessibility evaluation. The first of these is sort of the reliability of your process. If you have one person doing your product analysis all of the time, then you sort of take that person''s word for that and reliability is still, you know, reliability and consistency could still be a problem. But many of us have a multitude of people who are giving us feedback about accessibility. If you are going to create an accessibility evaluation team, which I think is the best approach to getting the job done, as I described earlier, then you are going to want to make sure that the team is entirely on the same page as to how products will be evaluated, what the outcomes need to look like, what does and doesn''t meet the outcome. And a great deal of work in establishing an inter-rater reliability is really critical to the success of that kind of a process. If you don''t do that, you will end up all over the map with different results from different people. That will create confusion for you about your final decision. It will certainly create confusion for your product developers and it will create confusion for your end users. So it is very, very important that the process be actually practiced and tried and worked out together so that you are in agreement. One problem, of course, then, is that we have the issue of accuracy. We could be reliable, but we could all be reliably wrong. That would also not be good. So the process that we adopt to try to assure all of this does have to in fact assure that there is not only reliability in the process, but also that reliability gets results that would be credible and defendable if we in fact had to defend them later. In fact, if we do decide something is not accessible and not going to be useable to particular entity, then we are going to have to be able to describe specifically why, and it is going to have to be a pretty, you know, solid explainable sort of thing. So that leads me to, then, my next observation is that obviously this takes a significant training commitment for anyone who wants to do this, and to work this out and a great deal of practice and working together and working with a variety of folks to do this, and it does require a real commitment to do this. I''ve worked with a number of entities to try to help them develop this skill internally. It is really, really challenging. What we usually find is if they are going to be testing a lot of products, we usually find there is sort of a baseline place that is pretty easy for the entity to go, and that is a higher scale than where we''ve talked about today in our examples. There is some limitation to that for most entities unless they are very highly technical. Then at some point you have to start deploying some of the other methodologies, either have a third party do some of your work for you or rely on vendor documentation if that documentation exists. So the training is an important piece. Making sure that there is the expertise on the team to do all of this, again, we described at the very start, we described some of the kinds of expertise you would want to have in your group. All of the issues around the product development expertise, assistive technology that might typically be deployed, the various issues around how the products are used to make sure that we don''t have a barrier in accessibility because we are trying to actually get the product to do something it doesn''t do anyway, and so if that is Not, if that is not something it does, then we probably don''t want to test it in that fashion. We probably don''t want to evaluate the process in that way. So basically making sure that you have a good round of folks who can help do this or who can be available to consult and that is certainly an appropriate role. I find that in the situations where we''ve helped people to do this, that there is a point at which you can drop back and take more of a consulting role so that you are looking at some very particular natty things that they weren''t able to get reliability on or they suspected weren''t accurate or they just didn''t know how to test it or whether it is not really part of the standard. So that is another piece that is very appropriate, and obviously, this is also supported by the idea of the team approach. So in closing, the fact that I mentioned just a couple of resources that are useful in terms of examples of guidelines and processes that people can use, and I''ve mentioned a few others throughout the presentation. This is a challenging process and it is not as simple as simply saying, well, you know, we want things to be accessible. We want to comply with, you know, whatever it is we are supposed to comply with, the ADA or Section 504 or some state law. We just want to do the right thing. Those are all good, but then how do we actually, how do we actually determine that our, you know, that our processes and products work in that way. It is a very, very challenging process. It does require a great deal of work and forethought to pull off. As I mentioned at the start, if the products or the entity being covered are similar to those that are used by federal and state agencies, then the process is a little bit simpler because a great deal of support has been developed for the Federal Government. However, if your environment is unique and is not like that of the Federal Government or if you want to doggedly persist that it is not like that, even though some of the rest of us might think so, you will have to be more creative in actually determining what in addition to, or instead of, the standards that have been adopted for 508 would meet your needs. To the extent that you can make those standards useful, though, I certainly encourage it because they are something that industry is familiar with and practices in many industries. So to the extent that they do serve your purposes, even parts of them, then it is very well to try to make use of that. But know that simply adopting that standard and then asking people if they meet it as they provide products to you is actually not going to probably get you too much closer to accessibility. You have to be able to articulate what it is that you are looking for and you have to be able to have a way of evaluating whether you''ve met it. So those are my formal comments, and I''ll be glad to pursue any of that information in different ways or different processes or to take on other kinds of things as you all wish.</p><h3>Robin Jones</h3> <p>Thank you, Debbie. I appreciate your thoughts and comments in this portion of the session. One of the questions I have for you and often comes to our office, before we go into the question and answer with all of our participants is there any one vendor that has, you know, when you look across your traditional software we might use in office or other kinds of contacts that has really taken on the accessibility scenario that, you know, embraced it widely, as a widely known thing or does it continue to be hit and miss? Microsoft obviously being one example of a software publisher producer there, but have you seen any that you thought are better than others or embraced more?</p><h3>Debbie Cook</h3> <p>Well, it generally varies from product to product. Since you mentioned Microsoft, I think the scenario for them is a great example. This is what happens to most product developers. Microsoft has a very strong corporate commitment to accessibility, and I don''t use that lightly. I think there is a very strong commitment to that. They have a large accessibility group and they have made great strides in making some of their products more accessible. They have prioritized that and in doing so, I think they have done a lot of consultation with the disability community about where those priorities should be, but Microsoft struggles because usually software development is quite a long time ahead of what is actually released. So, for example, we are all just starting to get, what is it, office 2003? Well, you know, our year is 2004. You can better believe that probably office 2004 is pretty much in the can and actually 2005 is probably well on its way into that same, you know, test process. And so basically, you know, if a decision gets made about a new accessibility feature that needs to be plugged in or implemented in a better way, some feedback comes to them or they determine it internally, it might not be able to be deployed for two years. We out here assume that is complete unresponsiveness on the part of whoever it is but that may not be the case. That may be that is simply where they can catch up with the development cycle. Probably one of the companies that is made some of the most significant progress going from nowhere to somewhere in a pretty rapid order and with pretty heavily impacted by Section 508 was Adobe. It is the maker of the, let us see, PDF. That is the document format that basically everybody thinks you should store everything in. I don''t, but that is okay. And PDF is fairly easy to create and a lot of people use it as a mechanism for storing documents. It is called a Portable Document Format. It started out literally as a way of storing archives, but now is the way that many things particularly get themselves up on the web. PDF is a graphical format, which in and of itself was not accessible because there was no text to be associated with it. Adobe worked really closely with Microsoft because they needed to interact with the operating system to, in terms of making their product more accessible. They worked with some types of assistive technology developers. There were some other kinds of assistive technology that have been a little bit late blooming in terms of being compatible with PDF, but we are actually getting to the place where most of the assistive technology that needs to be is. Adobe has actually worked really hard on improving the accessibility of their product. Is PDF totally accessible? No, it is not. There is a whole discussion on that, but two or three years ago we were at a place where none of them were. Now we are at a place where many of them are much of the time. So that maybe a qualifying statement, but that is very true. You''ll see that a lot with different developers. You know, of different products, both hardware and software. IBM, for example, has made a pretty overt effort regarding the accessibility of particularly their hardware, and I''ve seen as I have been going through a big trauma to select a new lap top, I did look at the hardware accessibility of all of the major lap top products and actually, it was interesting to see whether people had or had not thought very much about that or how they interpreted it, but IBM clearly does. So there are a number of different developers. And what you''ll see often is that it is kind of product by-product because there are some Microsoft products where that has been thought about very highly or some IBM products or some Adobe products where that has been thought of very highly and some others where it hasn''t really hit the drawing board. So there it depends a lot on what users kind of feedback as to what is important.</p><h3>Robin Jones</h3> <p>Some of the demand issues being</p><h3>Debbie Cook</h3> <p>Yeah, for sure. You know, when companies begin to hear that somebody wants to procure, I mean there are two big reasons why you can''t-you want to have an accessibility standard. One is you want to serve your users better. That is the good guy standard. The other one is you want to send a message through your procurement process to people who develop things. Many, many, many years ago before accessibility of information technology was really thought of too much, a number of us spent some time with some people at Microsoft back before they really had any kind an accessibility team. We were told very straight up, if you want to change this, I mean we agree with you, we think it is really important, we hope it happens, we are not down on this at all, don''t get the wrong message, but really if you want to get a messages to us, you need to get it to us through procurement because what people want to buy is what we want to build. We want to build it better than anyone else builds it. That is true straight across the board. If we can make any noise in the marketplace, then that makes a difference. So by the Federal Government adopting Section 508, we have a significant noise made in the marketplace that benefits many of us who have very little association directly with the Federal Government other than that we send them a big check in a couple of months. But basically that does in fact impact a lot of products that we buy. It doesn''t impact all of them, and so my caveat on different days when I''m looking at a product that just has gone nowhere with accessibility and if I''ve been talking to them and it is still going nowhere, it is like if I could just get the government to want to buy you. So that is, I think, the biggest challenge is that the marketplace has to stay-say it is important.</p><h3>Robin Jones</h3> <p>Which is with anything.</p><h3>Debbie Cook</h3> <p>Yeah, exactly.</p><h3>Caller</h3> <p>I''ve been asked to make our website accessible. I''m brand new to this and I do not understand what accessible means. We don''t have any kind of software right now that is going to allow me to do this unless Front Page 2002 has that ability. I''m just, I am lost. I do not know what to do. I do not know if I should buy software, just where I should be headed at this point.</p><h3>Debbie Cook</h3> <p>Well, it is possible to create accessible and inaccessible web pages in just about any product. So if you are using front page, it is certainly possible to create products that are accessible or inaccessible. We do actually, on our AccessIT website have some resources that will help you and will help any of you in terms of finding out about some of the tools, or how to use the tools you have, and that web address is on your handout. I recommend that you visit us and take a look in our knowledge base about that. But let me just give you a really broad overview of this. You will in fact, whoever is actually doing your web development, if that is you or someone else, you will actually probably need some training. There are some, depending on your HTML skills, you may be able to self train and our website does show some links to some, I think mostly free tutorials that you can sort of go on line and learn, but they do in fact assume that you have some pretty good knowledge of HTML. There are also a number of free and low cost, they range from free to very high cost, products for checking the accessibility of pages, but those products assume that you do in fact know something about the accessibility requirements. They will give you a lot of data back. They will give you a report that says this is this way, or that is that way. But about half of what they give you back is, you might need to check this because it might be a problem. So it does require developing some knowledge of the requirements. Most of the people in looking at website accessibility either decide to adopt the Section 508 standard or they decide to adopt the Web Content Accessibility Guidelines developed by the Worldwide Web Consortium. Either way, both of those particular guideline or standard processes have a great deal of support available with them to provide some tutorial or some examples. I think it is fairly difficult to create accessible web content without at least a working knowledge of HTML. So I always recommend to people that if they have come to this as a graphic artist, which is the way that I find that people come, most often when they don''t have a working knowledge of HTML, that the first thing you''ll want to do is take at least a basic HTML course because there are some things that can only be fixed by writing a little code. Many things, for example in Front Page, if you are looking at a graphic and you need to put a text label on that graphic so that it would be accessible to someone that needs that, you can, in the properties of the graphic, you can find a place to add the alternative text and it is just there. So there is lot of things that can be done. I would recommend, depending on where you are located, that you talk to your ADA IT center or other resources about actually getting training for yourself and for the folks who actually assist you, if there are any, in putting up your pages. Because many things about accessibility, particularly of web content, are very tried and true and very, very standardized, so that you won''t have the frustration of knowing what to, that you have web content is something that there is a tremendous amount of information on and, and it is not hard to do. Also, on our Access IT website, if you are a very experienced developer, and again, comfortable with the processes of the code, we have some information that is in tutorial format that will assist you and you can look at some of that and at a number of other sites. The Section 508 site, there is a web accessibility course you can sign up for. Depending on your personal skills, you know, some of us do very well with self-study, and that is okay, but most of us need some live instruction. I usually recommend that that live instruction include some demonstration of what happens to users, particularly of assistive technology, when they visit websites, and that sort of thing. There is also information on our website about a video that you can purchase that provides some demonstration of accessibility and inaccessibility. It doesn''t show you how to fix it, but it does show you what some of the consequences are, so that to help you with your sort of definition of what is accessibility. But probably the bottom line in terms of definition is that we want to think about things being useable in more than one way. So everything we can do with the mouse, we can do with the keyboard and vice versa. Everything that is visual is auditory and vice versa. Everything that is available in one way needs to be available in more ways. The more multi modal our process is, probably the more accessible it will be.</p><h3>Robin Jones</h3> <p>Thank you, Debbie. Just to follow up with those resources she mentioned, to contact your ADAIT center that would be at 800-949-4232 with voice and TTY. Then to access the AccessIT website, you can probably do that off of your ADAIT center''s website. If you are not familiar with that, which one serves your area, you can go to www.adata.org, or directly to the AccessIT website, which is www.Washington.EDU/AccessIT, all one word. They are at Washington University, University of Washington?</p><h3>Debbie Cook</h3> <p>University of Washington.</p><h3>Robin Jones</h3> <p>In Seattle Washington. So if you do want to follow up on those, that is one way to also do those. I talked to many people who are involved enough, committed to the issues and they say the idea will be at some point when you can actually use a front page or something and it would already be set up so it would cue you about the accessibility.</p><h3>Debbie Cook</h3> <p>It does for the things it can. It does for all of the things that probably can. Many of the things about accessibility have to do with presentation rather than coding. So, for example, it could never tell you for sure whether you have only used color to represent something that needs to be represented by something else. It can tell you that if you are using colors that you might have done that and it will ask you the right questions. Many of the accessibility checkers, which work like grammar checkers, they can, I always tell you that a grammar checker is pretty good at telling you whether the word was okay, but what they don''t tell you is whether you should have said it. If I''m writing a memo to my boss and I want to tell him what I really think of him and I use the grammar checker, it is going to tell me whether I used who and whom correctly, but it doesn''t tell me whether I should have made that statement at all. Because it can''t evaluate that, that is the same problem we have with many of the products, they check for accessibility, they can give you information about your coding. They can''t always give you information about whether things work.</p><h3>Caller</h3> <p>One of our current research interests is cognitive IT accessibility, in particular for the internet and web. I''ve noticed in surveying print and web resources that there is a bias in accessibility around physical and sensory disabilities and your talk seemed to reflect this. Are you aware of any good resources or research into software issues with regard to people with cognitive disabilities?</p><h3>Debbie Cook</h3> <p>There are some things that have been done, but nothing really definitive. What we generally have thought about and this was largely true as we were discussing this in the development of Section 508,for example, was that if you in fact do all of the things that are required that people typically associate with particular disabilities, you will in fact deal with a lot of the issues of cognition. For example, good web practice is to lay things out in the same places, if you have toolbars or you have other kinds of things. One of the things about the product I was evaluating last week that I mentioned earlier is that one of its real barriers, it had nothing to do with people with cognitive disabilities, it had to do with everyone, was that different buttons that were associated with functions moved around the screen for the convenience of the program and the inconvenience of the users. And we evaluated the product using people with cognitive disabilities and people who didn''t identify themselves as having any disability at all and they all had the same problem. So many of the issues related to cognitive disability relate to general usability and there is a wealth of information on the market about usability and the fact that a lot people in general don''t have a good structural knowledge about development. They don''t know how to present their content so that it would be useable to any user. The issues, then, with folks with cognitive disabilities is that this is magnified. People without disabilities can get around some of these things and people with disabilities just get stopped. So it is a great deal about usability. And we find that what we want to teach people about this is good page design. Lots of times, you know, people will show me a page and I''ll say well, it is accessible, I suppose, but it isn''t usable and it isn''t usable by anybody because of the way it was designed. The links don''t have meaningful names, it uses large terminology, it doesn''t combine graphic and textual information in a way that is helpful for people to interpret things and also isn''t accessibly designed. So many of the issues around accessibility for all people, but particularly for people with cognitive limitations is about usability and about good design.</p><h3>Caller</h3> <p>You have done so regarding resources or how we might be able to obtain resources at equal opportunity and civil rights practitioners, that is very important because to me when you enter governmental relations where you are finding out how you might be able to assist all individuals, whether they are able-bodied or they do have physical or mental impairments so that they would have good effective service delivery for our programs and services that we offer. My question was, when you were talking about the three basic processes used by the Federal Government, whether it is testing teams or product accessibility templates or independent testing. Within your opinion, which processes might be less costly and at the same time effective to determine software accessibility? Now, again, you mentioned resources. I was thinking also with the equal opportunity or civil rights practitioners here, maybe we need to, as you mentioned, identify their needs within their certain entities that they do have. I know that they have started that through their lead equal opportunity specialist, Tim Golemo, who is taking the lead with all the equal opportunity officers here within our state agency, maybe going from that level, finding out what their needs are and then maybe an in depth training, then maybe monitoring, but if you can give us some input, we would appreciate it.</p><h3>Debbie Cook</h3> <p>It seems like the process you would want to kind of follow is to begin by first establishing, I don''t know whether Illinois, for example, has established an accessibility standard, whether it is 508 or something else, but if you haven''t, you would want to start there because you need to know what you are measuring against. And in doing that, if you haven''t established, and even if you have, you want to do some training with people around what that is because sometimes people come to me and they say I want it to be accessible. We are going to do whatever it takes. Then they say, "We don''t want any training because we are just committed. We trust that it will be good". Then I come back and say we can''t do this anymore, and oh, but we want to do that. I say I''m sorry, you can''t do that anymore. It is really, really important to start with some training. I almost think before you even ask people what they need. Because I often find people don''t know what they need. They either say they need nothing or they need everything. Both of those are not quite right, they are extremes. Then I think your next process is to establish, you know, for, ideally for your state as a whole. For my state, the state has not actually adopted an accessibility procurement and development process, but we do have some individual agencies who have very strongly done so, and those agencies have identified, you know, their standard and how they are going to monitor it and how they are going to train for it and test for it, and what they actually do is a combination of pretty much the in-house team and because they are a state agency, their needs are rather compatible with those of the Federal Government, so they do in fact benefit from some of the information that shows up on those Voluntary Product Accessibility Templates. Using those carefree. If they exist, you can use them, but remember, it is let the buyer beware. It is the manufacturer''s version of their story. I don''t think it is ever ill intended, but if we were doing a longer training where we could use visuals, I would show you some examples of where really well intended stuff didn''t turn out to be very accessible. So you take that with a grain of salt. You determine which products that you are likely to be buying or developing are most likely to have accessibility problems. For example, if you are buying, you know, products like Microsoft Office, there will be components to that, that may have accessibility problems, but it may be what there is. Much of it is accessible so you won''t spend a lot of energy testing that, but particularly, if you develop proprietary products, you dang well better have a process for actually evaluating that accessibility because quite frankly, that is where, you know, we get into a lot of trouble by what we build ourselves. Whether that is web content or software products or little square boxes. So it seems like that would be a process to go through. Probably you''ll want some consultation since you are there in Illinois, probably from Robin''s office, sort of in terms of getting started, in terms of getting a process together to determine how you want to deploy this. But it is, it is going to involve your IT staff and one of the things information technology staff, one of the barriers that I often see is not a clear enough line of communication between the information technology department and the equal opportunity department. And so there is sometimes not a good structural process and agreement process and understanding and collaboration. So if that isn''t it in place that would be probably one of the first places to start. For someone in education system, then I would add the library and information people in that mix as well because that is where actually a lot of your technology and information is generated from, and if they are not at the table with you, you''ll probably be in trouble.</p><h3>Caller</h3> <p>This is about multi function devices, those big $12-20,000 printers that we use and network in offices. When you go to the various manufacturer''s websites, including our own and look up their VPAT, everybody appears to be minimizing the impact of the most important factor on them, which is the big LED screen that cannot be seen by visually impaired people. So what I''m wondering is, does anybody appear to be working on addressing the multi-function printer issue? I mean I walk up to some of them and it is a job for me, who can see perfectly fine to figure out from all the buttons and the LED screen what to do next.</p><h3>Debbie Cook</h3> <p>Well, the two sets of product standards that would apply to that are the closed product standards. And the hardware standards. Those two sets of standards are almost identical in many ways, as you probably already know. So that is a pretty good example of whether or not just taking something, something is word for its VPAT is a good way to go. That is a pretty good example of that. There are some manufacturers that have worked on this somewhat. Actually what I''ve seen more movement toward, though, is actually having a lot of these devices operable from the users work station rather than from the device. Particularly if they are in a network environment, and that is what I''ve actually encouraged people to look for because then, it shifts the accessibility issue. The user has a lot more control over their accessibility needs when the product is actually being operated from their desktop environment, which can be for many users, if they are using the environment at all, can probably be made pretty accessible. I mean assuming that they are there assuming we have probably been able to do something for that. It shifts that away from the actual device. There are many issues of accessibility, including loading the device, getting things from the device, reaching the buttons, identifying the buttons, the issue of the user screen. Most of those, to some degree or another, aren''t being addressed. And so I don''t know. I would probably take issue with whether anyone of them is totally not being addressed. As I walk around and look at them, I don''t see that any of its being addressed enough. That raises another point that I think is really important, which is that accessibility then becomes a case of buying the least offensive thing. So what you would have to do is, you would have to look at who is addressing the largest number of them. You might want to factor in a particular instance whether your product is being deployed for users in general or for a user in particular. So if it is being deployed for users in general, this means that you don''t know who all the users will be over time. Then you are going to go for as many of the options as you can. You may also want to think about if some of the options themselves are not accessible, one of the, you know, caveats to standards is that the thing is compatible with assistive technology. So is it reasonable, and this is going to vary from option to option, is it reasonable that if I can''t purchase one that is accessible, is it reasonable that there is an assistive technology or an adaptive skill or some other kind of way that people who need to be able to use it and can get at it and am I prepared to support that? We''ve seen some of that deployed. If it is being purchased specifically to accommodate a person with a disability, then obviously the things that they need will have to be there. But in general, when we are talking about deploying that kind of a big product, that is not what that is for. That is for general use. You don''t know who the users are going to be. You are going to have to go for as many accessibility features as you can get and maybe get some consultation around, you know, if this were part isn''t accessible, what can we do at the user end to accommodate them while we continue to look for an actually accessible solution to this. And the Federal Government is almost the only pushback there is going to be. There are not very many other entities. First of all, I know of no, I''m trying to say this pretty carefully because somebody may decide to prove me wrong, and they please can. This would be something I would be delighted to be wrong on. I know of no actual entity outside of a government entity, whether that is federal or state, in particular, and I''m sure some county somewhere has, but I wouldn''t know right now where it is, but I know of no entity right now outside the government that has specifically adopted a full scale, you know, information technology procurement accessibility standard. So if most of the product is not purchased by the government or significant pieces of it are not purchased by the government, or if they haven''t purchased it since they adopted the standard, then in fact you know, it is that market argument again. We are making the point that without a market to drive it, it doesn''t necessarily happen. So you know, my motivation either becomes more people have to adopt a standard and want it or we have to get the Federal Government to want it big. I mean that is a lot of what it amounts to. Or somebody has to find a legitimate way to have sued somebody. This is a tough one to actually sue over because since there is really no legal requirement outside the telecommunications industry, so if I can figure out that this is a telecomm product, I might be able to make a case where we can sue the developer, but if it is not a telecommunications product, we are not going to be able to successfully, I don''t think, under any known law, do a valid case against the developer other than issues around, you know, Section 508. So it is pretty challenging. I guess the one thing I would add is users who don''t identify themselves with a disability benefit from a lot of the things that we do about disability, and so when we are talking about more readable, you know, or more reachable or, you know, everyone benefits from that. So sometimes rather than coming at a developer with respect to issues of disability, because, of course, most of us don''t think that people with disabilities go to work or use products or have any business being out there anywhere, so rather than pursue that, sometimes we are better off to pursue the general usability. Did you know that everybody under 5 feet tall can''t do this or everybody over 6 feet tall can''t do this or everybody who wears bifocals can''t do this or that they can''t do this you know, it is not people with disabilities who primarily are using the parking ramps in front of grocery stores. It is moms with strollers and all of us pushing grocery carts. So to the extent we can make these usability issues rather than accessibility requirements, we are often further ahead.</p><h3>Robin Jones</h3> <p>Yes, thank you very much. That is an excellent point and I think we struggle with that and I think as we look at issues with software accessibility and such and try to impress upon our developer and people that we do have to continue to push that issue of a broader sector of the population being better able to, or more efficiently able to access a product, than a narrow set. I think we make that. I know we struggle with the whole issue also with manufacturers and such that if they don''t see the numbers, if there is not enough of a purchasing power, you know, to influence, there is not enough people calling for it in their purchasing, what is my motivation as a product developer to make it accessible? So it goes back to also what we are looking at in procurement, which is a huge issue.</p><h3>Debbie Cook</h3> <p>Well, we have an aging work force. If you look at any of the statistics on the number of us baby boomers who are planning to work later because the stock market took a few too many dips, there are a lot of people who are going to be looking for more, they are not going to talk about it as accessibility. They are going to talk about it asusability.</p><h3>Robin Jones</h3> <p>I agree. That is a huge issue. Thank you very much. We are getting towards the end of our session. I''m sure we have people on the line who have questions they would like to ask. This is a delicate balance of time to speak and time to ask questions. For those of you that have questions still hanging, we would like to be able to address you, your questions and provide you with the assistance. A couple ways you can do that. One is you can contact your ADA IT center and seek assistance from them at 800-949-4232, as well as Debbie is available through Access IT potentially to answer some questions. Do you want to give some contact information?</p><h3>Debbie Cook</h3> <p>Sure. The Access IT e-mail address is AccessIT@U.Washington.EDU. I believe that is on your handout actually, and I don''t even know the phone number, but I''m not in there very much, so if you can possibly use e-mail to address any questions, additional questions that you would like to address to me through Access IT, that would be just great and I will be more than glad to respond to those, and again, there is a great deal of information on our website. I''m not going to tell you, go up there first before you ask the question. That is not fair, or useful, but there is actually a lot of information and I will try as much as possible to refer you to locations there as we can for that. But you are questions also help us determine what new content to develop.</p><h3>Robin Jones</h3> <p>Yes, thank you. I know you also mentioned throughout the session a couple times, you talked about policy issues and such. For those of you who were with us or not with us, Debbie along with Debra Buck from ITTATC, which is another project addressing issues of information technology accessibility out of Georgia Tech did a session for us in September of 2003 that was best practices in information technology policy, and that session is archived on the Great Lakes website, you can listen to the audio version, as well as a transcript where some great information and resources were also supplied. So thank you very much for all of you that participated. Again, I would like to apologize for the problem we had with the 800 numbers this month. We will make sure we double-check that for next month to avoid that problem again in the future. Just as a reminder, our next session, March 16th, 2004 is changing and shifting a little bit. Our topic is issues of an international building code and interfaced with Americans with Disabilities Act Accessibility Guidelines (ADAAG) and ADA accessibility guidelines, what that actually means for people. The speaker is Dominique Marinelli. He has worked a lot in this area of the interface between the ADA accessibility guidelines and the international building code. So we invite you to join us for that session. At this time I would like to once again thank Debbie for joining us today and for providing her expertise and her time, and again, to thank all of you. Hopefully we will see you again in the future. Thank you.</p></body></html>