Computing at UW-MadisonDivision of Information Technology
Students Faculty/Staff Services Services A through D Services E through L Services M through R Services S through Z Help Desk Tech Store About DoIT   

Accessibility

Tools and Techniques for Accessible Web Content

Part Two: Functional Accessibility Evaluation Tool (FAE)
Transcript

JON: Let's get started with the second half of the webinar, which is on functional accessibility evaluation. Let's see, is everybody, Christy is everybody back? I know we can't tell if they're back on the Internet, right?

Typically, a lot of Web developers, when they think about accessibility, kind of the process seems to be, you know, they kind of create their Web resources using whatever techniques that they usually do. Maybe they have a template they create because then they replicate that for all of the content, or different templates.

Then step three is, okay, somebody told me how to do something about accessibility, so I go, and look at the guidelines, and I find some tool that maybe will help evaluate my websites. Then it gives me a report, and I see red things. Red things are bad, I know. If I see red things, I want to get rid of those, so I try to get rid of those first. There's typically a list of all of these manual checks that I have to do. Well, some of them I understood, and some of them maybe I didn't understand, you know, like did I use markup correctly?

Well, you know, most people take a step back and look at their codes, and, it looks pretty good to me. They really may not misunderstand what it means if they used markup correctly. They do this process until they either run out of time, or the little, red things go away. Some of the limitations of that though is most current evaluation tools that are probably available, or even ones you buy, I don't know if you purchase some here, but they only actually check for a small number of accessibility issues, typically, alt text for images, maybe labels for form controls, depending on the tool you're using.

There's a lot of other things that are important for accessibility, like using headers properly so people can find the major topics on a Web page. It's an important issue. When people use this approach for accessibility, I call it more technical accessibility. It looks like you satisfied, or potentially satisfied, some requirements, but you really don't know how functionally usable your website is by people with disabilities.

And this repair approach, again, makes accessibility look like a burden. If it's done late in your development process, you're already kind of tired of working on the website. You think you've done 95% of the work, and now, I have to go back and do this kind of stuff. Well, you know, that's not enjoyable to everybody and, again, puts accessibility kind of in a bad light. It's a problem, and it's hard to do. In the accessible design process, what we want to do is put the accessibility stuff up front.

We created design templates based on both Web standards and functional Web accessibility techniques. So like at the U of I, kind of our strategy towards moving with Web accessibility, we don't have a formal policy yet on accessibility, like UW-Madison does, and I used to look at that as kind of a problem, but we're trying to use it as an opportunity.

What we're trying to do is as people redesign their websites, to have them use specific, what we call our Best Practices for Accessibility, based upon Web standards and the markup needed by people with disabilities, as opposed to saying, okay, you've got to fix your website to be accessible. Kind of our current approach is, let's wait until it's being redesigned and then get the accessibility stuff up front because it doesn't cost anything.

If we have to go fix websites, that will take somebody that has to go in and fix them, and we still don't get our functional accessibility because oftentimes, based upon the markup that people originally use, they'd have to redesign the whole website anyway.

So from an administrative point of view, I think that's an important strategy because we want to have accessibility looked upon in a good light and not as a burden, especially to deans and department chairs because if it comes to them as looking like it's going to cost something, they're going to do the minimum they can, or they'll delay doing it for as long as possible. I assume that Wisconsin, and other campuses I know out here too, are having budget crunches.

I know our campus, our esteemed Governor has cut our budget, I think, every year for the last four years, so less and less, well, he campaigned on the promise that higher education was getting too much money in the state, and he's lived up to his campaign promise. He's cut the budget every year. To his credit, I guess he's putting it into K-12 education. He's put that money back into K-12. But it still means less money to the provost, less money to our deans, less money to our departments. There have been cuts in staff and stuff so people are already tight.

When you create the Web resources, all you want to do is verify the use of these standards of accessibility techniques. So we can build tools that can be more automated and tools that are basically looking for any type of accessible markup. So what are functional accessibility features?

We have kind of five major themes related to functional accessibility features, so the people in Internet Land will have to scroll their Web page a little bit. I can scroll it here so you can see. These aren't really new standards. They're basically techniques to implement 508 and W3C Web content accessibility standards. For one, developers can know that they're actually creating functional accessibility features.

We have a lot of Web developers that say, well, how do I know I've really helped people with disabilities? If they're designing new Web resources, we can just say, use these techniques. And they're the same techniques, pretty much, that the Web standards people tell people to use. So we get interoperability. We get all of those nice things about the original intent of the Web. I can write something once and have a wide variety of technologies access it, both future technologies, current technologies, and legacy technologies.

So for navigation and orientation, and this is typically the stuff that's left out of current evaluation tools. These are the manual checks. Do I uniquely title my Web resources? So if I'm using speech output and can't see that the whole screen changed, can I look at titling information to know what sub-page I am on in a Web resource?

