Skip Main Navigation
Indiana University

Main Content

2009 CIC IT Accessibility and Usability Working Group Annual Summer Conference Proceedings

Best Practices Approach to Web Accessibility Session

You can download and listen to an audio recording of the Best Practices Approach to Web Accessibility Session (mp3, 44MB)

or listen to it using the accessible player below (requires Adobe Flash):


>> And I'd like to move on now and introduce John Gunderson [assumed spelling] who is from the University of Chicago. He's the coordinator of the Information Tech - I'm sorry, there's two. There's the University of Illinois, Urbana, Champagne. This is where John is from. I don't think he dislikes University of Illinois, Chicago, but that's not where he hails from. And he is the coordination of Information Technology, accessibility, disability resources and educational services. And I will just turn the presentation over to John. Thank you.

>> Okay. Margaret asked me to come and talk a little bit about our accessibility - Web accessibility best practices. Some of you have already heard this before. But how many people are - she said some Web developers from Indiana would be here today? We have a couple? Oh, okay.

Well I'm gonna talk a little bit about what we've been doing at Illinois in terms of Web accessibility. And a lot of the issues our previous presenter talked about are things we all face, including us at the University of Illinois. But I'd like to start out with what makes accessibility hard, you know? I think one of the things he talked about was awareness. I didn't know I was inaccessible. I remember a few years ago there was a Webinar from the Educause Conference about a guy who, his name is Greene, he studies information technology in higher education. So, how many bits are going over your network, how many email accounts or emails are going over. All of these little facts about IT that you know, administrators want to know. How many more computer workstations are we gonna need. And he got to this one slide about the Web. And one of the bars on the graph was Web accessibility. And it said that 93% of all Web sites were accessible. And I thought gosh, I'm out of a job. Now fortunate, well I don't know, unfortunately or fortunately, but at that time at the University of Illinois we were looking around, we couldn't even find one 508 compliant Web site in all of the University of Illinois, except for our own Web site in Disability Services. But I emailed them to try to find out how he collected this information. But I got a feeling I know what he did. He basically, he calls up some administrator and hopefully they'll talk to him. And he's got a laundry list of all these questions, and he got to the question about Web accessibility. And he asked the administrator well are your Web sites accessible. And like any good administrator, he probably paused for a moment and said well, we didn't design them to be inaccessible, so sure they're accessible, you know? And I think, so that's the awareness part. People don't know that they're not accessible. People assume they're accessible until somebody tells them they're not. And this is true whether you're developing Web sites locally or you're buying it from a vendor. And if a lot of the technology that we care about accessibility, we don't make at the University of Illinois, we buy it from somebody else. Blackboard, Confluence, Mirror Point, all of these companies who are providing web-based services that we have no control really over the code that they're creating, but are probably more important to a lot of our students than if the departmental Web site is accessible. Cause they don't go to the departmental Web site very often, but they do go into Blackboard every day to try to figure out what they're supposed to be learning that day.

The second issue I think is knowledge, okay? When we first started working on accessibility at Illinois we were fortunate enough to have something called the Webmaster's forum. So this is a built in group of Webmasters who were already meeting together and trying to share practices. And learning about this new technology called the Web, you know, this is like ten years ago, you know, so the Web was new. Nobody was trained in this technology, there wasn't a lot of information. So they were sharing information. So we started talking about accessibility, and we started talking about some of the standards, section 508, W3C standards, and said you know, you should use these things. And that worked to a certain extent, but developers would come up to me afterwards and say well some of these things make sense to me, but a lot of these other requirements, I don't really know what they want. John, can't you just tell me what you want me to do? And if it seems reasonable to me, I'll just do it. And so that got us thinking well you know, what do we want for accessibility, you know? Kind of the approach, a general approach to accessibility, which I think he talked about in the previous, or in usability for that matter is people build something, and then they kind of see how usable it is or how accessible it is. So we're always kind of behind the eight ball in trying to fix things.

You know, one of the other things that he talked a lot about which I think is really a critical factor is cost. And if you're fixing accessibility problems after you build something, you've basically set yourself up for failure. If you're not building accessibility in at design time, you know, you're never going to have enough resources, you're never gonna have enough buy in, you're gonna have every Web developer trying to avoid this issue, because nobody likes to go work on old Web sites. So at Illinois, we only, we're pro-active. Okay you're not accessible now, but let's get into your templates, let's get into your new content management system and build the accessibility features in. Cause the new resources that you're creating, let's make sure that they're accessible. Because just from the social standpoint people don't like to work on old stuff, and they don't, and realistically most people don't have time. And the half life of a Web site these days is what, one and a half, two years at the most? So if it's important information, it's being updated, it's being created. If it's old information you know, it's probably not being used that much anyway. And so, and then skill. How do, if you've developed best practices, how do you get that into the actual production Web site? What are the tools that you're using?

