ROUGH EDITED COPY
ALL RIGHTS RESERVED
UNIVERSITY OF ILLINOIS
CIRCLE CAMPUS
DIGITAL ACCESSIBILITY EXPO
SESSION 3
WEBMASTERS FORUM
1:30 p.m. ‑ 2:50 p.m.
APRIL 9, 2009
CAPTIONING PROVIDED BY:
DILLON REPORTING SERVICES
100 NORTH LA SALLE STREET, SUITE 1500
CHICAGO, IL 60602
* * * * *
This is being provided in a rough‑draft format. Communication Access Realtime Translation (CART) is provided in order to facility communication accessibility and may not be a totally verbatim record of the proceedings.
* * * * *
>> KIM CHARLES: Good afternoon.
Welcome to the webmaster's forum. My name is Kim Charles, and I'm the director of web communications in the office of marketing and communications here at UIC. And my main responsibility is for the design, content maintenance of the main UIC website.
I think that like many of you, I face the same types of challenges related to how to make websites accessible, keep them accessible as you make changes to your site, and so I'm very happy to be able to bring some of these presenters together here to talk to us about how we can assess our sites, work with tools that are available, work with vendors and how we and webmasters can perhaps build a community to support each other.
Our first presenter is Jon Gunderson. Dr. Gunderson is the coordinator of assistive communication in information technology and accessibility in the division of disability resources and education resources at the University of Illinois in Champaign, he received his (inaudible) human factors and holds BS and MS degrees from the University of Wisconsin in electrical and computer engineering. Currently he's responsible for accessibility issues for students, faculty and staff. Before his present position, he was a visiting assistant professor in a rehabilitation services administration sponsored rehabilitation engineering training program at the RES at Urbana. He's the past chair of the W 3 C user agent working group and currently involved in making HTML more accessible and formats working group work on the accessible rich Internet applications. He leads the development of the Firefox accessibility extension in the Illinois web accessibility tools, and he led the development of the accessible web publishing wizards for Microsoft office, and it's now a commercial project. And he also developed the PC talking typing tutor, a software program and I am happy to say that he also educated me on these issues when I took his class. So thank you, Dr. Gunderson.
>> JON GUNDERSON: Well, good afternoon. There's some information that's being passed out by Chris Dobson about some of the tools, the URL. Also I'm teaching an on line glass a couple of weeks on ‑‑ class in a couple of weeks on accessible web forms so if you're interested in that, there's information there.
I would also like to pass a sheet. We have an announcements list if people are interested in getting updates on our tools and trainings or event like this happening around the state. I ask people to print their name and give us their e‑mail address, so if you can start that here.
Okay. I'm going to talk about some of the tools we developed at the U of I, and where these tools came from. A few years ago, the Illinois Board of Higher Education asked some people around the state from different institutions to come together to try to develop a state standard on web accessibility for higher education. And at the meeting, people got together and people had different ideas. Some institutions were already had an Office of Civil Rights complaints filed against them so they already had agreements. So this is what we're going to do. Some of the ideas are interesting and nice, but we already talked to our lawyers and this is what we're going to do and it was clear there wasn't going to be any state standard.
At least not a consensus one.
But what did come out of that meeting was a reporting requirement for all four year educations and I believe community colleges are encouraged to do this too, to report on their current state of web accessibility, what your local standards are, and how you are implementing those standards on campus.
And that's part of the minority student report.
So I thought that was a great thing, and then I was really excited about that and then I said, wait, one of the tools available to evaluate websites for accessibility and when I looked at the tools available I thought the only thing we're going to get for accessibility, what the standard will be is all text for images and maybe labels for form controls because that's all the tools said was an absolute reported being a failure.
At the same time, we were working with people on campus, and talking about the standards and either 508 or wick ed 1 at that point and the developers would listen to me and many of them would come up and tell me at the end, John, all these standards are interesting, and some of them are understand, a lot of them I don't really understand. Can you tell me what you want me to do? And if it seems reasonable, I'll just do it.
That made sense to me. And so we started to develop something we called, that's now involved in what we call a best practices. We started thinking about accessibility from being a repair problem to being a design issue. And so I started thinking about this is the markup you use so this is how you have to fix that markup up. We started thinking, what markup do we want for accessibility? So we started to think about how do you title a page, how do people know where they are? How do they know what the different stuff is on a page. People spend a lot of time, the graphical styling stuff, so that people can find information and differentiate it. How do we do that in markup so that people might not seeing that graphical rendering might see that information.
And these two different ‑‑ many things were going on, we knew we needed a different tool. And fortunately we had some resources available, to start the development of what's now called the functional accessibility evaluator. It used to be called wham it. Web accessibility management tool, we thought who would want to use a tool called wham it? It sounds like we're going to pound something into your head.
So fortunately we had the insight to suggest them to change the name of the tool.
But it's a free service of the University of Illinois. You can go and sign up for an account.
So does anybody here want to test the URL? Any volunteers?
>> AUDIENCE MEMBER: You can test uic.edu.
>> JON GUNDERSON: I think they're actually pretty good.
>> AUDIENCE MEMBER: It's www. Sorry.
>> JON GUNDERSON: Okay. Give it a title here.
We include second level pages.
(Laughter.)
How about next level domains? How about that? We'll see where the website links to now.
So hopefully it won't take too long but we can look at an archived report. Here's a repository of learning objects. We'll go back and check for UIC later.
But one of the things we did is we organized, one of the things we wanted was something that managers could use. When we looked at existing tools out there, basically there a long list of section 508 requirements. Some said there were failures but more often than not there were manual checks and they were fairly technical. You would never think of giving this to a manager and seeing there accessible or not. So I wanted some type of summary page for someone who didn't know much about the technical details of web accessibility could get an overview of accessibility of a page.
The best practices we organized in more functional units so these seemed more to be the way the web developers thought about the web. One of the things ‑‑ a wonderful thing about accessibility requirements is they were organized around the way people in the disability world thought about the different categories of accessibility and they didn't match how developers thought about creating a web page.
So under like navigation orientation, we talked about titling a page, creating subheadings, form labeling. One of the areas that was very big is navigation bars. There's this concept of people having navigation bars to navigate the website, but there was no consensus within the web accessibility community about what the markup was for a navigation bar. So the best practices group came up with a process and a strategy to do that. So and we considered the best practices not a standard, but the techniques to implement either section 508 ‑‑ in this state we're concerned about the information technology accessibility act and we've worked hard to update the rules to map into IITAA requirements.
So basically people can see if they pass or don't pass some of these requirements.
So let's see if UIC is done and we can take a look at that.
Yep, they're done. So here's kind of the summary report for UIC. So navigational orientation, 84 percent of the rules passed. 90 percent for text equivalence. 98 percent for scripting.
I don't want to spend a lot of time on some of the details but one of the things that web developers liked about this is if I go to the titling, I come to something called the site wind report and one of the things we didn't anticipate is one of the things that web developers liked this reporting strategy because it told them what they were missing on the page or what they needed to do to fix it. With other tools it said you violated this W 3 C or section 508 requirement. Okay? Well, or worse it will say, okay, maybe you have violated this requirement, so now you as the web developer have to think, okay, I got to go look at my markup and read this thing and figure out did I violate it or didn't I? Okay. Maybe I did, so now I got to go try to figure out, okay, what do I do to fix it? Oh, now I got to do another Web search, and so it was a very tedious process, and many web developers, if they got the old text on images, that red dot went away, maybe labels for form controls that red dot went away, and if any of these manual checks were that important, they would have made them pass, fail, right? They wouldn't have just made them manual checks if they were important, right?
So some of the things here, so like for titling a page, it has to have a title on it. Well, there's a basic markup for titling, and to if they're missing a title element on a page it will tell them. The title, you know, one of the things we learned in the first version was even if you have headings or a title element or especially headings on a page, you have to make sure they have content, in the first version of the tool we found that people said, okay, I'll put a header in here but there's nothing in it. It seemed to satisfy the tool's requirements, so part of the things have to have content, and for example titling here, the H 1 element is kind of our titling element, so people especially using speech can now use header one navigation to find out what the title of the page is, and at that header one content has to be a subset of the title content.
And so for many web developers they like this type of feedback because they knew that what they had to do to fix the problem, and we worked on these best practices with web developers and it seems to work for them, and especially in scripted environments, many people do this automatically, they define the title he in a way that it's automatically put into it and they have more consistent pages.
I'm not going to go through all the rules here. You can sign up for a free account. These links to our best practices, so there's additional information so like on titling. You can go to our best practices, hopefully.
There we go. We have a best practices for titling. So you can find out information about titling on the page.
And look at the rules, overview, examples.
Now, the other tool I want to show, is ‑‑ let's see.
There we go. Is the Firefox accessibility extension. One of the other things that we do at the U of I is work with third party companies to try to improve accessibility. Well think of companies, if you were at the session they talked a lot about Blackboard and some of these dynamic tools that generate a lot of dynamic HTML. Our current tool cannot analyze that, we're hoping to fix that, but even so, since I can only put a URL in, if I have to go behind a password protected place, I can't get there. And so when we were working with these companies, on how they can ‑‑ I can tell you how difficult it was to go manually through pages to find things, one of the things you want to do is make this hidden accessibility markup more visible to people, and so basically what this tool bar, a lot of our best practices, I want to find the headings on the page, so let's go back to the UIC page.
I can go to the navigation, and bring up a list of headers on the page. And it will basically highlight the headers on the page so I can see where they are. So again if I ‑‑ if I just put headers into a page, and I use a browser like IE, there's no external advantage to me, you know? If I want to find out if there's headers in IE, I either have to have a plug in for IE that will tell me or I have to look at the source code. So a lot of this hidden markup is made visible through the Firefox accessibility extension to it made it easier. And it will tell you if there's a problem on the dynamically generated page.
You can also get an FAE report. Somebody will send me a URL, usually with a message like this. I just purchased, and I was wondering if it was accessible. I mean what we'd like is, I'm thinking of purchasing this, is it accessible? Not I just purchased this, oh, can you tell me if it's accessible? But at least they're asking if it's accessible so I guess that's some progress, right?
So what I could do here is under the tools menu, I can go get a dynamic FAE report. And this will also demonstrate ‑‑ so I can get ‑‑ a hundred percent on the dynamic HTML and I think that that's one of the issues with UIC. I think some of the accessibility stuff is added dynamically so FAE may not get it. But what I can do is take this URL with any FAE report and it send it to somebody. I think that's a powerful feature with FAE. If you evaluate a website and want to share it with the web developer you can share the information and one of the things about make the FAE tool available publicly for free is now people can use the same tools to evaluate accessibility, and just because you pass a tool doesn't necessarily mean you comply with all of the accessibility requirements. We focused on things that we can check automatically. There are still manual requirements that need to happen, but people are getting a lot better feedback related to accessibility.
And again the Firefox tool is free. And I guess is my ‑‑ how much time do I have left?
>> KIM CHARLES: About 15 more minutes. Or take questions.
>> JON GUNDERSON: I know we're a little behind schedule so this is basically ‑‑ so what this tool does allow us to do is now go into web applications, and very easily check for accessibility features to find those hidden features within a page, either generate a report or be able to find out what is the heading structure here, are the form controls labeled properly on this dynamically generated web page.
So maybe we'll just take some questions.
>> KIM CHARLES: I have a question. If you can go back to the first report that you ran.
>> JON GUNDERSON: The UIC report?
>> KIM CHARLES: Yeah.
So for example, when you see failed, six pages. Is there further information ‑‑
>> JON GUNDERSON: If I select this link, it'll give me the URLs of the pages that failed.
>> KIM CHARLES: Okay.
>> JON GUNDERSON: I guess it just ‑‑ it's taking a minute here. It's supposed to.
>> AUDIENCE MEMBER: John, while we're waiting for that, have (inaudible) like target, when they lost the lawsuit?
>> JON GUNDERSON: There's enough commercial companies contacting target. We're not a commercial company, so we're not ‑‑ I'm sure high soft and DQ systems and there's a bunch of commercial companies out there that are knocking on their door. They have a lot of marketing people. I'm not a businessman. That's for sure. But if they want to use it, they could.
I'm not sure why we're not getting page reports here.
Oh, because ‑‑ oh, because we did just one page report. Archived reports. Okay. Here we go.
So here we go. Now it shows you the six pages, and if you click on this link here, it'll take you to that page level report, so this is the report just specifically on that page, what on that page passed or failed. And you can look at all the pages, you can get a list of all 30 pages that it checked, and go to those page level reports.
And the new version also under archived reports, there's a new manage report feature, so if you want to keep reports around, you can actually archive reports indefinitely. For the older version for people, about every two weeks the previous year report was purged but if you want to keep a report around you can tell it to archive up to five reports. If you need more than that, you can contact us and if you buy us lunch we'll probably give you more.
(Laughter.)
>> KIM CHARLES: The other question that I had is if it does find an error and it tells you, for example, that there's a problem with subheading, will it pull out for you the part of the page so that you know where that error is so if it says the subhead is not nested properly, do you have to go in and look at the code? Will it pull out for you and say this subheading or at this point in the page?
>> JON GUNDERSON: Right now we don't have line number information or anything. Partly because a lot of dynamically generated pages, line number doesn't mean anything anyway. But that's where the Firefox extension comes back. If it says subheading, you can go into the navigation feature and look at headings, and it will provide the ‑‑ it uses the same rule set, so you can see where the error is, and you can highlight it on the page. We do have a new resource under the best practices that we just started developing.
And this basically talks about one of the strengths and weaknesses of both of these tools. So what's the strengths of the FAE, and the same with the Firefox. We also have an FAQ we're building so as we get questions like that, we're trying to answer them. In terms of, so for example, a recent issue was why does the number of form controls different in FAE than in the Firefox extension? Well, the reason ‑‑ well there's two reasons why it may be different. One is that the Firefox extension, if any of those forms were generated dynamically, it would see those forms where FAE wouldn't. At least not at this point. We're working on a feature that will at least get some of the dynamic content. The other reason is is that FAE, the best practices rules don't always apply to every form control. So for example, input elements need a label associated with them, but if it's an input type submit or button, it doesn't need a label. It uses the value attribute. So the rule for label may apply to 24 controls even though there's 25 because of the submit button. So it says there's 24 controls that need a label. There will be another rule that says the submit button or the button type needs a label, but when I go to the Firefox extension, you see all 25 controls. People say there's 25 here but this says 24, why is it different? It's because the rules don't apply evenly to every form control so we're trying to build a database, because that is confusing to people, why are things different. And so we're trying to help people out with that.
Other questions? Yeah?
>> AUDIENCE MEMBER: Currently the FAE doesn't check ‑‑ it doesn't let you know which IITA guidelines are being checked. Are there any plans in the works to address that?
>> JON GUNDERSON: Well, the best practices document, if you have a mapping of IITA rules. They do have a mapping of which rules apply to which IITA requirement. And so there are some IITA requirements that we don't have a best practice for yet. One of the things that we want to build into the future versions of FAE is are the things we don't check that we provide a manual feature for. So we can't tell you about this feature, so our first priority was to implement the rules so we could provide some types of feedback, either something failed or something was a warning, and so now the next future versions of the tool we want to add a feature, okay, we couldn't tell you whether you're accessible or not but you should also be considering this. Just because we wanted to minimize the number of manual checks, because one of the things we saw with web developers, if it there's a lot of manual checks, well, most ‑‑ a lot of developers ignore them anyway, so we didn't make that a high priority, but we do want to address that so people get a better view, and also one of the things especially we have a purchasing working group is we want to provide a feature to develop an IITA compliance report, so I run FAE, I could click a link and I would get a report for IITA, other things we check, and in a format that could be edited for people to put in their manual checks if they want to. So that is something we do want. One of the critical things now that is getting into the purchasing process, people, some more things for people to check accessibility.
>> AUDIENCE MEMBER: What's the ETA on that?
>> JON GUNDERSON: You can send a comment to the FAE thing if that's important to you. That's always good for our developer to know what people want. So good for me to know what you want too. So if you send a message saying that's really important to me, or and get your friends to do it, it'll probably become more important. You can join our best practices working group.
>> AUDIENCE MEMBER: I just did that.
>> JON GUNDERSON: And come there and say this is really important to me. I'm not building tool for myself. I'm building it for you guys. So if you think it's important, it may not be my top priority but it may be yours, we want to build that into the tools. So it's participatory democracy. If I don't get feedback, we just do what I want to do.
(Laughter.)
Yeah?
>> AUDIENCE MEMBER: I'm curious. In your experience, what are the top two or three accessibility rules that developers tend to ignore that they can easily incorporate or techniques that they could easily incorporate?
>> JON GUNDERSON: One of the things that surprises me, even after people have taken my classes is that I look at their web pages and they still didn't get form control labeling. And this past year we extensively revised our understanding of form control labeling. A lot of help, Mike Scott here who had a lot of input and practical experience into that and that's probably one area and it's probably the one area where putting in labeling doesn't ‑‑ is helping just a small group of people, and there's really ‑‑ there are some benefits to labeling properly for mouse clickers, but that's probably the biggest area that I see that it's hard for people to get is form control labeling. So that's one of the reasons I'm teaching this class, is that I think it's an important topic. I know Mike, do you find that too, that people have a hard time with that.
>> AUDIENCE MEMBER: It's not that forms are difficult but people are not aware of it. And it's frustrating (inaudible) more often than not they're not there.
>> AUDIENCE MEMBER: We ran out of those too, by the way.
>> JON GUNDERSON: Okay. But you can go to the website, if people are interested in the class, you can go to the website and find information about the class. About but I think there's other things coming up with the labeling. Some of the wick ed (inaudible) and required. So we want to talk about that. There's some new markup available using the aria technologies that will make it easier to use form labeling control. There's extensive things happening with Firefox and Microsoft Internet Explorer and the jaws screen reader so I think there's new things coming out that will help people create more accessible forms too.
>> KIM CHARLES: Okay. Thank you very much, John.
So I think we touched a little bit towards the ends there on our next topic. Working with vendors. I know that a lot of us really don't have the resources to build our own sites and so we depend on working with outside vendors to create sites, and if you are at one of the universities or a state institution, you still have a responsibility to create a site that's accessible and so how do you do that with vendors? We've asked Mike Scott to speak to us on that. And Mike is an assistive technology and accessibility specialist currently focusing his efforts on improving systems for people with disabilities. He works with a wide range of clients to help (inaudible) design and develop new systems and train staff in how to implement accessibility in design and development. Working as a consultant to the State of Illinois, Mike has headed many initiatives including development of the web accessibility standards and the Illinois technology accessibility standards act. Prior to working with MSF&W, he worked with chief engineer with the Illinois Department of Rehabilitation Services where he specialized in using assistive technologies to able people with disabilities to do their jobs. So welcome, Mike.
>> SPEAKER: I'm going to talk just a little bit about the procurement side of things and I think we touched on it a little bit to this point so far.
Let me see if I can bring up a website here while I'm talking.
John talked a lot about how important it is for developers to be aware of proper accessibility techniques. And went over some of the very useful tools that are available to help developers in making sure that their websites that they're working on are accessible and we talked about some of the things we can do in addition to that this morning in our accessibility 101 session, and it is ‑‑ it's probably even more important that those of you who are involved in procurement, the case where you're not necessarily building your own system but you're buying or hiring people to build a system for you is probably even more important that in those cases we know what we need to do in order to address accessibility. When you're building a system, you can kind of learn as you go. The if you make mistakes, you got time to fix it you can get feedback and recoup. But if you write a contract to a vendor either to purchase a product or lay out specs for a vendor to build a system, you're going to get what you ask for so it's important to be aware of how to ask for the right things.
The good news is when we did ‑‑ we did some extensive work with the State of Illinois, Central Management Services procurement group, the folks who are involved in the purchasing that is done statewide. I don't know how much CMS works with universities directly but we found that the experiences we had with the state agencies are similar, not exactly the same but similarly to what you encountering in the university settings and with John's help we've had a chance to talk to the purchasing procurement agents from most of the state universities as well to get feedback and input and discussions of what the needs are and what works.
And actually part of the law, part of the IITAA, one of the requirements was that in addition to establishing standards that we've taken kind of a brief look at, one of the things that the work group had to do was to come up with some recommendations for procurement. Not hard and fast rules but some recommendations on what can we keep in mind when we're procuring either finished product or hiring people to develop for us, and if you are interested, the site that I'm going to be showing here just very briefly is the main IITAA site, the address is www.DHS.state.IL.U.S.AA. And we have a link to procurement recommendations and the nice thing about that, they are very short and sweet. Okay? There wasn't a whole lot that needed to go into this. And in fact through extensive discussion on what could work and what would work, we really boiled it down to the essence, the one most important thing that we can do in procurement, is summed up in this little three line sentence right here near the bottom of the screen. Basically what that is is the recommendation of language that should go into any document, in an RFP, request for proposal, invitation for bid or any type of documentation that's going to a vendor to tell them what we want, and the bottom line here is that basically states as required by Illinois public act 95308, all IT, including electronic information, software systems, equipment, developed or provided under this contract must comply with the applicable requirements of the IITAA as posted at this address. The bottom line here, the procurement folks said the most important thing we can do is get that out clearly in writing as part of the initial contract documents so that the vendors are immediately put on notice, we want this, we need this to be done, and by responding to this request for proposal or invitation to bid, you are going to be agreeing to do this, okay?
We didn't go into a lot of detail here. We don't list out the standards. We just put a pointer to the site, so it's a short and sweet statement. The good news is the State of Illinois Central Management Services they have actually worked this language into the boilerplate that is used for all state RFPs so this language is being included at least in the official state purchasing documents that go out. And hopefully the vendors will be getting used to it.
So the value of this statement, the value of getting this out here is number one we let the vendors know because we might know for ourselves that accessibility is important for us. The vendors might not know that. Wearing the vendor hat myself, we might run into the situation where we don't know exactly what the client was, what you want when you're asking for some things and we're in the reverse situation, we like to make everything accessible. Sometimes the client could care less. But the bottom line as a vendor the customer is always right. The bottom line here is we get that requirement out front and again it let's the vendor know we want it. It gives them some reference to some specific standards. What we saw a lot of times before this were in documents where the person putting together the RFP well intended would put in something like needs to be ADA compliant. Okay. Well as we talked about this morning a little bit, there is no such thing as ADA compliant. ADA is a general law that says that we need to accommodate people with disabilities but doesn't say how, so the IITAA like section 508 givers us the specifics. So we tell the vendor we want this and we give them some specifics so their developers can go in and test their system or put them in the requirements documents so they know what they need to do and lastly and maybe most important, it allows us as a state entity, to share some of the burden here. Under the IITAA it is the state's responsibility to ensure that the website is accessible. However, by putting this language into our contracts, it then (inaudible) I know I'm responsible for doing this, now by signing this contract, you're agreeing you're going to do it for me and we have seen cases where with this language in place, when it didn't work out, you know, because of mistakes or misunderstand, or whatever, there's no guarantee that having this language in there is going to make it actually happen, but when it doesn't work out, you can go back to the vendor and say hey, wait a minute I got it in writing here that you were going to do this and now rather than it being my problem it's their problem, or at least it's a shared problem. That's more often the reality. So it gives us some leverage then when we go back to say to the vendor, hey wait a minute you didn't do what you said you were going to do, you need to make this right and no I'm not going to pay for you until you make this right.
Interestingly there was not under the IITAA but there was a similar situation with the state of Arkansas that we went to often where they have a vendor come in, had determined that they were going to put an accessible system was going to go in. They didn't do it. They didn't make it accessible. The state got sued after the end of the project by a couple of employees who were blind, and the state lost the lawsuit. And the court of Arkansas said yes you're in violation of Arkansas's laws, in violation of the ADA, and the state you have to make this better. The state was able to go back to the vendor and fairly recently the vendor said you're right, we agreed to do this, and the vendor said we're going to go back and make it right. We're would rather have the language in here to make it better in the first place. However in the case where it doesn't work out, it gives us that leverage so we can go back and we can say it's not just our problem, the vendor, you're going to help us take care of this.
So we called that step one in addressing accessibility. Get that requirement out there in writing so the vendor knows what's expected of them.
Step two, there's three steps. Step two is get some feedback from the vendor. Get an acknowledgment back from the vendor that says yes we understand what it is you're asking us to do, and maybe even better demonstrate to us, convince us that you know what you're talking about when you tell us that. Of course every marketing person who is out there knows that when a client asks does your system do, you don't even wait for the rest of the sentence. You say yes, of course it does that. If it doesn't, the next version will.
They will tell you yes every time, because that's their job. They're supposed to get the sale and it's the engineer's problems to figure it out. It's good to get the requirement out there but almost every vendor is going to say we're good to go.
The next step is get them to give you some feedback. What John started to mention, we're trying to follow the model that the central government laid out is using a tool called a voluntary product accessibility template and this is a form that kind of lists out the accessibility standards and allows the vendors to check boxes and apply a little comment on how they did it. This is not a bulletproof solution. It's not a magic bullet. It doesn't guarantee that they're not lying to you but it does make the vendor sit down and think and probably what happens at that point the marketing person who has said yes we're doing it, they probably take that document and they probably go to the next step. They hand it off to somebody in engineering and say does our thing do this and at least they give it some thought. Again it doesn't guarantee that they're going to tell you the truth, it doesn't guarantee that they're not going to make mistakes in interpreting that but it improves our chance that we'll get what we want which is ultimately a system that it is accessible. So we're working on developing the documents, and we've got some posted up here and I know John is working on some versions, and he's been working particularly with the university procurement folks. So we've got the start off the IITAA website of some IITAA, V pats and modeled off the federal ones. So most vendors should be familiar with the idea of a V pat. The federal law has been out since 2001. There are not many IT vendors who have not touched at least the federal marketplace. They should know what it is. Worst‑case scenario, you ask have you done this for the feds. Get that. It's a part. We're working on how to make this even better and I know John has some drafts up here of the IBHE where we're working on getting even better feedback. How do we ask the questions so they don't only check the box and give us some pat answer but encourage them to give us something really meaningful and it sounds like they know what they're talking about. So we're working on improving the V pat but we're talking about several steps in a process. The first step getting requirement out, the second step get some kind of feedback, whether it's a pre‑completed V pat or they check the boxes or whatnot and then lastly, the last step in the process that we're still figuring out how to accomplish this, but some actual testing. So how do I ‑‑ okay, vendor you said you're going to give us an accessible product. You checked off all the boxes and said the right things. Let's actually see it and we would certainly encourage you whenever you can to ask the vendor, demonstrate, can you ‑‑ not only can you check the boxes but can you show us, give us a demonstration of your system working with jaws. Tell us what you did. Have you done tests with zoom text or dragon users, to actually see some demonstration and testing that proves it. We know from working with procurement folks that that's not always possible. Sometimes the time just doesn't allow but we're working towards the ideal situation is we can ask for all of those things.
And lastly, and to tie back into the tools that John was demonstrating, we do know there's tools out there so even if the vendor might not be able to do the test for you, you can take FAE and if it's a web based product you ask run it against the vendor's site or the vendor's demonstration site. Or you can take the checklists that we talked about this morning and you can run through some of those tests, so we know we've got some tools out there that even if the vendor can't step up or the vendor can't demonstrate you have got some tools where you can easily and quickly at least get a feel for whether they're in the ballpark or not and again a little bit of progress is better than no progress at all. We recognize that we're not near a hundred percent of the way there. We're not guaranteeing that our systems are going to be accessible, but hopefully we are significantly improving the likelihood and improving our success rate by doing just a few small steps so that's the essence of what we recommended and working with the state agencies and we're working our way through it. We've had some good cases, and bad cases, a lot of times we'll have vendors come back and say we've never heard of this accessibility thing before. You're the only ones who want it, which I don't buy for a second, but a good thing is we've got a consortium of folks who are coming together so we can come back and say we're not the only ones. We're working through this. So really that covers what I wanted to share with you today, so we've got a start, we've not some information out there and we are improving it constantly and we certainly would encourage you to provide your feedback if you're involved in that aspect of dealing with accessibility systems.
Does anybody have any questions?
>> AUDIENCE MEMBER: We were working with a vendor who, this was earlier, but in terms of IITAA (inaudible) was asking, okay, tell me what tool you're going to use to check (inaudible) the earlier version of the FAE. So in this case, I created this piece so it passed the FAE at the time. But when we looked later into the code, it was not accessible. The purchaser though would not have known that, not being ‑‑ having the technical skills to know that. I mean there may not be any way yet to check that, but do you have any advice.
>> SPEAKER: Sure, the question was or the scenario that Debra was telling us about was the vendor particularly said we know you want your system to be IITAA compliant so we're going to make sure it passes FAE. And it's a step in the right direction. It's better than not passing FAE but I think something that's good to be ‑‑ to always keep in mind is vendors will look for the easiest thing and the most objective thing they can do and certainly the testing tools like FAE are a good portion of that. However all of us who are involved in accessibility and John mentioned earlier, there is no tool out there that exists in this world that will test everything that is covered in the IITAA standards, the section 508 standards, the other standards, it just doesn't exist. So I any we need to look at ‑‑ I think it's a good idea to say one part of demonstrating compliance is showing that you pass FAE or another tool like that and that's a good step but I think we need to let the vendors know that's not all. You still need to be ultimately what we are contractually obligating to do or you're obligating yourself to do by agreeing is to comply with these standards. And passing an FAE test is a part of the way there. But in the bottom line, they are still responsible for (inaudible) that can't be tested. You're right, Debra, there's probably no magic answer to it and it's a matter of hopefully the next time we do it we're better than the last time. But it's a good experience to share. Thank you.
>> AUDIENCE MEMBER: Mike, even though we're working on getting some procurement statements in our documents in purchasing, how can we assert this compliance on new versions or add ons to existing systems that we already have?
>> SPEAKER: Sure. That's a good question. How can we address new versions or add ons to existing systems?
One thing that's important to recognize about the IITAA, as I mentioned this morning, it's a go forward law and it is about if I've got an existing system in place, it doesn't say I have to go back and fix it. Certainly you can and it would be a good thing to do.
Because the law kind of gives us that out, it's almost kind of like we're letting people off the hook a little bit. And what we do in that case, we wanted to recognize what's required by law but we also want to encourage people to address accessibility even if there might be a loophole but what we've done in working with vendors is certainly starts with educating them. Say we would like you to be compliant, you know, this is a state law, it may not be in your current contract but it's going to be one of these days. You know, what can you do for us? And see where they'll go voluntarily. We try to entice them by saying hey the IITAA, the law is based on (inaudible) 2, it's based on where section 508 is going to be in a year from now. What you do now is going to benefit you. There are 20 states including Illinois that have laws about accessibility. There are 48 states that have either a law or some kind of policy directive or something like that. The federal government obviously is a big player. And it doesn't work all the time, but we have had a few vendors where you see the dollar signs appear in their eyes and they say, this is a real competitive advantage to us, especially if you are in a position to be able to help. And we do that a lot with the state, you know we'll say vendor, we need you to do this, and if they show any kind of interesting in cooperating at all, we say we can help you, provide technical assistance, training, help you along the way so they see it's a competitive advantage in the long run. So if you can say our people can help you or point you to resources and convince them it's in their best interests in the long run. Sometimes it works, but not always.
>> AUDIENCE MEMBER: One of the types of vendors I encounter very often is textbook publishers and many of them include many electronic supplements and things like that along with the textbook that they're trying to have our students purchase from. Is there anything that's out there that would score how compliant different textbooks potentially are so that we might make a choice that's more favorably disposed to ‑‑ more favorable towards accessibility?
>> SPEAKER: That's dealing with electronic supplements or electronic versions of textbooks there's anything that would help us tell whether this one is better than that one. I don't know that there's an answer. I don't know that there's something that will help do that. If it's in HTML format document. We've got FAE. I assume it's not in that format. We have been working and talking about developing best practices for PDF documents. Another resource I would look to would be California State University systems, California is ahead of even Illinois in this game. And they have been doing a lot of certification. They recently, not of textbooks that I know of, but they recently did some extensive reviews and certification of learning management system vendors and they went through and reviewed Blackboard and angel and you name it. And they said here are the two that they feel meet the California guidelines, which are roughly equivalent to what we have.
So California State University system is a good place to look for that. The first place I'd go looking. Does anybody else in the room know anything about textbook document accessibility?
What's the format of the electronic supplement. Is it PDF?
>> AUDIENCE MEMBER: It could be anything. Power Point, flash PDFs, it can be anything that goes on.
>> SPEAKER: We're trying to line up the different documents kind of, the different document formats in order of popularity. HTML is first, PDF is on the radar with the best practices group. We've talked about flash probably being next and we're trying to get there and identify for each of these technologies, what are the best practices, can we make a tool that will test it. There are some tools out there that will do a little bit of work with PDF. I've not seen anything yet that touches flash. It's on the radar.
>> SPEAKER: (Inaudible) emerging standard for publisher providing content. But it's still a moving target. IMSS.
>> AUDIENCE MEMBER: (Inaudible) connected to the California system, and they also work with a consortium to use standards to produce textbooks on V text. They don't have the recommended publisher per se, but they will give you a list of publishers that they work with.
>> SPEAKER: Wonderful. AHEAD. It's the acronym, and the daisy consortium are both two good resources there.
Okay. Any other questions?
All right. Thank you very much.
>> KIM CHARLES: Thank you, Mike.
(Applause.)
So if I could just add a note to what Mike was saying. You know, if your department here at UIC is going through a contract, an RFP process and you have questions about this, please be sure to send an e‑mail to access web, at UIC.EDU and we'll try to walk you through, you know, the tools again, the tools that maybe you can assess the vendor's site or their sample sites or how you can work with those vendors.
We're going to be putting up quite a few of these links on to the UIC web accessibilities committee's website so look for those later this week.
So our next speaker is Tim Offenstein from the University of Illinois at Urbana‑Champaign and he serves as the campus accessibility liaison through the educational initiative. In this capacity he works with campus units, assessing and evaluating their websites for accessibility issues and providing training services which help them bring their sites into compliance with the IITAA. He also serves as chair for the UIUC webmaster steering committee. He works with program that works with web developers to bring their one seats up to code. I've asked him to come to us and talk to us about how UIUC has been successful in building their webmaster community to share resources and improve their accessibility of their websites.
Thank you, Tim.
>> TIM OFFENSTEIN: First I want to say thank you to Kim and Kevin for inviting Jon and I and we brought about a dozen people up here from UIUC. We appreciate the opportunity to share with you.
The webmaster's group actually started ten years ago this year. We got a kickoff from our in term CIO, who was interested in investigating how to join the webmaster community together, giving people an opportunity to network and kind of build the community. Out of that, we had the opportunity to grow awareness and education about accessibility.
So we kicked off. We started with a list serve of about 25 people. We are now up to over 600 people on our list serve, and that is our core method of communicating with the campus. We communicate accessibility through that, in trying to raise people's awareness. We also try to use that as a method for informing people about things like the Illinois identity standards and things that are kind of coming down from administration, directions that they want to go and so forth. But we're very much a grassroots initiative, and that's kind of what motivates us.
In fact I would like to invite all of you to attend, if you're available, on the 22nd of this month. We kick off our 10th anniversary. We hold an annual webmaster forum where we bring people together. We have a keynote speaker. Our speaker this year is Luke Rebluski, who is a forms expert and he's going to be talking to us about how to design usable web forms.
We also have about six or eight different breakout sessions. They're run concurrent, covering all sorts of different topics. If you go to www.webmasters.uiuc.edu, there's a link to our webmaster forum that will tell you all about what we're trying to do and what the breakout sessions are. And if you register, we offer a free meal. So ‑‑ and it's a good one. So I'd like to invite all of you to be sure and attend that.
About two years ago, I had the fortune of spending about two months compiling an overview of all of the websites on the UIUC campus, and I evaluated them on about seven different criteria. FAE was one of them and also the compliance with W C3 standards, whether or not they use tables or CSS and so forth.
In that initial overview, we had a total of seven sites out of about 380 sites that were what we called 100 percent. They were completely W 3 C compliant, completely FAE compliant.
I'm happy to say that in the last report, we did back at the first of this year, we now have almost seven percent of our sites are what we call 100 percent. We've been pushing this idea of calling it the 100 percent club and it's been pretty well received. But what we're doing is we're trying to raise awareness, we're trying to get people on board, and aware of how easy it is to make their sites like you saw with the UIUC site, or the UIC site, 100 percent compliant.
In educating people and we've discovered by the way that there are two basic components. Either people are very willing but just uneducated about what they need to do to make their sites compliant, or because of administrative oversight or whatever, they're not aware or they're not sensitive to the needs. Those are the two areas that we're trying to address in raising awareness and recognition of what people can do.
So this allows us an opportunity through the list serve and through the webmaster forum to educate people, to bring them on board and to show them these are some easy things you can do to your site that will vastly improve its accessibility.
So these are some of the things that we keep trying to do.
And I lost my train of thought.
>> KIM CHARLES: In between your annual event, what are some other things that you do?
>> TIM OFFENSTEIN: Thank you. That was my train of thought.
A couple of other things we try to do through the webmaster forum is we hold monthly brown bags. We try to keep them on a monthly basis but some months we'll have two or three brown bags. Other months might have one. When we do our webmaster forum, we ask for input from the participants on areas that they would like to have a brown bag presentation on. And the brown bags are over the lunch period. They're usually just an hour long, and this gives us an opportunity to address not only accessibility, but how to build affective forms or how to investigate content management systems, all sorts of things. And it just depends on what kind of feedback we get from our groups on the areas that they're interested in.
So this is a very important way that we can keep the momentum going because we do this on sometimes every other week basis. We do it all over campus. We have a lot of different meeting rooms that are available to us, and so we try to space it out so that people who are on one part of campus can get to one brown bag and might miss another one, but we try to make it available to everybody on campus.
Yeah?
>> KIM CHARLES: I was also going to ask you about your 100 percent club. Is that maybe something that people can put on to their website that they're a hundred percent or how do you encourage that? And you need to talk about your awards too.
>> TIM OFFENSTEIN: One of the things that we've been debating and kicking back and forth is an FAE icon, and I keep bugging Jon about this, and what we want to do is promote this. We do it through giving recognition to everybody who gets ‑‑ attains that 100 percent level so I send out a note to the list serve saying congratulations to so‑and‑so, and we're also looking for an icon that people can attach to their sites that say this is what I've attained.
What we want to do is give them special recognition for their effort. So that it's a goal. And that's what they're shooting towards.
Kind of in conjunction with this, each year in our annual forum, our steering committee collects nominations from all across campus of people who think their website is a great website. We give them a nomination form where they can check off different things that they think their site is ‑‑ has strengths in, and then at the forum, we give out awards for these sites that are just exemplary sites. This gives us an opportunity again to promote accessibility, because that's one of the standards or areas that we evaluate sites on.
So this raises awareness, in that and so we've got web developers who are striving to at those components into their sites.
This year we have kind of changed things around. We used to do it in three different categories. Content, design, and programming. It became very difficult to judge sites based on programming, and content was also difficult. So we kind of mix it up, and this year every site on campus that's nominated will win. In other words, they're all going to get a certificate of recognition, because if somebody cared enough to say I think this is a great site. Then the committee is going to take out of all of the nominations, four sites that they think are outstanding, and those four sites will get plaques and special recognition.
If you decide to do a webmaster group on your campus, this is somewhat of a controversial area. We've had people get very upset because their sites didn't win.
(Laughter.)
Or last year we had some negative comments because we were judging very strictly on accessibility. And some people came back and said, well, you know, my site really doesn't need to be to that level of criteria. So you can encounter some flack doing this. But I think it's well worth it, and in spite of the controversy, this has been a component of our webmaster forum where people are always saying, okay, I'm looking forward to this. I want to see what happens.
So that's a good component. Yeah?
>> AUDIENCE MEMBER: You said you did testing not only on the FAE but also wick ed? How did you do that testing?
>> TIM OFFENSTEIN: On the web site, there's a site called validator that will automatically test your site and it give you a rundown on whether your site is compliant or the ways it's not compliant.
>> SPEAKER: It's not wick egg. Its ‑‑
>> AUDIENCE MEMBER: How can we collaborate between Chicago and Urbana so we can listen to your brown bags and you can listen to ours. But even if we just use meet me teleconferences, that might be valuable.
>> TIM OFFENSTEIN: Yeah. I am happy to announce that this year we're going to live cast our keynote speaker. In the past we have not had this opportunity. We didn't put it into the budget, but this year we were able to do that, and so hopefully next we're we'll be able to ‑‑ next year we'll be able to broadcast all of our keynotes. We're going to start streaming more of our brown bags. We do have a few but they're outdated at the moment. So that's definitely something we want to do.
Anybody can join our list serve. Initially when we kicked it off, it was limited just to campus people but now it's wide open, and we encourage you to do that, because the intent is to give you an opportunity to share ideas, to post questions or whatever. And this would be a wonderful way for us to collaborate with you.
We have people coming from Madison, Wisconsin, to our forum. And from Springfield and all over the place, so we welcome the participation and encourage it.
>> AUDIENCE MEMBER: How do you encourage content managers to be involved with the group? What are the challenges? I found that that is ‑‑ people that are just working with content, content managers will tell me, well, I don't know if I should attend that meeting or that forum because it's just going to be technical talk and I won't understand it. I'm assuming that you do have quite a few content managers people in your group. How do you encourage them to participate?
>> TIM OFFENSTEIN: Well, as you're probably all well aware, web development entails a number of different strata, and one of the intentions of our original charter with the webmaster group was to include everybody who had anything to do with web development, and that was one of our initial reasons for including three different categories. We have design, content, and programming. And we tried to do our breakout sessions so that a programmer could easily identify the different sessions that would be applicable to him. Content people as well.
Also when I put together the steering committee that we came up with, it was very important that this committee not be made up of entirely tech oriented people. We wanted to include secretaries. We wanted to include everybody so that we had a good wide range of the full gamut.
The reason being is that oftentimes the secretary is your number one user of your website. If she has to answer or he has to answer questions over the phone, they've got to be able to go to the website to pull out that information.
So it was very important to us that we include all these people. It's also important in your brown bags that you have a different strata or different levels of expertise in the brown bags. And you want to watch out for that when you go to advertising, because oftentimes, as Debra mentioned, people will just blow it off. They'll say that's too technical of a conversation. Especially when you use terms or jargon like CMS. People will say or a secretary or an administrative person will say that's only for my tech people. When their part of the work flow, it's very important that their voice is heard in determining what kind of system is going to work best.
So you want to be sensitive to those types of things when you go to advertise the services that you're going to be offering.
Thanks, Debra.
Any other questions?
Well, try the website, www.webmasters.uiuc.edu. Check us out. We are in the process of moving towards a druple system, so our website is kind of in transition. But there is a link there for the event that comes up on the 22nd, and we would love to have you come and attend. Thank you very much.
(Applause.)
>> KIM CHARLES: Thank you, Tim.
Okay. We're running out of time.
>> SPEAKER: One more note. We would not be where we are today in web accessibility without the webmaster's group. That was essential to learn about accessibility. Without that group we would not be where we are today.
>> KIM CHARLES: And just a couple more things before we wrap up because we are running out of time. First, I do want again to thank all of our speakers. We really appreciate that you took your time today to come and talk to us.
One, I wanted to make sure that our campus web masters knew what resources we do have available and to start the conversation on what you would like to see us do with our campus community to move us forward, where maybe we'll be at the point that Tim and Urbana folk are.
So we don't have much in our web development workshop these days. The information that we used to have up there really became outdated, so we've kind of stripped it down to some links to some information. Other information for you.
A couple of things I want to point out is we do have a list serve that you are all welcome to join. It's not just for us to announce things to you. We want you to have conversations with each other, and ask questions, ask for resources, ask for help, offer help. And there's instructions on how to sign up for that here.
Also recently we have started to ask departments to designate an official webmaster or web masters for each unit, which gets listed in the A to Z directory just like your reach contacts and there's directions here under the department webmaster designations, there's some directions there on how you can find out who in your department can make that designation and then give them the instructions to go ahead and do that, to add you to the list.
Again that is really us trying to understand who you are and hopefully get the conversation started for our community.
And in addition to some links to the A triple C and other sites we also have links to the web accessibility website, which does talk to how to test your site, what kinds of tools you can use to improve the accessibility of your site, and we'll add some links from today to that as well.
One thing I would like for everyone to think about is you know, getting signed up on our list serve and let's start the conversation, what kind of brown bags would you like to see offered here at UIC, what other kinds of social media tools would you like to have available to connect as web masters. Would you like us to set up some discussion boards in addition to the list serve? Do you think the list serve would be enough to get the conversation started? So give us your ideas and let's talk.
Any other questions?
Thank you all for coming.
(Applause.)
(End of session.)