The use of headers to indicated major topics on a Web page, extremely important not only for people with visual impairments, who can use that to navigate to the topics, but if I have a physical impairment and can't use the mouse, I can use the header navigation features of like a browser like Opera to allow me to more efficiently navigate to links on a Web page. How many people here are familiar with the Section 508 requirements? Okay. So you're all familiar with the Skip Nav feature? So what do you do to implement Skip Navigation? Personally do you have a favorite technique?

Okay. Like an internal target link? Okay. Anybody else do anything different? Yeah, back here? A spacer gif, okay. IF IE would have had one feature, we wouldn't be talking about any of these features. Do you know what that one feature in IE is? Header navigation.

If IE would have allowed people to use the keyboard to navigate headers, you wouldn't be talking about any Skip Nav's. You wouldn't be talking about invisible GIFs and all that stuff. All they would have said is to use headers and to use them properly. Then people could have navigated not only two navigation bars or over navigation bars, they could have navigated two navigation bars and all the other major topics on a Web page. But the way 508 has been implemented, and people have interpreted it, it's that, well, it's the author's problem to do that.

That, again, reinforces the idea that accessibility is this weird stuff that people with disabilities only need, right? The spacer GIF is because only screen-reader people need to know about this. Well, what about the people with physical impairments who don't want to tab through all the navigation bars?

There is lots of stuff out there. I was part of that for a while. I just tell people to forget that. Just use headers. There's enough, oh, we have a question?

UNIDENTIFIED SPEAKER: Does IE7 do that?

JON: . . . the Beta version I have does not. Again, if anybody has any contacts with the IE team, tell them that, hey, it would really be nice to have built-in header navigation. But there's enough assistive technologies out there now, and browsers like Opera and the Mozilla Firefox extension that we'll talk about later in this session, that has header navigation features with the keyboard. So I tell people, forget about all those techniques, and just use headers.

Then you get the benefits, you know, you get the styling benefits of headers with CSS for consistency and things, and we're not doing something special just for those people with disabilities because we want to eliminate those because if it's just for them, again, people will be confused. They'll look on the Web, and they'll see 50 different opinions about how to do it. And you're still not sure if they did it right. A lot of people don't want to have that skip link on their page. It doesn't look good, so I'll hide it with a GIF.

Things like navigation bars, data tables, language changes, list markup, using the structural features in HTML, most of the current tools don't check for. Text equivalences are for like images and graphics, audio and video, having transcriptions or text equivalents for images and graphics, scripting, making sure we support the keyboard. If content is being generated dynamically, is it being done in an accessible way?

One of the big things we push with the tool, are people using CSS for styling text, for layout, for creating graphical styling? One of our developers who has embraced these techniques, Doug Burget(?), he works in our Office of Admissions and Records, and he redesigned their website this past year. On our campus, I don't know if you have an equivalent group here, but in our campus, we have something called the Campus Webmasters Group.

It's a collection of webmasters from all across campus, and they have weekly seminars. So somebody will speak on a topic. They'll bring in a speaker. Once a year, they have like Web Developer Day, and they'll bring in an external speaker, typically a nationally known figure in some Web accessibility topic, typically usability or CSS, some hot topic that's been coming up. And they have awards, the Campus Webmaster Award.

Well, his new website for the Office of Admissions and Records, won the campus webmaster's board is the best site. Well, he's using all of our Best Practices techniques, or almost all of them. So he has a highly accessible site that was voted by his peers to be one of the best-designed sites on campus. And they didn't vote for it because it was accessible. They just thought it was a well-designed site.

UNIDENTIFIED SPEAKER: What is the site?

JON: Office of Admissions and Records. We could deviate there for a minute so people can take a look at it. This is the OAR website, using all CSS techniques for layout, and features, and for developing the navigation bars and things, so an example of a website that can be highly graphically interesting, yet still be highly accessible to people.

And so we estimate how much content is being styled with CSS. How much is being styled using inline styling? Are you using liquid design techniques? And then are you supporting standards, HTML and CSS standards, so that you get that interoperability? Are you validating your documents or have the capability?

UNIDENTIFIED SPEAKER: What is liquid design?

JON: Liquid design is Web pages that adapt to the graphical width of the screen. I don't know how it will work here. This page is a liquid design, so if I change the width of the screen, I don't think anybody out in Internet Land can see this, but you can see that the text reflows to fit the width of the screen.

So if I had a PDA device with a small screen, text would wrap around, and so there's a number of, if I had a high-resolution display or a low-resolution, I don't have to decide what I'm going to design for 1,000 pixels wide. I just use liquid design techniques, and it will adapt to the width of any screen. And it's becoming more popular, especially in the Web standards, as the number of graphical, we have some more questions?

UNIDENTIFIED SPEAKER: Doesn't that create really long lines of text on high resolution?

JON: Okay. Sometimes it does create long lines, and there are CSS techniques to truncate that too. But, again, users can make choices. They can make the window narrower too. One of the advantages of liquid design is that probably most people, if they have a high-resolution monitor, aren't going to have their Web browser open to the whole width of the screen. One of the things they'll probably want to do is I may have two browsers open and comparing information from two sources of content.