And this is probably I think the most critical thing we have for accessibility that's gonna make the biggest difference. And if you take nothing else from this presentation today, I hope you'll take this, is that we need authoring environments and authoring tools where it's harder to create inaccessible content than accessible content. Right now with the tools that are available, it's a lot easier to create inaccessible content than accessible content. And as long as we're gonna rely on the developer's knowledge and skill in using that tool to create accessible content, we're not gonna get very far. So when companies come to your institutions to sell you these great flashy new products to manage your Web sites or create content, ask them not just the question of whether they support accessibility, cause we all know what their answer will be is oh yeah, you can create accessible contents with us, if you want to. You know, that's always kind of, if you want to. And if you want to do that, well then you have to go over here and do this, and you have to go over here and do this, and you have to. Ask them to show you how do you create accessible content? You know, what do I have to know, or what don't I have to know to be able to create accessible content. We need to start challenging companies and vendors and products, people producing products to not just say that they're accessible, but show us how you're accessible. Show us how you create accessible content. And because until we start doing those types of things, they'll be happy to just tell us that you can create accessible content.

And so we need to do that, and I think that that's really the critical aspect of how we're going to solve a lot of these efficiency problems and the cost problem is that we get accessibility by default. We don't have to know very much, because most of the content creating in the university now is being done by, less and less by anybody who understands any of the HTML or accessibility standards.

So, how much time do I have Margaret? Cause I know originally I was supposed, we were supposed to end this at, oh well is that okay with these guys you think? Is that okay with you guys? We'll see. Once I, we'll see how many people start checking their email then we'll stop.

Okay. So where do we start. I've already talked a little bit about where we started. We started training, you know, doing these workshops as part of the Webmaster's forum on campus. We started to get some buy, we targeted some key people on campus. One of the places we really wanted to work on with accessibility was our office of public affairs, cause they kind of set the tone for the campus. People were following them in terms of the templates and design techniques that they were using. And I think that was really a breakthrough for us. A developer named Doug Burgett [assumed spelling] was in the office of public affairs. He had come into Web accessibility from a graphics design background. So when we started working with Doug, basically you know, his idea of creating a Web site, so he would draw a pretty picture in Photoshop or Illustrator or something, and then use that nice publish to the Web feature that's on one of the menus of that tool, which produced highly inaccessible Web sites. But we convinced him to start looking at accessibility and Web standards. So one of the ways we started to talk about accessibility at our campus was through the Web standards movement. So you get the efficiencies of some of the Web standards design stuff, and also we get the accessibility we want, which promises you know, it's more, it's easier to create and maintain Web sites, and some of those issues.

So Doug went away and had to learn about CSS and about some of the underlying markup more. But he came out with a new Web site which was highly accessible, and was also now part of the the public face of the University. And he's moved on to a different part of the university now, but he still creates highly accessible Web sites. But I think the telling thing that came out of that for me is that after he did this and learned these techniques, he said I learned these techniques because of accessibility, but I use them because they're better Web design. And that's what we need for accessibility. If accessibility is always thought of that stuff for just those people over there, this small group of people who who aren't very visible and they're not very vocal, I don't ever hear from them, I don't think we're gonna get very far. But if we can see, if we can get people to think about well this is just part of better Web design, I'm creating Web resources that make it more efficient for me to create Web sites, to maintain Web sites, and that's how we need to get at the design process. Because if the mental model of Web developers of accessibility is I got to go back to all my Legacy Web sites and alt text all the images, accessibility's gonna have a pretty bad name. But if accessibility's associated with better web design, and the way things I should be doing stuff, we'll have better buy in, and we'll get developers on the path towards not only more accessible Web sites, but Web sites that are easier for them to create and maintain. And so we get a much more positive spin on accessibility.

