Good afternoon and thank you for your patience as we get started today. Welcome to our November session where we are going to be talking about the various tools that we use to look at web accessibility and validation of those. Before I turn it over to the speaker, let me just orient you for a minute to the program that we are involved in today. This program is brought to you as a collaboration with the ten Americans with Disabilities Act (ADA) and Accessible Information Technology (IT) centers, also know as the Disability and Business Technical Assistance Centers which were founded in 1991 under a grant from the U.S. Department of Education. This program is now in its sixth year of operation where we offer a monthly teleconference on various topics related to the Americans with Disabilities Act. And in the last several years we have also been addressing issues of Accessible Information Technology. This is the first of a two part series we are offering on issues of Accessible Information Technology, and we are happy to have all of you joining us. We have people joining us in different modes of communication. We have people who are joining us via teleconference, we also have people joining us using streaming audio on the internet, and also individuals who are joining the session utilizing technology of real-time captioning on the internet. We welcome all of you. This session is being recorded, as well as transcript will be created and it will be edited and posted on our website. If you have questions or you are interested in further information about the ADA audio conference series, please feel free to contact your ADA and Accessible IT Center, also know again as Disability and Business Technical Assistance Centers at our phone number of 800-949-4232, that is both voice and TTY. As we get started today, I am just going to turn over the session to our speaker in a minute. But let me just reiterate what we are here for today and what we are doing. We are going to be spending the next, oh I don''t know, 70 or 80 minutes at this point, together talking about the pros and cons of web accessibility validation tools. Our speaker is Terry Thompson, who is a Technology Specialist and I have worked with Terry now for several years, as have all of the centers across the country. We have been very successful in our efforts to try to increase the accessibility of information technology, and Terry has been instrumental in that. He works for both the Do-IT program as well as a project called AccessIT, both located at the University of Washington. And I think that you will find after your session today that Terry''s information is useful to you. Hopefully everyone was able to access and get a copy of Terry''s handout. If you did not get a handout prior to this session and there was a problem with your registration, please go back to the registration process and let us know what your problems were. We will make sure that you get a copy of the handout, but hopefully you can follow along and it will be self explanatory as Terry does go through his program today. So without further ado, I am going to go ahead and turn it over to you, Terry.
Thank you, Robin. Good morning to all of you like me that are on the west coast, and good afternoon to everybody who is not on the west coast. Just a word about the project that I work on, Do-IT and AccessIT at University of Washington both of those are funded by, Do-IT and AccessIT are funded by the U.S. Department of Education and we are charged with promoting technology accessibility in education K through 12 as well as post-secondary nation wide. So we do a variety of trainings, develop resources and talk to various constituents, trying to encourage and promote education entities to make sure that their technology is accessible. And certainly a lot of the technology that we see is in education involves use of the web, so making web sites accessible or making curriculum accessible is delivered on the web, a variety of services and programs are being provided using the web these days in education. It is imperative that education entities ensure that those resources are accessible. So, that is what we are talking about today, is how to make those resources accessible and specifically the role that automated software tools, those tools that can do automated evaluations, and in some cases repairs. In what roles do those tools play in an education entity''s efforts to ensure that their websites are accessible. So, what this presentation is not, is a review of or comparisons of specific products. So, I''m not going to be, you know, telling you about the specific features of Bobby versus LIFT versus some of the products that are out there. We will talk generally about what each of these product or broad category of what the products can do and we will give you some resources and some information on how to go about assessing these products for your own needs. So, part of the reason for that is that we at AccessIT, don''t want to endorse any particular product over another. At this point, the majority of the products that are available are commercial products including the most famous, which is Bobby. And another reason is that, it is a moving target. There are so many products out there, that are constantly being updated that although we have in the past done some pretty comprehensive research looking into some of the major products anyways, we certainly don''t claim to have knowledge of all of them that currently exist because you know, again they are constantly coming up with new products and new features. So what this presentation is on the other hand, is a look at the roles software can play in the organization''s web accessibility plan. So we are going to talk a bit about the planning process and how an educational entity can go about working toward improving their web accessibility and then the role that software can play in implementing that plan. So before we plunge into that, we should first talk a bit about web accessibility just to make sure we are all on the same page with that. What does it mean to design a website that is accessible to the broadest possible audience, including individuals with disabilities? This was formally defined by the W3C, the World Wide Web Consortium. This is the group that defines most things web. They are the people that have the HTML specification. They write the language that is used for building the web for the most part. The cascading style sheet specification is theirs, Extensible Markup Language (XML) is theirs. It is a consortium that represents a very wide body, wide spectrum of participants in creating and using the web. So industry representatives, people who create browsers, people who are web designers by trade, people who are consumers all play some role in the work of the W3C. So in 1999 after many years of work, the W3C released or recommended, as they call it, an official recommendation, which was the web content accessibility guidelines. This was the first definitive set of guidelines or standards that define what it means to develop an accessible website. There were 14 guidelines, and within each of those guidelines there were more specific checkpoints that sort of defined what that guideline meant from a techniques standpoint. All told there were 65 checkpoints, and each of these was identified with a priority level. So there are Priority 1 checkpoints, which were the things that needed to be done absolutely, otherwise you end up excluding some group from accessing your web content. Priority 2, are things that are ideal that should be done, otherwise people with disabilities are going to have a difficult time. They might not totally be excluded, but they are going to have a very challenging and difficult time accessing your web content. Priority 3 then are things that are really if you want to have an optimal, totally accessible site, then Priority 1, 2 and 3 checkpoints should all be implemented. So again, there are 65 of those checkpoints then. So quite a bit of detail within the W3C''s set of guidelines. Examples are things like providing text equivalent for non-text elements so if you have graphics on a page, it needs to have alternate text so people who can''t see the graphics can still access the content. Not relying on color alone so that if somebody can''t perceive color, somebody with a visual impairment, somebody who is color blind or somebody who is using a mono chrome monitor, they should be able to access information so color can''t be used to communicate information exclusively. There has to be some other means of communicating those same ideas and then there are techniques for marking up tables so that they are maximally accessible for screen reader users, forms the same issue, specific techniques that need to be implemented so that screen reader users can definitely know which form labels go with which form fields and so forth and can therefore complete a form reliably. So there are all these issues and those are the types of things that the web content accessibility guidelines address. In 1998 along came Section 508 of the Rehabilitation Act. That was legislation that required that the federal government ensure that any information technology that they are building or purchasing or using is accessible to people with disabilities, and so with that legislation came the first legal set of standards, the Section 508 Standards were created by the Federal Agency called the Access Board, were published in the Federal Register and provide a legal basis for defining what web accessibility is. This came in after the W3C''s guidelines. The Access Board in creating the Section 508 Standards, they turned to the W3C''s work as a resource. They didn''t adopt all of the W3C''s work, but they wanted to do was take that as a resource and what they would adopt had to be realistic for the federal government to attain and it had to be measurable since this was a law. It needed to be something that they could measure and enforce and so what they ended up with then was a focus on the Priority 1 W3C guidelines. So the Priority 2 and 3 were pretty much eliminated but the Priority 1 guidelines remained and the language was fine tuned a bit as well, to make it more enforceable, more measurable and also to make it a little bit more current, because by that time the W3C''s guidelines were starting to get a little bit obsolete. So those are the two sets of standards that we have currently, still today the W3C standards and Section 508 standards and that is going to come into play as we look at the software tools because each of the tools available works with the standards that are available. So what software is there out there? A lot of people have heard of Bobby. That was I think the original tool in this category. It was developed many years ago by an organization called CAST which still exists at cast.org. They have sold the product Bobby to a commercial company, Watchfire, and we will talk about that in a little bit. But essentially Bobby and other tools like it are able to look at a website and assess whether or not it is accessible based on these guidelines and standards that currently exist. So, and a lot of them are customizable so you can select whether you want to focus on Section 508 standards. Then it will check and see if your web page meets Section 508 standards. You can if you want to do the W3C guidelines, then you can check whether you want to assess whether it is compatible or compliant with the Priority 1, Priority 2, or Priority 1, 2 and 3 guidelines. So there is quite a bit of flexibility even with free tools that are available online. So the definitive resource, I''m not sure if it has everything or not that W3C claims that it does, but the W3C does maintain a very extensive list of products that fall into this category. Just to give you an idea of what the extent of available products is, there are 87 products listed on this page. Each one is described with a short paragraph and so you can kind of get an overview, just a quick overview what the product does. And they have broken this down, organized the page into categories. And so there are of the 87, 55 are evaluation tools, which will evaluate a website for accessibility. 15 are repair tools that have some aspect of repair integrated into them, a feature such as prompting users for an ALT tag, if there is a graphic that doesn''t have an ALT tag, it doesn''t just tell you that there is a missing ALT tag, it will prompt you and say this graphic needs an ALT tag and allow you to enter one and then either depending on how it is set up, how it could possibly save that and make your page more accessible interactively. So there are just a few things that can be sort of automatically repaired like that and there are a few tools, 15 on the W3C list that do provide some repair functionality. There are also 17 tools that fall under the category filter and transformation tools, and those are tools that allow you to sample your website as it might appear to someone else who is using a different sort of technology or has a particular disability. Examples in that category are rendering your page as it would appear to somebody who is using a text-based browser. Looking at your page as somebody with particular color deficiencies might perceive it and so forth. So, again, all told there are 87 products. So that is another reason why we are not going to be talking about specific products because there are just so many in the market and the market have become so vast. So kind of the range of the software that is available, there are manual evaluation tools that assist a person or an entity in doing a manual evaluation and we are going to be talking about those a little bit later. There are also online accessibility assessment tools. And so if you go to one of them, Bobby, we have already mentioned Bobby. If you go to Bobby.watchfire.com that brings up what used to be Bobby but they have actually even changed the name now. It is now called WebXact. But if you go to Bobby.watchfire.com then that brings up a very special interface where you plug in the URL of a page that you want to evaluate. And then it evaluates that page and it returns a report that identifies what the issues are with that page. With Bobby, it was solely accessibility. One of the reasons the CAST was willing to sell their product to a for-profit company was that it fit within their vision of what universal design is all about. That Watchfire is a company that already had some tools that could assess different quality measures of a website. So, for example, they would go in and look at whether there are broken links, do spell check and look for orphan pages that are part of the site but don''t have any other pages that link to them and a variety of other issues that could be considered web quality. And so they were interested in integrating accessibility into their product line so that accessibility was sort of one of the quality measures. And that whole idea fit with CAST''s vision. So that is what Watchfire''s product lines have now become as they are quality assessment products that include accessibility, which is the Bobby product that has been integrated into their other product lines. So this is one example of an online tool where it is free. You go, type in your URL and get a report back showing what sorts of problems your page has in terms of accessibility and providing some feedback about how to go about changing and repairing those issues. There are a number of, each of the main companies that we are going to talk about here in a bit do provide a free service like this. They tend to be a bit limited. One of the big limiters is that you can only assess one page at a time, so you can type in a URL and assess that one page, but for an entire if you want to look at an entire website or an entire school, then it is going to have to be, you know, you are going to need a desktop product or a server side product that is able to crawl and spider through a website following links and checking all the pages that it encounters within that website. So that is kind of the next level up. We have our free online accessibility assessment tools, and then the next level up from that typically costing a few hundred dollars is desktop software where you can run it on a local machine and you can assess several pages that form a website, starting, perhaps, at the home page and then following links out and checking all the web pages that are part of that site. Then typically a report from a product like that would be a summary report showing what, overall how many of your pages are accessible based on whatever the criteria you are looking for and then also you can drill in and you can view the reports for individual pages. We also have the issue of evaluation versus repair. Some of these products that are able to do this on the desktop are able to repair the pages or able to prompt you and sort of walk you through using a wizard how to repair the accessible content on your page. Some of them are strictly evaluation. So they give you a report and you take that report and apply it toward repairing your web page or your website individually. Then the high end is server side or enterprise solutions, products that run on the server that are capable of doing assessments and possibly repair of an entire website from the server side and that provide a lot of additional functionality for sort of project management that as an entity is working on their web accessibility and they want to do a benchmark assessment and they want to follow up with particular sites, they want to send out e-mails to authors of particular web pages or owners of particular web pages, and then they want to follow up to be sure that their feedback is acted upon and monitor their progress over time. You know, this sort of thing require a much more extensive database tool, and there are products on the market that provide that sort of solution, and those are the ones where you can''t even get a price on the website, you have to actually call and talk with a sales representative. Prices may vary, depending on the size of your institution and the number of web pages you are going to be working with and so forth, but it is definitely a high-end solution as opposed to the lower end solutions we have been talking about so far. So just a handful of the best known vendors. Again, with 87 products, I don''t want to exclude anybody, but just to give you an idea of what is out there, we will mention those that most people are sort of already aware of that are aware of, you know, companies who are players in this field. That doesn''t say at all that these people at all have the best products, it is just that they maybe have the most aggressive marketing campaigns and so you tend to read more about their products and, you know, get fliers from them and so forth. But Watchfire is the one that now owns Bobby or has integrated Bobby into their product line. The handout that comes with this presentation has the websites for each of these companies. But they are pretty intuitive as well, so Watchfire.com. Usable Net has a product line called LIFT and a huge number of products that fall within that LIFT product line ranging from low end to high end. That is usablenet.com. There is also a product called the Usablenet LIFT Text Transcoder. That is a product that we will be looking at in more detail later on because it is unique. It does some things the other products don''t do, and a lot of people are asking questions about this particular product because they have marketed pretty extensively and there are a number of higher education entities in particular that have purchased subscriptions to this product or licenses for this product, so we are going to be looking at that in some detail. But Usablenet in addition to Text Transcoder also has products that are similar to Bobby that just do evaluation and in some cases do some light repair or some assistance with repair. There is another company called SSB Technologies, that has a couple of products available and a company called High Software that has a couple of products available. The free tools, since a lot of people don''t have hundreds of dollars to spend on a desktop solution and may not have thousands of dollars to spend on one of the enterprise solutions, there are some free tools available. There are W3C Validators, first of all which aren''t accessibility validators per say, but they will check and make sure that you have valid HTML on your website and valid CSS and this is important for accessibility, although it is not, it doesn''t cover all things related to accessibility, but there is definitely a correlation between valid HTML and accessibility. If somebody takes the time to make sure that their website is valid, then it tends to be much more usable, much more compatible with assistive technologies and so forth. It doesn''t cover all accessibility issues but it is definitely a good place to start. One thing that a lot of people aren''t aware of is that the HTML specification and the language as it is defined by the W3C requires all tags. It is not optional that images have ALT tags, they have to have ALT tags according to specification. But what has happened is browsers, Internet Explorer and Netscape and so forth, have relaxed their support for the specification, so that is one area, if browsers were fully compliant with the HTML specification, then they wouldn''t, the web page would break if there were graphics with no ALT tags. It would give you an error. But browsers didn''t want to do that, so they go ahead and render the page anyway without ALT tags. But if you do run a web page through an HTML Validator, it will give you an error and it is not valid HTML if there is an image without ALT tag so that is another thing that could be corrected if somebody strives for HTML compliance. Another free tool is the Bobby online, this WebXact tool, which provides a pretty comprehensive assessment. There are some things that they are holding back on. So not only can you only assess one page but in the report you will see some other things where you can get more information if you actually purchase their product as opposed to just using the free online version. So all the companies who sell products that have some sort of online front end version are in part using that free tool to market their other tools. So you will get kind of some encouragement to pursue their other products as you use their free tools. Another is Cynthia Says, this comes from High Software and the URL is www.Cynthiasays.com. It is a free product online and gives you quite a bit of customize abilities. There are lots of things that you can do with this tool. I actually just talked to them this morning prior to the session because I wanted to clarify something. Cynthia Says used to be, they used to have a desktop version that was free to K-12 educational entities so you could to more than just assess one page at a time like you can with the free online version. With the desktop version you could spider a site up to 100 pages. So if you had a website that had more than a hundred pages, then it wouldn''t work on page 101, it would just do 100 and stop, so it is somewhat limiting in that way. Although I have known educational entities that have used it and just sort of chunked their website into 100-page blocks and then were able to use it. So it is a pretty fully functional solution that can run on the desktop and be great for educational entities and free. However, they are not marketing this any longer and I guess in talking to the person today, they are no longer developing a desktop based Cynthia Says, but that is not to say it is not available. So they are somewhat noncommittal in my conversation today but they say they can probably still offer it free for K-12 entities and you just need to contact them. So probably that means if you contact them, they might be willing to work with you and will send you this, but they are also going to want you to talk to their salespeople. So keep that in mind but you might be able to get a free tool by following links from Cynthiasays.com. Another product comes from Web Aim, which is an organization like ours that promotes specifically web accessibility out of Utah State University. Their product is the WAVE, which is at wave.webaim.org. That is a product with a unique interface where it actually shows you your page and adds icons to the page identifying where within your page there are some accessibility issues that need to be addressed. So I have talked to a lot of people that really enjoy using the WAVE and it is a free product. A-Prompt is a product that was developed at the University of Toronto. It does provide in a couple of areas a repair capability. A wizard will walk you through repairing your page. I don''t think they have done any further updates on it recently. This product was developed several years ago. But web accessibility hasn''t changed extensively. The guidelines and standards have been in place for many years and continue to be current. So A-Prompt may be a nice tool for some folks and again it is free. Another that I like using quite a bit and borders on endorsement but it is a free tool, and it is a not-for-profit company, I believe, but the AIS web accessibility tool bar developed in Australia by AIS, which is Accessible Information Solutions, and it is a tool bar that plugs into Internet Explorer and allows somebody to check a number of things related to the web page that you are currently displaying within IE. So you can, for example, look and see if all the images on the page have ALT tags or not. You can quickly and easily disable your cascading style sheets to see what the page looks like without CSS. You can turn scripts off to make sure the page renders well and is usable with scripts turned off. You can resize the page to see what it is going to look like for somebody using a 640 by 480 browser, or 800 by 600 browser and just a whole set of tools that allow you to check the page that you are currently on. You know, very helpful. I recommend it for anybody who is doing web design because it helps them to sort of perfect their design and make sure it is going to work across a variety of browsers and so forth. So that is kind of a list of some of the free tools. I think there are probably quite a few others out there as well, but these are ones that are fairly popular and ones that I found some benefit in using. There is also an Open Source Project. That was spear headed by Stephen Faulkner who is the key player in Australia in developing the AIS web accessibility tool bar but he has been collaborating with folks in the United States and the UK and Japan to develop free tools that fall into this category, web accessibility evaluation tools, and so we will look for some more things to come from that group. It is a pretty new group. I just found out about it a couple weeks ago, but we will keep an eye on them to see what develops beyond the tools that are currently available. So obviously then there are a lot of tools falling into a variety of categories, broad spectrum of tools from very simple to very complex. You know, some free tools. How does all of this fit as an institution is looking at their web accessibility? Well, I think web accessibility has to be an overall strategy. So when an educational entity comes to me and says, hey, we just got approached by this company and they are selling this product, should we buy this and will that make our web pages accessible? I think the answer to that is have you looked at your web accessibility in other ways. How does this fit within your overall plan. I think first you need to come up with a plan and then see how this software fits, if it fits at all. So sort of components of a web accessibility plan. First of all, it would be identifying a point person. Who is it within the educational entity that is going to be responsible at some level for this plan. Now, web accessibility is not something that I think just one person can be responsible for. It really is a matter of empowering the existing infrastructure. So anybody who is designing web pages needs to be aware of accessibility, and anybody who is doing training for those web designers needs to include accessibility in those trainings. The administrators need to be aware of accessibility from a policy standpoint. Maybe they need to implement and enact policies that require a certain level of web accessibility. So there are all these variables and everybody who is involved at any level in creating websites or web content for the institution needs to be a player in making sure that that web content is accessible. So a point person is needed to kind of spear head and coordinate that effort and serve as a constant reminder that, oh, yes, web accessibility is important and we should be doing that, but there are lots and lots of other people that need to be doing the work. It is also important to develop a specific plan that includes priorities, responsible parties and dead deadlines, document everything that you plan to do and that way there is never any doubt. Everybody knows what the mission is, what we are striving for and when we need to do it. It is also within that to define web accessibility. This is one of the things I have worked at a number of institutions prior to the University of Washington, I was at North Carolina State and prior to that I was in Kansas where I worked for an independent living center that did quite a bit of outreach to educational entities in that region. And whenever I do web accessibility trainings, if it is for an institution that doesn''t have a specific policy at the institution, the staff and faculty or instructors there, you know, wonder, often allowed, what is our institution''s policy. How are we defining web accessibility? Is it Section 508? Are we trying to comply with Priority 1, W3C guidelines or Priority 1 and 2, or Priority 1, 2 and 3, what is it we are supposed to try and attain here. So that is where I think it is important as an informative resource to have a policy in place. It is also important to integrate accessibility into the web design trainings for instructors and staff. So and that is not just having a web accessibility training, although those serve their purpose as well and you can go into quite a bit of depth with those types of trainings. They tend to attract only people that already have some interest in accessibility. It is the other 99.9%, people that are learning to use Dream Weaver or learning to use the Blackboard or Front Page or whatever the tools are that people are using to get content up on the web, they need to have some exposure to making sure the content is accessible and they might not otherwise have that exposure or they might not have that accessibility on their radar screen at all, unless they are presented with that in the available, sort of mainstream trainings. It is also, you know, with regard to web accessibility policies and guidelines at an institution, this can actually take place at any level. It is sometimes difficult to get policies implemented at an institutional level because it takes a lot of time to get the necessary buy-in and to go through the required procedure before something can become policy, but you can also implement policies at lower levels, just sort of as an interim step. So, you know, working with your department to have a departmental policy. Everything that this department creates is going to be accessible. And if not that, maybe even down to an individual policy. So any of you who are listening today that do web design, you know, make it your personal policy to ensure that the websites you create are accessible and then you can serve as a model to other people and gradually maybe that will sort of domino and cascade up to the top. So policies can take place really at any level within an institution, from the top down to an individual. It is also important for this not to be burdensome. I have always tried to present web accessibility as a quality issue, just as Watchfire now does. We are not saying because we are bullies that you need to make your website accessible. We are offering this as a quality, as web quality feedback that, you know, hey, your website has these issues, you know, let me help you to make it so that it is more usable across the board. There are lots of universal design incentives for ensuring that websites are accessible. It is not just about people with disabilities and people who are using assistive technologies, but the growing variety of technologies that people use to access the web. There is a tremendous amount of technological diversity out there, people using a variety of different web browsers. Firefox is getting a much greater market share, almost on a daily basis. They are gradually eating away at Internet Explorer''s dominance. There is also Opera, there are text based browsers, there are Mac browsers like Safari, a lot of people viewing the content with different web browsers, different screen resolutions and the audible web is not just for people who are using screen readers any more. There are now products available that are marketed to a mobile work force where you can call in using a wireless phone and access the web using speech commands and getting speech output. And so web accessibility is an issue for users of those devices as well as people with disabilities. And so it really is a broad spectrum of users who are affected by web accessibility and so providing support to web developers to ensure that their websites are going to work for all of these devices, it becomes an add-on. It is something that you can do as a support to them. It is important to sort of integrate that into an educational entity''s planning process. Be sure that that support is there and that it is perceived as support. And then finally, after all of this planning is done, consider supplementing your efforts with web accessibility evaluation and repair software. So there is a lot to do and educational entities tend to have a lot of websites. I know at the University of Washington we have hundreds of thousands of known pages just on the centrally supported web servers. I think the last time I asked it was something like 600,000 pages that the central computing group hosts. That says nothing about all of the servers that are out there that are hosted by departments and not centrally supported. And then informal websites, professors who are hosting their websites offsite and so forth. So it is daunting to say the least to try and go in and make all of that accessible or even to assess how accessible it is. So there may be a role for software tools that can automate all of this, you know, within the planning process. It may play an integral role in an institution''s accessibility. So how can software help? Well, it can spot problems that you might have missed in a manual inspection, so as you look at a page and try to figure out what is inaccessible about it, you might be able to spot some things. I have been at this for over 15 years so I tend to think I can eyeball a page and figure out what is wrong with it but even I will sometimes miss something that an automated tool will find. I will say, oh, well, I overlooked that, but the tools will help me to find these issues. The other is a site wide benchmark. You can use this to spider your entire site and give you kind of an overview of where you are with regard to accessibility. Then as you implement some web accessibility improvement efforts, training and outreach and promotion and so forth, then to go back again in three months or six months and a year and see how much your accessibility has improved and use that as an incentive to continue your efforts and try to get those numbers to continue to grow. It is also a great tool for educating web developers who are struggling to understand web accessibility. If they learn about web accessibility through a review of a page that means something to them, you know, a page that they have developed, then that is going to be a more meaningful education than if you use some demonstration site that they have no personal relationship with. So it can be helpful for learning. Because of the fact that these automated tools really can only assess so much, there is a limited amount of accessibility checkpoints that can be assessed automatically, then education really becomes a key factor. Typically the way a product works is it will assess those things that it can automatically and then for all the other things, it will say this could potentially be a problem, you have to look into it manually. And then it will give you some information about, you know, what that checkpoint means and how you do go about evaluating it manually. So just sort of that coaching that it provides and that additional information that it provides is a great way to learn about the different web accessibility guidelines. On the handout there is actually a number that I neglected to plug in there prior to sending this off, but it says many aspects of web accessibility are subjective, only X percent can be automatically assessed. If this was a live audience, I might ask for some figure there, you know, what do you think it is that software can automatically assess. But since I''m just in an empty room talking by myself, I will tell you that it is 27% according to the folks who developed Bobby, that 27% of checkpoints can be automatically assessed. The balance, 73%, has to be verified by manual checks. So web accessibility is very different than HTML validation or CSS validation. It really is, there is a lot of subjectivity involved and so you really have to do some manual inspection and the software tools then are limited, inherently limited in what they can accomplish automatically. Tools are also known for false positives and false negatives. I have seen some of these firsthand. So that is a concern. Certainly we don''t want incorrect information, we want whatever these tools are coming up with to be accurate. And as development continues, then they are able to get rid of some of those bugs that would trigger that, but because of the wide variety of ways that people code web pages, there still are things that can trigger a mistake in tools such as this. And for an educational role, I mentioned that these software tools are helpful for educating web developers, that needs to be something that is considered as you are looking at products. Do they do a good job of educating? Are they good teachers or do they present users with just an overwhelming volume of information using technical jargons and users aren''t able to make any sense of that. Some do a better job than others at providing information. So the question then of whether the software is effective comes into play and I mentioned there are false positives sometimes, false negatives sometimes, confusing output can be problematic. So do we have any sort of research that identifies whether the software is effective or not. Well, there is a study actually done at the University of Washington by a professor named Melody Ivory and her associates. She no longer is at the University of Washington and I wasn''t able to find a lot of the content that she used to have up on her website is no longer there, so I''m not sure where to find it now. Although the URL that I gave in the handout, it is very long and cumbersome, but it is still available at scholar.google.com and so you can either type the URL in or just go to scholar.google.com and search for the title of this article, which is a study of automated website evaluation tools. It is the best research I have seen on the effectiveness of the software products. The way the study was set up is she had nine experienced web designers and they had some specific criteria they had to meet in order to be qualified as experienced, many years in the field and having developed X number of professional websites, and they were asked to modify five websites, websites that were created specifically for this research and they were given 20 minutes on each, each of the first four. There is actually another mistake in the handout. Sites 1 through 4 they were given 20 minutes on and site 5 they were given 40 minutes on. The first site they had to try and figure out the accessibility problems with the site and they had to fix them. In the first trial, they had to do this manually using no automated tools. Second trial they had to use Watchfire''s Bobby. Third, they had to use the W3C''s HTML Validator. The fourth, they had to use Usablenet''s LIFT products and the fifth, they can use whatever they wanted to. Given they had just gone through these first four trials, they can then pick whichever tool or combinations of tools they liked best or they can use any or all of those. The results were that, the automated tools did reveal more problems than they found manually. So there were some things when they manually evaluated a page for accessibility they overlooked, and the tools were able to spot those things. The more questionable results though is that there were no significant differences in the number of problems that were corrected. So they were able to find what was wrong within the allotted time which was only 20 minutes per site and then 40 minutes for the final site. During that amount of time, they were not able to make more corrections using the tools than they were just manually. So they didn''t in this sort of control environment provide any sort of boost in terms of the final outcomes being more accessible web pages. So I guess the question whether this controlled sort of environment is really telling of what is happening in the real world. Then how much time would a web designer devote to try and make their web page more accessible and maybe it will be realistic that 20 minutes or 40 minutes is about the extend of what they are going to put forth. If you know, if after 40 minutes they can''t understand the report that the tool produces adequately enough to go in and make some of the changes that it is recommending, then they are probably just going to say that this is too much and I''m going to put it in the back burner and then they never get back to it. So, that is a concern and an issue. On another study that I didn''t actually referenced in the handouts, the study that I did along with Dan and Cheryl, at the University of Washington, a couple of colleagues of mine. We evaluated, Dan and I evaluated manually, using a process that we developed for efficiently manually evaluating web sites. We evaluated 10 pages at each of the major research universities in the United States, public, just public research universities. There are 102 of those. So each of the 102 schools that we looked at 10 specific pages. These are all high traffic pages, like the homepage and the library page, the search page and several others. So we developed this process and did quite a bit of work to make it a process that was easy to implement so it would have cross-raters and inter-raters reliability. Dan and I evaluated the pages and we also had our companion Bobby do an automated assessment of the page. And then we would assign a score to the page, basically pass or fail. If Bobby, using any of its 27% of things that it could automatically assess, if it found problems then it would fail and if it didn''t find any problems then it would pass. We correlated our findings, our human findings with the Bobby findings just to see if we could do a better job than Bobby could or if we always agree. What we found is that Dan and I were positively correlated at a fairly high level, so we did have inter-rater reliability between ourselves and Bobby was actually roughly the same correlation value. So our results were highly positively correlated with Bobby''s. So, that show that for benchmarking, for looking across a wide variety and vast volume of pages, that using Bobby is a reasonable assessment. We did actually find in our study that some false positives and false negatives, where we rated pages poorly, Bobby said they were perfect and vice versa. So they are individually I think that the short comings become very visible. So that it becomes something when you are looking at individual pages that you really need to look at. But for broad benchmarking web pages, then I think maybe the software products can be more useful. So just to reference that, that website if you wanted to read more about that article, it is in the ITD Journal, Information Technology and Disabilities Journal, which is put out by EASI, Equal Access to Software and Information. You can go to their website at easi.cc and there is a link right there on the homepage to ITD journal. This is in Volume 9, which was published in 2003. So there is also another resource that I will turn you on to is the AccessIT knowledge based article we have written called "How can I select a web accessibility software tool?", and that goes into quite a bit of depth as far as the questions that you might ask in exploring this with vendors of these products. What operating systems are supported is one of the questions you might ask. If you are a Mac environment, then you probably want to pursue a product that will work on Macs. Which sets of accessibility checkpoints are predefined, so you don''t have to do a lot of customization. You know, most of them do support the W3C guidelines and Section 508 standards. But if you have a set of custom guidelines that your educational entity has implemented as your policy, then you will want a product that is customizable so that you can go in and check which checkpoints you want to assess so you can test compliance with your institutional policies. Is the tool able to automate repairs? If that is important to you. Is the user interface accessible itself and usable? You would think that products that focus on accessibility would be accessible, but that isn''t necessarily the case. These products do have a number of issues that prevent them from being usable by people who use assistive technologies, so you will want to get an up front answer about that. Sometimes you can get, you know, honest information from the sales folks but sometimes you need to be able to evaluate the product and if you have employees with disabilities that are going to be interacting with the product, you know, try to arrange for them to check it out and make sure they can use it effectively. Does the tool assess site quality issues beyond accessibility, so that can be important. It is a nice value add, but it is also important in terms of selling accessibility to the folks at your institution that are developing websites. If accessibility is bundled in with other quality issues, then, you know, it becomes a very good thing. It is something that is looked on favorably by the people that have to use it and they are more likely then to use the tool than they would be otherwise. Spelling is one of those things that people will be interested in, a site that is able to check their spelling site-wide. Does the tool include page preview filters, if that is a desirable feature. Most products are able to spider or crawl an entire website or domain, but if you are doing site-wide web accessibility management, then that will be an issue that you will certainly want to make sure that feature is available. Can the tool follow non-HTML links? This has been a problem in the past where links are coded with Java Script, which they shouldn''t be, but a lot of sites do that or maybe links are buried within a Flash presentation. Some tools are able to follow those links and some are not, so that will be an important thing. If you have content on your website that has links that are not HTML, then that is going to be an issue. Otherwise it can only spider your website so far and runs into a brick wall when it encounters content like that and it is not able to follow links to get to some of the other pages on your site. Can the tool assess the accessibility of any non-HTML content? So not only can it follow links within Java Script or Flash, but is it able to do any assessment regarding the accessibility of that Java Script or the Flash or accessibility PDF. And this is a moving target and it hasn''t developed much yet. Most of the tools are specifically focused on HTML, but there are some that do claim to have some capabilities of processing. Some of these other non-HTML types of content. How does the tool handle potential obstacles? Just password, cookies, required form fields, session IDs and things of that nature. That is an area where every environment is different and the types of obstacles that you have are different and so you really need to have the opportunity to try out a product in your environment and make sure that it is going to work, you know, with the particular obstacles that you might have. Does the tool have built-in features to facilitate web accessibility project management? If it does, you are going to be spending a lot more than you would otherwise for those features, but that might be something where if you have the resources, it could be beneficial to you. Just to really, you know, get a very active web accessibility project implemented and to have a high end software product that supports that. And then there is several questions regarding results and how the results are presented. How are they presented. Are they exportable, can you run the tool from a command prompt as part of a batch process, can the tool, is the tool available as a software development kit so that you can customize it. These are all questions that are important for any educational entity that wants to really do some customization with how the information is presented. So since one of the problems, the problem shown in Melody Ivory''s research is that the reports are difficult to understand and I think maybe the problem is that they present just too much information and it is difficult for web designers to sift through all that. But since that is the problem, then maybe that information could be filtered in some way or maybe it could be presented differently. Maybe it can be customized so that it is most meaningful for web developers at your institution. When I was at North Carolina State University, that is one of the things we were looking at within the information technology division, was building an application using one of these products as kind of the core engine, so these products could check accessibility and then export a report but it would do so in a format where we could then take the data and present it to web developers in a way that we saw fit. And, you know, we were wanting to build an application that would send an automatic e-mail out periodically to owners of particular web spaces and it would provide some accessibility feedback as a support to those web owners, web authors. And so in order to do that, you are going to need a tool that does export the content in a way that is most meaningful. So I''m actually going to back up within my presentation to the previous section at this point because I skipped a section. And that is regarding a new effort, recent effort that the W3C is taking on, and it is called the Evaluation And Report Language or EARL. And that is designed to meet the needs that we have just been talking about, an exportable format for the results from tools like this. It is not, designing it is not limited to accessibility. It could be any sort of Validator or any sort of assessment tool.
Is now a good time after you finish this quick section to start the Q & A?
Yeah, I have got just one more section I want to talk about after the EARL section and we will have about 20 minutes of Q & A, so I''m about to wrap it up.
Okay, great.
So EARL is an XML language that organizes the report information and it is just in draft, very early draft now. They are still working on it. Once they finish it up, then they will be able to, ideally they will get some of the web accessibility evaluations tools and other validator tools to subscribe to it and then the output from the reports will be exportable and people will be able to use it in ways that is most meaningful for them. The only other thing I wanted to talk about that is Usablenet LIFT Text Transcoder, because it is a product that is widely visible out there and they are marketing it pretty extensively. And at last I saw, I think they had 150 higher education institutions that are subscribers to this. And it is a multi thousand dollar product. But what it does, is it creates a text only version of web pages, which that alone sort of makes a lot of long-time web accessibility advocates sort of bristle because text only is not something that is viewed favorably anymore. Ideally you work with your existing web page and make it as accessible as it can be, which usually is fully accessible. There are few things that can''t be accessible in the front page and there is no reason to have a back door page specifically for people with disabilities, a separate version, that type of thing. But one of the reasons that text only pages has been criticized over the years is that people tended in the olden days to create a text only page, let it sit and then they would update their graphic page and not go back and update the text only page so it became obsolete. What the Text Transcoder does, is it on the fly generates a text only version. And so there is no maintaining a website, maintaining a text only version required, it does it automatically. So what it doesn''t do, is it doesn''t fix inaccessible content. So, if you have a page that has graphics and no alternate text on them, it can''t do anything with that, any more than a screen reader can do something with that. So the danger with this tool is that it is not an accessibility solution, not a complete accessibility solution. It can do some pretty neat thing. It can take the existing content that is accessible and structure it in a way that works best, particularly for somebody with a screen reader and that really is who the product is designed for. Since it does it on the fly, it is using the existing content from the main page. And this works across the entire website, so you license it for a website and so any page that a user goes to on your website then, they can just continue following links and it works, continues to render text only pages. So it is not a bad product. It does a lot of neat things, but the danger is that, a lot of the 150 educational entities perceive it to be a complete solution and it is not that. It might be, you know, a band-aid that can make things a little bit more accessible than they would be otherwise, but, you know, an educational entity still has to do the work to make sure that their website is accessible, the front end website is accessible. And so we do then have 20 minutes for Q & A, so I want to open it up for any questions that folks have.
Can you talk more about the EARL aspects of this talk? Will various developers be complying with that or is that a W3C only feature?
It is tough to say at this point. With anything that the W3C does, they work usually over years to develop a specification or a recommendation, and then it is up to the different user agents or tools out there to support those recommendations and so one example of that is with cascading style sheets, the W3C came out with a CSS recommendation and the specification for what that CSS language is, and then browsers implemented it a little bit. Some of them took some liberties with it and implemented it incorrectly. Over the years it has taken many years to get to where CSS is pretty widely supported and pretty accurately supported across browsers. At this point EARL is much earlier in the process than that. As I understand it, the software web accessibility evaluation software companies have had some in put into EARL so they do have an interest but it still remains to be seen. Once W3C issue this as a recommendation, then we will just have to see whether the tools support it or not.
Thank you.
Thank you. I use magnification software and I had a comment that it took me a long time to find this out. If you use the high contrast feature in Windows, if it is checked, it will overwrite the page so that the background does not appear correctly and it will also make the language, the dot CFM page huge and very hard to read.
That is a good point. Those are some accessibility issues that need to be watched out for. There are lots of issues like that even though web accessibility evaluation tool wouldn''t necessarily assess those types of things. So there is no substitute in the long run for understanding web accessibility and understanding the variety of ways in which people are accessing technology and the types of technologies they are using.
We have a question from someone from our streaming audio and it was regarding Flash accessibility, wanted you to comment on that, Terry.
Well, regarding Flash accessibility as a whole, Macromedia has been working to improve the accessibility of Flash and since Flash MX was originally unveiled, there is an accessibility panel from which you can assign alternate text to various elements of the Flash page and you can control tab order and various other accessibility things are available when you use action script to script within the Flash environment. So there are some accessibility features built into Flash now. It is not I wouldn''t say that it is fully accessible because the accessibility features are only, they only work in Windows and so somebody is using Linux or Mac or some other operating system, they don''t have access to that. It also requires that assistive technology support those accessibility features and so, currently there are only a couple of screen readers, the late versions of JAWS and WindowEyes are the only ones to my knowledge that support accessible Flash. If you are using anything else, it is going to be inaccessible. In terms of assessing Flash for accessibility, there is only one product to my knowledge, and I guess I can mention it by name since it is the only one, but High Software claims to have a tool that interactively allows you to assess the accessibility of Flash. I haven''t looked at that feature myself, but it is a wizard that because Flash animations are interactive typically, then you kind of have to interact with it and tell it what you would expect to be accessible in order for it to then give you feedback about whether that is accessible or not. But that is something that you could check with Highsoftware.com and try to find out more how they are assessing Flash accessibility.
Hi, thank you. Actually you have already covered two of the questions that I had, which I was curious about your opinion on cross browser compatibility with CSS and also Flash, which obviously you just talked about. My other question was do you have any thoughts on ways to code beyond HTML that web developers should look into as far as accessibility things that are on the horizon, like ASP pages or things like that?
Well, any server side technologies, scripted pages, such as ASP and PHP and so forth, they deliver ultimately HTML to the user, and so there really aren''t accessibility problems with that as long as the HTML that gets delivered to the browser, to the user is accessible. So with Java Script and other client side scripting languages that work within the browser, then those are kind of a mixed bag. There is some things you can do with scripting languages that are fully accessible and other things that create a lot of times will create some change on the page that is not perceivable to somebody who, you know, isn''t aware that something has changed. So screen readers, for example, might not see a pop-up that happens because of some Java Script behavior. Somebody who is using magnification, you know, they might be focused in on a small portion of the screen. Something happens some where else on the screen, they might not be aware that that has happened. So there are issues such as that. The more dynamic content gets, then you encounter those types of issues. So I think that you really need to focus on developing content that will work for everyone and the standard for if you have scripted content, it is okay to do that but the standard is to ensure that it is also accessible to those who do not support scripts. So if there is assistive technology that doesn''t support scripts or somebody has scripts disabled on their browser which a growing number of people do because of security concerns, then the content still needs to be accessible and usable to those individuals.
Thank you. The last question was about Java Script and you have answered it. Thank you.
Ok, and just a comment about you also mentioned cross browser compatibility of the CSS. The standard there is that even though browsers are getting better at implementing CSS, it still is possible for users to turn it off and there still are some problems with cross browser compatibility. But the issue there is that the content should be accessible even without CSS. CSS actually should be used to control the presentation that way you attain full separation from content to presentation which is a good thing but people without CSS at all or who use custom style sheets should still be able to access your content. So it is kind of a balancing act. Use CSS but don''t use it in a way so it will prevent access.
Thank you very much. Thank you for your time.
I am a screen reader user and do any of these tools go into the documents themselves on the site, including having PDF files written accessibly, in other words, not the imbedded image files?
You know, I''m not sure at this point. Again, that is one of those moving targets where I''m not sure at this point if they can assess, if any of the tools can assess automatically whether PDF is accessible. So I mean just in terms of there would be some simple things I think they could do, such as checking to see if it is a tagged PDF or not. As you have pointed out there are image PDFs and there are a couple of steps above that PDFs. The only PDF that is optimized for accessibility is known as a tagged PDF as an underlying tagged structure and it allows alternate text for images and so forth and so I would think that these tools technically would be able to go in and sort of pick apart a PDF in the same way they can HTML, because PDF is a proprietary document type as opposed to HTML which is just text. Then they are going to have to work with Adobe to gain access to that. But I suspect that, that sort of work is already being done. I''m not aware of any tools at this point that are able to do it, but they may be out there and I''m just not aware of them. If not, I suspect we will be seeing some sometime soon.
I have a question from the audio that kind of plays, addresses some of the PDF. The question is does Terry recommend the new Adobe tool for converting PDF to accessible formats?
I don''t think any PDF can be converted automatically. There are adobe''s tools and then there are other tools as well that are able to convert PDF to text. You can even see that on Google if you, you know, go to a document that is natively available in PDF, then Google will provide it to you in an HTML version as well and it does its best to create a document that is readable, but a lot of times it is not. The issues with PDF are so incredibly complex that there is no substitute, I think, for following all the steps. Adobe has a manual for how to create an accessible PDF that is something like 150 to 200 pages long. So it is not an automatic process. We have actually at AccessIT we have done there is an article, if you go to www.Washington.edu/access IT, that is our project home page. From there you can go to our knowledge base and search for topics that meet your needs. We have actually written an article on PDF that links to some other resources as well, to kind of give you an overview of PDF accessibility issues. They are pretty extensive. I have actually done online trainings just on PDF accessibility that were three hours long. So it is not a simple solution and not simple enough that an automated tool can just, you know, convert something with any sort of reasonable reliability.
Hi, Terry.
Hey.
One thing I was wondering, is the Usablenet LIFT Text Transcoder, that is not considered 508 compliant, is it? And also isn''t the same thing occur if you just turn off Style Sheets instead of using that Text Transcoder?
As far as the first question, is Text Transcoder, I guess you are referring to the solution they are offering, is that a 508 compliant solution, right?
Yes.
The relevant standard there within Section 508 is that something to the effect of if you have exhausted every other possibility and you can''t make your web page accessible, then a text only alternative is a solution. And so I would agree that, that doesn''t really fit within that model, that they are creating a text only solution and the you know, and the front end page may not be accessible and in fact it could very easily be accessible. So you are correct, that is not going to meet Section 508 compliance. In terms of CSS, it actually, Text Transcoder actually does some things beyond just what CSS can do and it is a fairly sophisticated tool where it is able to make some intelligent assessments about, for example, if you have a banner image, a large graphic that has ALT tags at the top of your page, then the text only page will mark that up as heading level 1. You know, it will take the ALT tag from that and assume that that is a heading level 1 within your page. And it will do the same thing with what it perceives to be heading level 2s within your page so it can actually add document structure to the page based on the way your pages are formatted. It also makes some intelligent decisions about the images on your page. So if there is no ALT tags whatsoever it is going to just toss it out so you have no access to that whatsoever. But if there are spacer images, which a lot of times have predictable names like spacer.gif, then it detects those and tosses them out too, even if they have ALT tags. It can be a very cumbersome experience if somebody using a screen reader goes to a page and it says spacer, spacer, spacer, spacer, spacer, then this eliminates some of those types of issues. So the page that it creates, although it doesn''t fix all the accessibility solutions, it does hide accessibility defects in a way so that it makes a page more usable than the original page might have been. So that is why I say it is a pretty decent tool at what it does, but people need to be careful not to perceive it to be a complete solution. They still have to add ALT tags to their images and still have to markup tables and forms and so forth to be accessible and do all the things that they would have to do otherwise. So if anything, it just sort of provides it a temporary fix until they get to the point where they can do that.
I have a quick follow-up, real quick question here. Study design you had talked about earlier talked about experienced web designers. A lot of people come to web design in a lot of different levels. Do you think tools are more important for a lower end or who are not as much into a high end web designer as it was in the study design and everything? What do you think on that, on where the best would tools be more important?
I think that everybody can probably benefit from them. The existing tools, I''m not sure that there are any that out of the box I would recommend for a novice web developer. I mean my approach when working with, you know, say the administrative assistant who is charged with maintaining a departmental website and they do it in Microsoft Word and save it as HTML because they really don''t, they have no idea what HTML even is, those are folks where if they ran on their web page through Bobby, it is just going to completely overwhelm them. The research showed that even these professional designers with experience were not able to respond, you know, to the reports from these tools, and so somebody who is a novice, really they don''t need so much information. So my presentation tends to be much more filtered or I will say your graphics need to have ALT tags and they probably aren''t including complex nested tables or complex forms on their web pages so accessibility issues with those, we don''t even need to burden them with that necessarily. So that is where I really see there being value in a filtered message. And maybe EARL will provide that or maybe some of the tools currently do, reports that can be customized so that you deliver users, you know, information that they can truly utilize and that doesn''t just overwhelm them with too much detail.
Thank you, Terry. See you in Arizona.
I think that we have time for just one more question, Terry. I do have one on the streaming audio. This person says that from experience I have found that Google, the results page is hard to navigate due to embedded table markup. Have you heard if Google is working towards improving this, and how willing are they to comply with W3C accessibility standards?
That is a good question. I haven''t heard a specific response from Google on that particular issue. I know that folks have approached them about other accessibility issues. As Google branches further and further into, you know, new areas, then you know, and they are becoming a much more central resource in everybody''s lives, then it certainly is in everybody''s interest that it be accessible. So I know there are people working with Google and talking to Google but I really don''t have any sense as to what Google''s response has been. But I encourage anybody who is listening to, you know, take up that bit of advocacy that is required. If you spot issues with accessibility of Google''s site, then be sure and let them hear about it.
Great. I think we will wrap it up now. I just want to thank Terry Thompson. It was extremely valuable to myself and to I''m sure all of the listeners. Thanks for sharing your knowledge and your expertise in this area. Just a reminder that there will be the handouts and information on the website, www.ada-audio.org. The audio transcript is posted within five days and written transcript is usually posted within seven days. So please feel free to check back for those resources. There is the second session for the accessible information technology series on December 13th. It is on accessible web-based communication tools and why they are so hard to find. The speaker is Steve Jacobs, so I encourage people to sign up for that if you haven''t already. And then if you have questions on technical assistance or you want to contact your local ADA and IT center, you can call the 1-800 number, 800-949-4232. And that is voice and TTY. Or the website, www.adata.org will give you the center that serves your area. Thank you, Terry. That was great. And that takes care of our audio conference for today.