So if you were looking at all those different techniques for Skip navigation, you might want to look, well, is this person saying the same thing as this person, and you'll want two windows open at the same time. Well, if they're using liquid designs, you can maybe have three or four things and compare the stuff, whereas, if they're using fixed-width designs, you're always doing kind of horizontal scrolls and things. So, again, the user can choose to make the screen narrower to make the lines shorter too.

Again, users have control. Do we trust users to make their decisions? Sometimes that's not a good idea, but I think as users learn about that, well, liquid design is a good issue because we've talked a lot about that on our campus, and someone implemented liquid designs on their campus. So I asked them, well, how is it going? Well, one person in our department doesn't like it. Doesn't like it? Well, what's the problem? Well, when they move their window, stuff moves on the page, and they don't like that. Well, you mean that they can't access information? No, they just don't like it that stuff moves when they change the window width. They're not used to it. So there is a change there. People aren't used to that. They're used to, well, everything stays where it is.

So with liquid designs though, things don't always stay where they are, so that's a change in thinking. But I think as people come to see that, and they see the benefits of it, I can now start to look at more than one document without having to do horizontal scrolling. You know, people come to see it as a feature, as opposed to, oh, this changed it. It's not really a problem, but it's a perceived problem because they're not used to it.

I'm sure you all have users of your websites that any change is a problem, even if you're changing terminology, or the color of the background, or whatever. But it makes Web pages adaptable to a wide variety of technologies. So this is our Best Practices website. I'm not going to spend a lot of time on that, but this lists the techniques, how it relates to the W3C. For example, under navigation here, if we go to navigation requirements, what does that mean to have unique titles?

So we talk about the markup involved with that, how it relates to both Section 508 and the W3C Web Content Accessibility Guidelines. So, again, these aren't a new standard. It's techniques to implement current standard, and as WCAG 2.0 comes out, we'll map into their requirements too. Okay. So slide five here is just a typical example of a report generated by WebXACT, which I guess now doesn't exist anymore, or the link to their URL doesn't work. But it's typical of a lot of accessibility checking tools, where you kind of get a list of potential errors, known errors.

You can see that there's a lot of manual checks here for this particular Web page, 12 warnings, 16 warnings, 153 instances, so a lot of line numbers. And there's a long list of manual checks that you'd have to go through. Most developers don't have time to go through all of the manual checks. Even on a single page, that might take five or ten minutes, maybe longer, and if you have 30 or 40 pages, you could be spending days going through your Web pages.

And, really, and then just think about Web applications because I know like on our campus, it's nice to have accessible home pages, but where do the students spend most of their time? Course management systems, e-mail systems, financial aid systems. They want to know, do I have money available for me to pay my rent this month? What are my degree requirements? Am I going to be able to graduate this semester? What do I have to take next semester?

These are all applications, thousands of different states. Could you imagine doing manual checks on all the different states those could be? So we need new tools to look at these new technologies. So we've been developing a tool called a functional accessibility evaluator tool, called SAE for short. What it does is measure HTML markup associated with our Best Practices. So if you're using the Best Practice techniques, it will give you an estimate that you're using them. We want to apply reports that are useful to both managers and Web developers.

That previous report had a lot of jargon in it, a lot of details. Well, you'd never want to give that to your manager and say, oh, well, we have to fix this stuff. They would have no clue about it. So we wanted to have the tool support managers too. That was really important to us. A big emphasis for this tool is that our Illinois Board of Higher Education is now requiring all higher educational institutions, both community college and four-year institutions, to report on their current state of Web accessibility and their plans to improve accessibility.

So, all of a sudden, a lot of administrators who haven't even thought about this are now having to at least have people have to sign off on a report that they're sending to their primary funding agency because all the money of state universities goes to the Illinois Board of Higher Education. So this is a new policy requirement of the new president, who has an interest in disability access.

We link to the Best Practices and other tools to help people understand accessibility. So here's an example of . . . so this is the front end of the functional accessibility evaluator. You can put in a URL or a list of URLs that you want to check. You can include a depth. I don't know. Does anybody have a website that they'd like to test?

UNIDENTIFIED SPEAKER: UW-Madison home page

JON: I think those guys are actually pretty good. So they are pretty good. We look here, and this is the summary report information. So navigation orientation partially implemented, so I'm not sure how many pages. This was pretty fast. Are people seeing this? One out of one pages, so let's see. Let me just bring up a list . . . are there any other, it looks like a lot of the links changed to other URLs, so we don't test all of those.

Okay, well, we can just go to the FAE archive. We have lots of things in the archive. That might be easier. So we have an archive here, so after you do a report, it stays in the archive for a few days. Somebody just checked UW-Platteville. Anybody want to look at that one? Okay. So here's UW-Platteville. Here's the summary report. So it looks at the five categories that we talk about in the Best Practices, navigation and orientation information.