Another thing that was happening in parallel was we have the Illinois Board of Higher Education. At another point the previous speaker talked about you get some high level buy in. And we were fortunate enough that Jim Kaplan was the chair of the Illinois Board of Higher Education, and just as he said, he had a child with a disability. And so Illinois Board of Higher Education oversees all four year institutions in Illinois, and he basically went to every campus and he wanted to know not if what they were doing to serve students with disabilities, but how many students with disabilities were actually on your campus, and how you're recruiting students with disabilities. Do you care about those students just as much as you care about the other students in our state? Or you know, internationally. And part of that process came out a process, some campuses were looking at Web accessibility. So he wanted to see if there was some type of standard that all universities could use on the, in Illinois.

So we got together some people from different campuses. But some campuses had already had the hammer put on them, you know? Some of you had filed a complaint. And there had already been litigation. Anybody here ever been involved with any litigation? No? Boy you got, oh Dean, okay. Well you know how wonderful that process is. Anybody, everybody's had to deal with a lawyer. Do we have any lawyers in the room?

[ laughter ] No? Okay. Well there's real world and then there's the law world. And my few dealings with the law world, it's a whole different reality. But you know, not to say it's a bad reality, it's just a different way of looking at the world. So they already had, you know, they said all of these best practice stuff you guys are doing is wonderful, but you know, this is what our settlement says we're gonna do, and that's what we're gonna do. So it was clear we weren't gonna have any consensus on any standard, but one thing that did come out of it that was very positive is that campuses had to say okay, what is your web accessibility standard, and what are you doing to implement it on your campus. It was part of a report that people had, was gonna be made part of a report that people, all campuses had to send to the Illinois Board of Higher Education. So it was gonna be this public, and at least an, you know, the presidents and chancellors have to sign off on that report. So again this awareness. So somebody had the high level administration has to at least acknowledge you know, what the campus is doing. So that was very important. So what do developers want? So as we started working with developers we started to say okay, not how do we fix a Web site to be accessible, but what do we want on a Web page for accessibility.

So we started looking at the designs people were creating, and the parts of the Web page. So you know, one of the first issues we wrestled with was titling, how do I know what Web page we're on? We know that branding, you know, branding is really a big deal for departments and colleges in any program. They want people to know hey, you're on your Web site, and a big deal is you don't want people to leave your Web site. You know, if there's a click on something off the screen, we want to make sure our Web page stays there, and stuff like that. So we started looking at well what does it mean to title a Web page? What does it mean, what is the structure?

Like one of the other issues was navigation bars. We know there's all these navigation bars to the Web site or other links on a page. How do we mark that up? You know, and we looked at the W3C work, and there's not a lot there for navigation bars. We said well here's a bunch of suggestions of things you might want to do, but it doesn't say what you should do for a navigation bar. So from our best practices work we started to say okay, what do the Web standards people do for navigation bars? And we said okay, unordered list, unordered lists of links. Okay great, we can do that, that's fine with me. You know, it helps Web developers. But then we said well how do we title that unordered list? So we thought okay, well maybe we'll use the title attribute of the unordered list to give that you know, but one is we started looking into system technologies like screen readers. Well to read a title, it's an extra command, you know? So you'd have to get the list and somebody would have to issue an extra command. Not all screen reader users are gonna be looking for that, or maybe even understand about the title attribute.

So we said okay, well headers, you know? Screen readers support header navigation. We have techniques if people don't want to put the header on the visible page, you know, we can off screen it. So we started to develop these practices, and then we could give developers concrete things to do. Cause one of the things that we really emphasized was Web developers want to know that they're making a difference. Like one of the comments a previous presenter said, I put in all these all text images, but nobody gave me a pat on the back for that, you know? And so, but if we have, if we give developers techniques that we know will make a difference for people with disabilities, they're much more likely to want to do that.

Validation, did I do it right? And one of the things with current validators, or a lot of the publicly available ones is that they basically look at the markup on the page and say okay, you violated W3C guideline, blah, blah, blah, or section 508 guideline blah, blah, blah. Or more likely what it'll say is you may have violated this particular thing. So now the developer thinks oh gosh, now I got to go figure out if I did violate it. And if I did violate, if I do think I violated it, what do I do to fix it? It's not a very efficient process.

Again, we're looking for efficiency. Well with the best practices, we can start to look for patterns in markup that support the best practices. So like one of the tools, so one of the tools that we developed here, I know we're, so here's the best practices. So one of the things we do here, I guess I should have shown some of this, is we have a Web site where we contain all these best practices. So a lot of our things have to do with navigation, so when we look at unique titles, we have actual rules we can look for.