We chose these categories because oftentimes, navigation orientation information isn't checked very much by these other checking tools. Therefore, they were being ignored by developers. So this is looking at headers. You need titles, labels for form controls. Text equivalence, so that's the traditional alt text for images and other types of objects. Scripting, supporting device independent event handlers, styling, are they using CSS? So they are using a lot of CSS.

So if I was a manager here, I'd say, okay, well, it looks like we're doing pretty well in styling standards and text equivalence. It looks like we need to really put resources into improving our navigation and orientation, so if somebody has to make decisions about accessibility, they can say, well, where shall we put our efforts into? And then there's more details here, in terms of where are the areas of navigation and orientation, so tables, frames, there weren't any tables, frames, or access keys, so that's not applicable.

Document titling, it looks like there's some document titling issues. There's not unique titling information on each page. Navigation bars, it looks like the navigation bars aren't being marked up the way the Best Practice is. So, basically, that's using an unordered list with a header before it. That way, people can use header navigation. If I'm a screen-reader user, I can use my header navigation commands to get to a navigation bar and know that it is a navigation bar.

And then section headings, so there seems to be some rules be violated related to using headers. So then you can go to the site-wide report. Now, a developer might come here to find an overview of the information on the page. So for document titling, we see that, okay, the first one says, not all title elements are unique. So 43 out of the 59 are, so there's approximately16 that have redundant titling content. All the pages do have a title element. Some people leave out title elements altogether. So we wanted to make sure they were using the title element.

Thirty percent of their pages have at least one, and no more than two, H1 elements. So 18 out of 59 have at least 1 H1 or 2 H1's. And 55% of H1 elements have text content that matches all or part of the title content. So by using those rules, we can verify, have people thought about the titling of their Web page? And it provides functional features so people can either read the title bar or read the sub-page information in the H1's to figure out what sub-page they are on a website.

So for navigation bars here, we see that zero percent of all the ordered lists or unordered lists appear to be navigation bars or menus that are immediately preceded by the header element. So it basically found some list elements, LI elements related to, that looked like they were navigation bars. Basically, they were lists of links, and none of them had a header before them. That header provides orientation to what that navigation bar is.

That orientation information is extremely important, so my colleague . . . when we started implementing this on our website, had never known what a sand trail was. To him, they were just a bunch of these random links that leads you to a Web page through a screen reader, but when we put a header in front of it and said, this list of links is a sand trail, he said, well, what's a sand trail? Or some people call it bread crumbs. So by providing this navigation information, people can have access to information they didn't even know existed before.

So it's section headings that provide statistics, so it found 18 H1's, 58 H2's, 120 H3's across these pages. And all the header elements that follow H1 across the pages are properly nested, so that's a good thing. On the average, 1% of the content over all the pages is contained in headers. So we have kind of this header density. So how much navigation information is available? We're actually going to change this. One percent is kind of low. We're going to change that to a warning. Zero would be fail.

So we figure, right now, between 2% and 10% seems to be a good measure, so that's pass. So over 10%, like 10% to 50%, is warning, and over 50% is a failure. Some of these things are new, and we're still playing with them, but it provides some information back to how much navigation information are you providing on a Web page to the users.

And here's a real killer. I don't know. Labels for form control seem to be a very difficult thing for people to get. Here, 0 labels, across 59 pages, there's, it looks like 0 out of 17 controls have labels associated with them. That's a fairly invisible accessibility feature because you just can't tell by looking at a Web page whether their label is associated with it, but in a minute, we'll be showing you the Mozilla Firefox extension, which allows you to look at that right within the browser and to verify that piece of information.

So it provides this detailed information. Then you can go down to individual page reports. We're still working on the navigation structure. We've done some focus groups with Web developers on our campus and some other people, so we know there needs to be a lot of improvement in this user interface for people to find specific information and to navigate. So we're working on that, and you can see we're still at 0.87 here, so we don't even feel we have what we call 1.0. So we're working on the usability of the tool and working with our Web developers on campus. If other people start using it . . .

UNIDENTIFIED SPEAKER: Do you know if anyone builds some intelligence into these tools?

JON: Well, there are, well, you're assuming the tool knows something about what's on the Web page then because . . We aren't thinking in that direction. It really takes a human to know, well, what is the title for this Web page? You can't just automatically generate it.

UNIDENTIFIED SPEAKER: How about a tool that instead of presenting warnings, would place items into an area for repair, or is there anyone out there developing something like this?

JON: Well . . . I know that will actually tell you that you don't have unique titles in the tests for these things. I haven't seen anything, none of the other tools I know of have every done this. I'm not aware of anybody. That's what people want. They just want to push a button, and now my Web page is automatically accessible. I don't think, I haven't seen anything like that. I don't know of anybody working on it.

In fact, there's very little resources, I think, that are actually looking at building functional accessibility evaluation tools. It's really scary as I go around places to see how little resources are being devoted towards accessibility, and that's why I think it's also important for accessibility to piggyback upon the Web standards movement because there aren't a lot of people who understand a lot of the details of accessibility out there advocating for it. You're lucky to have Alice Anderson. I know the DoIT staff here does on campus, but a lot of places don't even have that level of resource.

There are some tools that will prompt you for that type of information, but not titles specifically. They're more like alt text for images. There's a tool called A-Prompt. Part of the problem that I really see is that right now, we're just looking at static Web resources here, but the real issue is Web applications. You can't repair a Web application by some AI technique because it's being dynamically generated on a server all the time.

JON: Right. Okay. And the accuracy of it. I think probably the most comparable thing you're talking about is OCR technology. How accurate does OCR represent the text output of a book? If it's a fairly generic page, it does pretty well. If there's a lot of textual formatting on the page, it doesn't do so well. So you might be able to do it in simple cases, but probably with most Web pages, especially Web pages now, when you look at, you know, especially commercial companies, Web pages are generated by an amalgamation of sources.

It's not a static HTML. They've got these RSS feeds coming from all over the place. People are actually dynamically choosing what they want on their pages. So this tool will provide you with information related to these functional accessibility features. And, again, this goes back, and kind of also, my theme isn't, we're not trying to repair pages. If people have a bad report here, and they're going to try to go back and fix their Web pages using their current markup, I would probably say you're setting yourself up for disaster. You're going to spend way more time.

I would tell them, well, you know, why don't you just wait until you redesign the website. Learn the techniques in that time. Learn about CSS techniques, and then implement the practices when it's not going to cost you all the money you're going to have to do to try to go back and retrofit a website. That's basically what we're advocating for on our campus.

The half-life of websites, I mean, the way most people design websites now anyway, they're obsolete in about two or three years. And also, with the marketing that goes on in campuses, you know, your homepages, or departmental pages, are basically marketing to alumni and to students. There's a lot of push to always keep those fresh, and updated, and new so people, when they come there, think that you guys are doing something. If their Web pages are too long, people think, well, they're not doing anything new.

UNIDENTIFIED SPEAKER: So when you are saying “websites” you are talking about traditional websites or are you talking also about portals?

JON: Well, I think that, you know, we've been fortunate on our campus. They're looking at portal technology, and we've been able to get to the portal prototyping people early, and they actually have done tons of work to make the portal accessible.

So they redesign these portals to be pretty much a tableless design, using all CSS, whereas, the original UPortal interface that they showed us, there was over 100 table cells just to create one tab in UPortal—just 100 table cells just for that one tab. I mean, it was just tons of markup, you know. And so getting in early and using designs up front can, you know, if they would have implemented a default template and done stuff, and we would have said, well, now we want to make it accessible, they would have said, forget it. We would have had to do that back at the beginning.

So we really want, and, you know, a lot of these resources are going to change. The Web is still a very dynamic thing, and Web applications even are changing. So we want to build accessibility stuff in as we're redesigning resources and do the right thing then because I think it will cost much less. There will be much more administrative buy‑in for it. Everybody will benefit because you'll be using techniques that a lot of people have a lot more options in accessing Web content. So that's really where I see it needs to happen.

There may be some resources that are considered so critical that maybe they should be redesigned earlier than others, you know. But on our campus, you know, for example, talking with one of our blind students a couple of years ago, I was just talking around to some of the more severe students and asking them, well, what about Web accessibility on campus? And she told me, it's not a problem.

I go, not a problem? Didn't we spend hours and hours with WebCT for you to enter grades into it because that student was a TA, and she had to enter grades, and she had to memorize all these steps? If she made a mistake, she had to go back. I mean, it took her four or five times longer to enter grades than other students. She said, yeah, yeah, but, you know, you showed me how to do it. We worked on it together, and we figured out how to do that, and I can do that. Well, what about other Web resources? Well, if I need anything else on the Web, I just ask a friend.

That was really scary to me because now students are self-accommodating themselves out of using the Web and information technologies. Could you imagine, what kind of jobs could you get if you couldn't use the Web independently?

UNIDENTIFIED SPEAKER: If you have a disability you want to be independent.

JON: Right, and, you know, she doesn't view her mission in life to be able to use the Web. She is working on a degree in education and eventually wants to be a professor, so she has other interests. But that was her method of dealing with the Web, so she really doesn't know what other information, you know, if she wants to go and find out information, it's got to be really important. She was trying to get information just about, you know, with our new SCT Banner system to find out about our financial aid. Well, she couldn't do it.

And then part of the problem, since they implemented a system, when you got to the information, it was confusing to everybody, not just people with screen readers. So maybe not having access into it was better so she didn't have to deal with the problems other students were dealing with, but she still didn't know. She didn't have access. And to her credit, she was starting to complain about it because that's how it's going to change. I'm glad she's complaining about it.

So this tool develops reports related to accessibility. Another tool we're working on is, well, some of the limitations of FAE, we don't test for all the requirements of sites as far as Best Practices, but we do most of them, and we want to add many, many more rules. We have some of the primary rules, and there's a lot of work that we want to do with it. And then some types of markup can't be accurately measured. Like changes in language are difficult to understand because there's nothing in the character sets that you're in language A or language B. The Web basically deals with character sets.