[ silence ] So here, the title element is important in our titling, the H1 element is reserved for titling. We can now start looking at rules. Okay, I apologize here, my navigation skills aren't too good here. But I guess my screen is, we can start to say okay, well if the title element and the H1 element are important, we better make sure that there's a title element and an H1 element on the page, okay? And then we can start looking at okay, part of the content for the H1 must be part of the title. So we can actually start to develop these rules that can be used in automated tools that provide direct feedback to what developers have to change. And so, and this turned into a tool we called the functional accessibility evaluator. This is a free tool. And at the end of the presentation I have some handout materials about where you can find these things.

So does anybody want to volunteer their Web site? We'll do a little demo here. Anybody have a favorite Web site? Which one? www2 like that? Lib?

[ silence ] And we'll just look at second level pages. And while we're waiting for that to go collect pages, we can look at a different report. So here's Lon Campa [assumed spelling]. But this is kind of, I think this is a repository for instructional materials. But what this does is this is kind of a summary report on the rules, on how many rules passed in some of our different best practice categories. And this was assigned to be used by an administrator. Cause I don't know if people have used other automated tools, but they kind of have these lists of things, right? A lot of lists of things, all related to W3C. You could probably give it to an administrator but it would probably not make much sense to them. But with this, at least they get kind of a broad overview. They can tell if things are fairly accessible, or what areas of accessibility might need to be improved. You can get more detailed information related to like subtopics in the best practices, so titles, subheadings, navigation bars. And this was, one of the things that we found that with developers that they really liked about this tool is that it told them exactly if there was a failure.

So like on this particular page it says each H1 element must have text content. And three pages failed that. So you could go and find out what those pages are. But this information, okay there's some empty H1's on my page, and I can go find out which pages those are, and I could fix that. I knew what, it's telling me what I should do. It's not telling me that oh you may have violated this particular thing, and you have to go figure out whether you violated or not, and then go figure out well, what markup should I use for it. It would provide us specific information. So developers really like that. And we also, we don't have a lot of time here, but we have other tools to test dynamic content, we want to update FAE, right now it's just looking at static pages.

But through, another tool we've developed is the Firefox accessibility extension. So basically it adds these toolbar features and allows us to look at dynamic HTML. So if you have pages, a lot of the work we do is with companies, helping them raise awareness on accessibility, and help them to design accessibility in. And most of the Web applications are dynamic, so we need a way to look at what's in the current Web page, and test it for our best practices features. And there's more information in the bulletins about those. So let's see, so let's go see if our report for our volunteer, we could have used a university that wasn't here, you know.

[ laughter ] So here's the library. So here we go. So here's a page, it looks like they've done a lot of accessibility work. I don't know, did you guys use the best practices at all? Okay.

[ silence ] Okay. Yeah, as you can see here that you know, a lot of the rules that they passed, you know. It's hard to be a hundred percent, but you know, but this tool provides that validation, provides that feedback to developers yeah, I got the features in there. And so it does provide that feedback. You know, everybody wants a hundred percent, or you know, high ratings. And the things that you know, if you look at some of the current tools out there that just look at guidelines, that's why alt text for images is considered so important, because most, almost any accessibility tool will tell you that you fail if you don't have an alt attribute on an image. So the alt attribute has this inflated priority in accessibility. It's like well if I have alt text for images I must be accessible, because everything else is a manual check. And if those manual checks, if those were really important those would be you know, would tell me I failed. So if they're manual they're probably more like optional nice things to do.

But people who work in accessibility know that they're not, that you know, accessibility's a lot more than making sure your images have alt text on them. So we've developed these best practices and tools, and worked with Web developers to get feedback. So as we developed them, and I think this is, so there's links to more about the tools. But a big part of this is the best practices working group. And let's see, oh this is the old link. We should go with the new link.