And that's a really critical one because, especially on our campus, four or five years ago, the College of Liberal Arts and Sciences increased the foreign language requirement. So enrollment in foreign language courses tripled on our campus. Do you think they provided three times as much faculty? No. They didn't get three times.

So these Web technologies were coming out, and they were developing things on our campus called CyberProf, and Mallard, all these homegrown course-management tools. You probably have a few up here in Wisconsin. So they coded all this content. They put it on the Web and delivered it through the Web for the routine stuff of just drilling the students and stuff. Then they had less class time to do conversational stuff.

Well, all of this stuff had both English and the foreign language on it. They didn't use any language change markup on it at all, over 300 or 400 Web pages. Can you use this to test the markup on our website before it is published?

UNIDENTIFIED SPEAKER: Can you type in a Web folder address rather than a published URL?

JON: We are going to have more options to test Web pages. We want, eventually, to have a text box that you could paste some code into and test it. So there are some options we'll be working on.

If you send us comments, we just add that to our list. You're basically voting. If you want a feature, and other people want it too, we'll raise that up into the development process. So there are some limits. We only have a few minutes left here.

Another tool we've developed is the Mozilla Firefox accessibility extension. So this is a plug-in to Firefox that includes accessibility features that, again, looks for the use of Best Practices. Here's the toolbar here part of it.

It also adds an accessibility menu to the menu of the toolbar. But it has the same five themes: standards, navigation, text equivalence standards, and scripting, that we have in our Best Practices, plus keyboard support features, and then convenience features for access to the zoom features of Firefox. And it tells you the percentage.

Under navigation, we see the same themes that we see under both FAE and the Best Practices, unique titles, major and minor topics, menu and navigation bars, forms. Do I have labels on form controls? So, for example, if I choose unique titles, that brings up a little dialog box that tells me, okay, what's the title content to this page? What's in the H1?

UNIDENTIFIED SPEAKER: What does major and minor titles refer to?

JON: Headers, use of headers. But that's what we want people to use headers for is major, minor topics. So you can see what the information here, what's the H1, and what's the title? We used your website, Chisty. So here's a list of headers, so you can see all the headers on a Web page, and as you go through this, it will actually highlight the headers on the Web page so you can see the corresponding place to see if all the major and minor topics have proper headings on a Web page.

For form controls, here's a page that, again, doesn't have labels for form controls. I apologize to Christy for this, but she showed me it, and we were talking about it the other day, so I included it here. It shows you that if you don't have a label, it indicates you don't have a label. If you do have a label, it tells you what it is.

And this seems to be a huge issue with Web developers because I've done a lot of training with Web developers, and I come back to their Web pages, and they have labels for some of the form controls, but not others. It's like if you do one, why don't you have to do the other ones? I'm not sure what it is, but this tool helps make that then visible, making these invisible things we want for accessibility visible to developers and also visible to people with disabilities because they can now use this information to navigate content.

Under text equivalence, we can see a list of images, a list of text descriptions for objects, and showing abbreviations that might be on a page. You can render all text for images or area elements. So it has features both for people with disabilities and for developers. So, for example, here on the list of images, on this CNN page here, you can see that some of the images don't have all text or titles associated with them. So, again, I'm not sure what these images are, but neither will someone with a disability because there's no text description, and they actually are links to some other content.

So you get information about your Web page related to accessibility. You can show all text though. If you show all text, it will turn off images and then render the all text in place of it. And this will even do it for area elements. So people who are using area elements, regular browsers won't show the all text for area elements, but this one will.

Under styling, you can set up a high contrast or disable CSS style sheets so you can see, well, what will my Web page look like if I don't have style sheets? And that helps you to understand, well, how will my Web page translate to technologies that don't support style sheets, like a PDA device or a text browser? In this particular case, if you select a high contrast setting, you can get a high-contrast rendering of the Web page. So it has features again that can help people with disabilities.

Standards view, so from within the browser, you can send your Web page to one of the W3C validators. Or the WDG, Web Developers Guild also has tools to validate documents. So it has links to those documents so you can very conveniently check to see if you're conforming with Web standards.

Scripting, so you can list the events on a Web page, or disable scripting, or disable mouse events. So if you want to say, can I still use my Web page when we take out the mouse events, you can do some functional testing with your Web page.

Under the keyboard, we support keyboard enhancements, so if you do include headers on your Web page, you can use the S and W key to navigate headers on a Web page. You can use the End key to navigate to navigation bars if you include our Best Practices in the design of your website. Then there's other features.

You can actually reconfigure the keyboard bindings to your own needs so that if there's conflicts with your keyboard, and you just want to have different ones, you can actually choose some different keyboard bindings. And this is a free download. You can go to the website, and download it, and use it. FAE is also free. There's no charge for the service to it. We don't plan on ever charging for any of these things. The FAE is kind of an open-source project. If other people are interested in developing with it, we'd be happy to talk to you about participating in the current developments of it.

But why is this important, this automatic evaluation? I think it's becoming increasingly more important for a number of reasons. One is that as we deal with a lot more and more websites, we need consistent reports. So if you have a lot of manual checks, and you have a lot of different people doing those manual checks, you're going to get a lot of different answers. If you're trying to write feedback to people, some people say, well, I did this, and I did this, and they're not sure which is right, and it can be a problem.

And I think, more importantly, when we start dealing with third-party software, so like Web applications, purchase technologies, we want to have a consistent view. If we're working together with a group of people, and one group is evaluating one part of the website and another another part of the website, and they're talking and writing feedback in two different forms, that's confusing to the developer. It's harder for them to process it, and it will be more difficult for them to make the changes. So that's an important part.

A lot of these issues that we're looking at, like form controls, labels for form controls, headers, proper titling, those are what I consider like bread-and-butter issues for accessibility. We just need those things. And if we're focusing all our accessibility resources on providing feedback just on those bread-and-butter things, we're not really getting at the usability issues of, you know, do the headers make sense? Is the navigation structure good?

Could the Web resource, especially for Web applications, have different features that would make it easier for people with disabilities and maybe easier for everybody else to use because things would be clearer, and navigation structures would be better? But we can't do those things if we're having to keep working on, well, we have to get the headers in, and we still don't have labels for form controls, you know. If we're going to spend all out time there, we don't get to these other issues.

And we have very few precious resources for accessibility advocacy. So one of the things that we're developing at the U of I is consortiums, which we've been working with other Big Ten universities and also within our state. We're trying to build consortiums around third-party technology. So probably our most successful one to date is our work with WebCT.

Just working with WebCT, developing templates that we can use to provide feedback because we have people from Minnesota and Purdue at our campus developing reports, we really saw, you know, if people are just kind of sending in random accessibility problems, it's a tremendous amount of work to try to organize that and figure it out. So we did develop some templates that people can fill out some forms to standardize it so it would be easier to aggregate information.

And kind of our long-term goal is to have FAE be the aggregator. We really want to merge the technologies of Mozilla extension and the FAE so that if somebody's in a Web application, they can tell the toolbar to start recording here, do a bunch of actions, and have FAE build a report on all of those actions, and then be able to send that report to the developer to show them what the accessibility issues are. Then that developer can then use the tool to verify, you know, so they can not only verify, but they can replicate it, hopefully, the accessibility problems.

Or if they make fixes, hopefully, they'll run the tool before they tell us they fixed it to verify they've actually done what the report asked them to fix. And by automating this, we dramatically reduce the amount of resources needed and the more products that we can address. So that's kind of a goal for the tools.

Web applications are really where a lot of students, faculty, and staff have accessibility needs because those technologies, like e-mail, course-management systems, institutional administrative systems, are things people want to have, need to have, access to.

So those are some of our next steps. And, again, these tools are available for downloading. We have some brochures that talk about the tools over here and where you can find them. And, again, these tools are all free, and we'd love to work with you on using them for your needs or get your feedback on how to make them more useful to you.

UNIDENTIFIED SPEAKER: Can you print?

JON: Yeah. You can print. There's a print style sheet so you can print them out. We do want to, we have a lot of things we want to do with the reporting interface, and probably, providing better print style sheets is one of them. But I have to do a lot of reporting to our campus, and the current format isn't ideal for me, so I have to do a lot of translating.

But we have some other technical issues that we're dealing with with capturing Web resources, and character and coding information we're working on, and also, developing this link for developing FAE reports of Web applications, which we critically need because of our work with WebCT Vista. It just, we did a whole lot of manual evaluation, and they didn't get it quite right. We have to go back and do all that other manual evaluation. It's just daunting. So if we had this, the tool can do it. It would be a lot more easier.

UNIDENTIFIED SPEAKER: Explain more about foreign languages?

JON: Okay. Well, I think the thing is a problem with speech users, people who are blind that are using speech, so I think the reading, and English, and now the text is in Spanish. If there's language change information there, it will automatically change. But if there's not, and the person can't tell. We tried to test it with people.

We said, well, maybe they could just tell because the words will sound different, and they'll be able to switch it manually, and that didn't work. It was just too hard to know, especially when you're learning a new language too. You're not an expert. So questions or comments? It looks like, all you guys kind of look worn out here. It's a lot of sitting, I know. Two hours of sitting is too long, but hopefully, other questions or comments?

UNIDENTIFIED SPEAKER: . . .

JON: Yeah. We talk about that. Best Practices are evolving too, as we use them, and test them, and we get feedback, both from people with disabilities and from developers, saying, these techniques don't work for me for whatever reason. So they are somewhat involving too. Like with unique titles, kind of our original intention was you have to have a title. The title element would indicate both the website information and sub-page information. And an H1 should just include the sub-page information. So that's why it would be a subset.