[ silence ] Best practice. So we have a working group that meets once a week, brings together disability professionals and Web developers to talk about accessibility design problems. For this particular feature on a Web site, what do we need to do to make that accessible, not only works for people with disabilities, but makes sense to Web developers. Cause we don't want to ask Web developers to do, you know, one of the other things that I think Web developers have is that they see these things like the skip navigation link. How many people put skip navigation on their Web pages? You know, I bet if we surveyed here we'd find out you have four different techniques for the four people who do that to do that. You know? And Web developers are gonna, the skip navigation thing, they go on the Web, they do Google searches, and periodically there's a flurry of emails on some list about the best way to do skip navigation. Well you know, in our best practices approach, you know, we don't have a skip navigation. We say use headers and use headers properly, and people can use header navigation to get to features. I think one of the issues why we have this skip navigation thing is cause of 508, and because Internet Explorer basically doesn't have a feature, you know. If Internet Explorer would have had one feature, we wouldn't have ever had skip navigation. You know, anybody know what that one feature is? Header navigation. If IE would have supported keyboard header navigation, we wouldn't have had skip navigation, we would have had in section 508 use headers, and use headers in a structured manner. But, so if anybody here ever has an opportunity to talk to anybody in Microsoft's IE development group, ask them why we don't have header navigation. You can use the Opera browser, it's had it for over ten years. You can navigate by headers using the keyboard with Opera for over ten years. You can ask them why don't we have that in Internet Explorer. So if you ever have that opportunity, I've asked them. They don't seem to care, but if more people ask them maybe they'll start to care and add that feature. I mean they add a lot of other features, why not that one? I don't know. But that's using Web standards. So people use headers for Web as a big part of Web standards, and separating content from styling.

But this group is open to anybody. Anybody here would like to participate, or other, if you know people on your campus we'd love to have you. The most people we have, the better best practices we'll have. So let me see what else we have here.

So our steps to accessible Web design was to use standards and semantic markup. And with the buy in from that, and looking forward, forward-looking designs, I think even with our Illinois, one of the other things that's happened in the last two years in Illinois is the Illinois Information Technology Accessibility Act, which covers Web content. And so that's become the de facto standard for all four year institutions in Illinois. So whether your, our administration agrees with that or not is not, it doesn't matter, it's the law of the land. And so that's the standard, if a complaint was gonna be filed against the university that people could point to, or the complainant says well, here's the act, don't you guys know about it? But with Web standards and semantic markup, we want people to start using the best practices approach. And for a large part we have got administration buy in to do that. And we could talk a little bit more about that. We want people to start doing things with design time. So if your Web site's not accessible now, you could, you know, let's make sure in the future you are more accessible, and to participate in the best practices if you don't find something.

Now we've been very fortunate at the University of Illinois is that our Dean, Dean Tanya Gallagher felt accessibility is very important. So on our campus in terms of building up administrative control, she said okay, if this stuff is really important for accessibility, let's do it in our college. So the Web developer, Tim Offenstein [assumed spelling] was the Web developer for our college, and worked with our best practices group, and implemented it for the four departments in our college, and for the college Web site. And so, and he said this is doable stuff. It's not rocket science, and it makes Web development more efficient. So then the Dean said okay, I proved we could do it here, she took it to another level. She took it to the campus and said we need to do this for the campus.

And so an initiative, basically a proposal was made to the council of Deans, the Deans all had to approve this, and they allocated four new positions to do administrative, to provide administrative controls and support, to support accessibility for the whole campus. Tim Offenstein became kind of the accessibility auditor for the campus. So he goes around and has done a triage on all of the campus, all the major campus departmental and programmatic Web sites, basically classified them into three groups, kind of the groups that were, have, are almost complete or have completed the best practices. The second group basically with some help they could meet the campus standards, and a third group that is gonna have to wait till a total redesign. So part of it is to get buy in, Web standards, we have to show that this is economically, you know, I tell people Web accessibility saves money, it doesn't cost money. If we look at Web standards, if we look at forward-looking design, we create Web resources that will cost less and be easier to maintain, we'll actually be saving the university money in the long run.

So looks like Margaret, we need to move on.

So are there any, one last thing though is, one of the things that's coming up in September is, this is kind of preliminary information. We're going to have a one day Web accessibility conference and expo at Illinois. A similar conference was held at the University of Illinois Chicago in the spring, but we have some sponsorship on our campus, an interest to do that on our campus. So September 29th. So people from Illinois or other CIC institutions who are interested in coming, we'll have a one day, we'll have a keynote speaker, we're trying to bring in an alumnus with a disability who's now working the Obama administration to hopefully talk about IT accessibility at that level. I don't know if that'll happen, but we'll be talking about best practices, bringing in speakers, and maybe some of the people here will bring in a speaker to talk about some of these topics. We're gonna bring in vendors to have a vendor area to talk about some of the technologies for accessibility. And it'll be fairly low cost. A major company is willing to underwrite a lot of the cost for the, or is interested. So you know, twenty-five to forty dollars. So I want to make sure people kind of get that on their calendar and start thinking about it. We'll have more information next month about it, and be making it available through the CIC listserv. So, okay.

[ applause ]

==== Transcribed by Automatic Sync Technologies ====