Well, talking to people at Minnesota, they had a similar requirement in their Web accessibility, but they wanted 2 H1's. One H1 would indicate the site information. The other one would indicate the sub-page information. So we modified our Best Practices to be compatible with that. We still felt that was uniquely titling a Web page.

Well, our approach is using Web standards. Again, we want to go back to interoperability, and give all users more choices, including people with disabilities more choices to access resources.

UNIDENTIFIED SPEAKER: Who is testing these tools? Do you have any screen reader users testing these?

JON: Our staff are blind, so our staff are telling us all the time. We have people who are physically impaired, but probably, blindness is the most difficult because it has, since they don't have the context of graphical layout. But these current screen-reader technologies don't provide very much information, in terms of spatial layout and things. Yes, we're testing them all the time with our students with disabilities. But I think our visually impaired students are probably the biggest challenge.

UNIDENTIFIED SPEAKER: . . .

JON: I think by providing Web resources that are flexible, then you provide, so if you're using images to stylize text . . . somebody that's using Kurzweil 3000, then they can't read that text using Kurzweil 3000. But if you're using CSS to . . . that as text, then they can use their assistive technologies to read that text. So, again, an individual technique isn't for a specific disability. It just allows everybody more flexibility in using content.

So, for example, the invisible GIF might be useful to screen-reader users, but what about the physically impaired user who wants to skip over all those navigation bars? They don't know it's there. So most of these features have impacts for many, many different types of disabilities. Maybe I have Attention Deficit Disorder, and I just want to compact as much information on the screen as I want, so I'm going to make the font really small, and try to get all your stuff on the pages, and have a whole bunch of pages.

Well, if your Web pages won't adapt to that, I can't do that. So we want Web pages that will adapt, and it's the same Web standard stuff. Adapting to technology, different technologies, or adapting to user preferences, that's what we really advocate for. But there are a lot of specific techniques in our Best Practices to allow for orientation and navigation information. So it's not just, do Web standards. There's a lot of stuff in websites that aren't very accessible. Other questions? Over here, you guys have been pretty quiet. This side of the room is beating you guys (with questions).

JON: Well, certainly, the refinement of these tools, we think, is important. In terms of the FAE, we also want to create like a Web services interface, a lot of different technologies. We could have an IE toolbar. We could have an extension to Dreamweaver or Front Page, that it could send information into FAE, and people could get reports during the design mode. I think somebody mentioned that. So we want to create an extensible interface for that so you could create your own tool and interface to FAE and get reports from it, you know.

Maybe your content management system, you know, maybe WebCT could build an interface to it so that if somebody is uploading content, it could provide a report on the accessibility of it. You know, it's at least a first stage to helping people understand accessible design. So that's one aspect. I really think the biggest need we have though, especially in education, is to have an authoring environment that instructors would really love to use, that also supports accessibility by default.

If I had one area that I wish I had a lot of resources to put into, that would be it and not only be accessible, but provide output that instructors want. They'd say, boy, this is a lot better than what I'm doing now, or, it provides me with flexibility, supports active learning processes, and is accessible. Certainly, I think if people were looking to design instructional technology, and they didn't have a computer yet, and there's a whole wall of software, I doubt anybody would reach for the Microsoft Office box.

The only reason why it's there is because it's what comes on PCs, so that's what faculty use. I see that as the biggest need, and, hopefully, at some point, we'll have resources to do that, or somebody else will have resources to do that. That's what I see as really critical. We need authoring tools that support interoperability and accessibility by default, not just for instructional purposes, but creating documents. And I'm hoping the ODF movement will bring competition back into the authoring tool market.

So even if the mainstream ODF people don't do it, since ODF is a standard, somebody could build a tool that supports it. They would at least be able to have an accessible authoring environment.

UNIDENTIFIED SPEAKER: Question about Vista?

JON: Okay. I've heard that . . . Vista is going to have new Web authoring and publishing software. Have they been helpful to you in your . . . I haven't really seen Vista, so I can't really answer that. Does anybody here use Vista at all? Okay. Sorry. We'll just have to wait for Microsoft, I guess, to show us what they're going to do.

UNIDENTIFIED SPEAKER: Why isn't this a part of Microsoft?

JON: Yeah. Well, I'm sure Microsoft is trying to figure out how to, I know that the new version of Office has a lot of new wizard-type features to it. I'm sure that Microsoft is trying to figure out how to keep people using Office to do almost anything. I mean, their commercials on TV show that it can do almost anything. It may not do almost anything very well, but, again, with a little training and a little knowledge, I'm not sure.

It's interesting to see how Microsoft will, they've been a desktop platform . . . your whole world was just your PC in front of you, they were kind of it. But now, with this new network world, it's not really clear how their desktop strategy fits into that and how they will be able to extend it to use that network. But I guess we'll wait and see. Other questions? All right. Well, thank you very much. I appreciate you taking the time. And, again, thank you to Alice Anderson for inviting me to talk this morning, and all the people who have joined through the Internet, I thank you.