APS11: The Status of Web Accessibility in Higher Education to People with Disabilities

Announcer: This is one in a series of podcasts from the HighEdWeb Conference in Austin 2011.

Jon Gunderson: I thought I'd just start out with a little bit of what I'm going to talk about today, basically a little bit of how I came into accessibility and how I approach accessibility from a developer's point of view, and some of the things that we've done at the University of Illinois to support the development of tools.

I've just recently, like, yesterday, finished collecting data on over 26,000 websites to look at where are we in terms of accessibility. We'll go through some of that data.

Some of the recent litigation against institutions of higher education and what are the results or what are some of the implications that people probably need to consider as they look at their own IT and web development policies.

And important things. Where do we need to be going? What are the next things we need to be thinking about in terms of accessibility? What are the technologies we have to be concerned about?

And I'm always looking for people to help, or people who want help. How do we start bringing people together to get answers to questions about accessibility to find out what are the best practices for implementing an accessibility feature and trying to help share those with other people?

Any questions before we get started? No? OK.

When I first got involved with web accessibility back in the late '90s, I started... Everybody familiar with the web content accessibility standards like WCAG and Section 508? I didn't want to spend too much time reviewing those things. When I started going out and talking to web developers about accessibility, there's this WCAG thing that had, what, 67 check points in 16 different guidelines, and there was a lot of stuff for people to look at.

Some of it seemed to make sense, 'OK, alt text for images. I get that,' and other things didn't seem to make so much sense. WCAG 1.0 is really dated now because it requires stuff to work without Javascript-enabled. Now we're in the WCAG 2.0 world which has another 67 success criteria, and then pages.

So web developers started to come to me and say, 'Jon, that's all good and stuff, but can't you just tell me what you want me to do? And if it seems reasonable, I'll do it.' So we started working with web developers and continue to work with web developers to solve their design decisions and look at the accessibility implications.

How do we use markup to design for accessibility? A lot of people, I think even in the web accessibility community, have a repair model. People build stuff, and then they test it to see, 'Well, what do I got for accessibility? What do I need to fix up?' So we started something called the 'best practices'.

So how do we design accessibility into websites? We have a website that's in the process of being updated. This is kind of our Web 1.0 world of accessibility. We'll talk a little bit about the transition to Web 2.0 later. One of the things we're going to have to think of.

Some of the things we did to support this best practices design is start developing some tools. And there are some tools here. These are free tools. One of them is called the Functional Accessibility Evaluator. You can put a URL in and test a whole website for the use of these best practices principles.

There's some handouts in the front row if you want more information about where you can access and try these tools out.

Another tool, which desperately needs to be updated here is called the Accessibility Evaluator for Firefox. For some reason my inline link doesn't work. This is a plugin for Firefox that helps people inspect websites for accessibility features. So where are the accessibility features?

The current tool, we hope to replace in a few weeks, this one, again, is based on, I'll talk a little bit about what we're trying to do with these tools, but this tool has some problems.

I'm not really excited for people to download this version, but hopefully in a few weeks we'll have a new version out there that will have a whole bunch of new features and really be designed to help us with this Web 2.0 world in where we need to go for the next level of accessibility.

So we've developed some tools to help support the use of the best practices.

And this brings us to where we are now. In this new WCAG 2.0 world, one of the things we live in now is this dynamic web application. Chris Wilson was talking about all the new interactive content that makes the user experience so much better. Things respond faster. We talked about the systems anticipating my needs. I just start typing something in and it's already figured out what I'm looking for.

And these are all things that people with disabilities want, too. We just need to make sure that they are accessible.

And with dynamic content, we need to make sure that a system, especially assistive technologies, understand the same things that are going visually on the screen that they can get that information in a non-visual way.

One of the things we're doing to help support that is, again, in an open source way. Just like the Web started out with this free stuff that people could use and modify, there's something called the OpenAjax Alliance, and it's a consortium of major companies and other institutions working on dynamic web applications, but there's a small task force related to accessibility.

We're building an open source Javascript-based rule set to support analyzing websites and inspecting websites for accessibility features based on the WCAG 2.0 requirements.

The two tools I just showed you, we're right now in the process of updating those and integrating in this rule set into both of those tools. We're not quite there yet. But hopefully by the first of the year, we'll have new tools, versions 2.0, tools using this new rule set based on, again, this international standard of WCAG 2.0.

One of the things I've been doing with this new rule set as we've been developing it is I wanted to test it out.

So what I did as part of the technology that we're using is that I ran the rule set on over 26,000 pages, over 703 websites at over 188 universities to get a big picture of where we are in terms of accessibility, and also to test these tools to see if they actually can do what we wanted them to do. Can they actually analyze these websites and extract accessibility information?

The rules, again, are all written in Javascript, so we use something called HTML Unit, which is a server-based Javascript-testing environment to actually load the web pages and run the rules on the web pages on the server.

Here are some of the results that I found with this testing.

When we started working on web pages for accessibility... And actually, WCAG 2.0 now does actually have a titling requirement. WCAG 1.0 didn't ever talk about titling web pages. I was talking to John here earlier and he mentioned he worked with somebody at the University of Illinois, John Barkley, on some Drupal stuff.

Well, actually this came up with John Barkley when we were looking at the College of Education's website of our university. We were looking at Section 508 and WCAG requirements. But when we sat down and said, 'OK, well, here's our design,' one of the things we thought about, at the top of the page was the standardized banner that you, at least in those assigned times, I always thought, 'Well, that's kind of the title of the page, right?' "College of Education". And that was across pretty much on every page.

Well, if you think about it, though, if you are a speech user, the first thing, if you go to every web page and all it tells you is "College of Education", well, it doesn't really tell you much about, 'OK, what's on this specific page?'

So we started to think, well, what is titling a web page? Well, it really doesn't have so much to do with the banner anymore. It really has to do with what the subpage content is and what the title element is.

The title element, at least on many browsers, displays in the title bar of the window. Some browsers are getting rid of that. I think Chrome doesn't display the title anymore, but at least many browsers display their title. It will always be one place people could look at it.

But the other thing we thought about was, 'Well, what about H1 elements?' H1 elements we consider special elements because they allow people to put in, they could be a special marker to where the main part of the page starts. So if I'm a screen reader user, I can use the header navigation to go to the first H1, and that would tell me what the title of the page was.

So we developed an algorithm through some design work and said, 'Well, the title should contain some information about what website you're on and what subpage you're on. I'm on the College of Education, I'm on the Admissions subpage.'

And the H1 should contain the subpage information. So as I navigate around the page, I can just use the H1 key to find out, 'OK, what subpage am I on?' if I'm a screen reader user.

It also fits with web standards, because web standards people... Do we have web standards people in the crowd at all? Really? No?

Audience 1: [Indiscernible]

Jon Gunderson: Oh, OK.

[Laughter]

Jon Gunderson: Well, good.

Well, because part of it, H1 means, 'Well, that's a main topic.' That's the top of the H1 chain.

Yeah.

Audience 2: [Indiscernible]

Jon Gunderson: What we did is that the H1 content should be a subset of the title content, so the H1 is the subpage information and the title contains both the website and subpage information.

Audience 2: [Indiscernible]

Jon Gunderson: OK.

And then it also provided a check for us. We could actually look at what the H1 was, and the title content in some of our tools provide feedback to developers that that's not a subset or that the H1 was missing.

And that created a design pattern. How many developers like design patterns? When you start out, 'Well, what should I be doing with this markup?' or 'How should I be using it most effectively?'

Also, by using H1s consistently, you can set up your CSS stylesheets, you can set up all your templates to use that. And you can just reuse it or program it into your content management system, and you have an algorithm for generating titles for web pages.

So what we found here is that most web pages, 98% of the 26,000, had a title element, but only about 3% actually had H1 elements. So that was a little bit surprising.

Some of the other tests for use of headers is 'unique siblings'. If you have two H2s on a page, then they're both unique. And some web pages, people might not have unique headings, especially library pages where they repeat headings a lot. So sometimes headings aren't unique.

But it seems like people are using headings pretty appropriately. Proper nesting of headings. H2s follow H1s, H3s follow H2s, H4s follows H3s. So people aren't going from H1 to H4 to H3 to H2 kind of things.

And pretty much all headings had content. This is kind of a rule we had when we first started building some of our tools, because our tools look for proper nesting.

So people quickly figured out, 'Well, if I just put an empty H2 here, it seems to like that, because now I have proper nesting,' even though the H2 had absolutely no content. So I was curious to see if anybody was doing that.

And this next set of data is related to form control, and this is probably still the biggest issue for accessibility.

This first rule here is labels for form controls, which is a basic requirement of either WCAG 1.0, WCAG 2.0, Section 508 or any accessibility guideline, is labeling form controls. Of the 26,000 pages, only 48% of the form controls found on those pages had some type of labeling on them, whether it be title or label, encapsulation, label for, or some of the new ARIA technologies. So this continues to be a major issue. Assistive technologies can often guess labels, but sometimes they're right and sometimes they're wrong.

Having alt text on image input buttons. It's a lot better, 81%, but still, 20% of those buttons don't have alt text on them. So somebody using a screen reader really wouldn't know what that button did.

Legend around radio buttons. It's nice to have labels on radio buttons, but what is that group of radio buttons about? Legend and field set provide a mechanism for people to understand that. Only about 25% of radio button groups actually had the field set legend.

Most buttons had some type of label. Unique IDs, there's a lot of repeated IDs. So that would be confusing for assistive technologies trying to calculate what a label is. If you have repeated IDs, they might not know which label goes with which form control.

But in general, the labels are fairly unique. Over 94% of the labels that were actually used on the web page that were available were unique so that people could differentiate different form controls on the page.

So this is probably still a Number 1 accessibility problem and what I consider one of the most basic issues. Even 12 years after Section 508, we're still struggling to get labels on form controls.

Data tables. There are tons of data tables out on the Web, but this shows a little bit about the accessibility.

This shows that use of headings, either TH or TD scope, about 84% of things that we would classify as a data table.

One of the things we first have to do when looking at table markup is figure out if it is a data table or if it is a layout table. There's a little algorithm that looks for things that might make it a data table. And then if it's a data table, is it a complex data table or a simple data table? They have different rules for accessibility.

But in general, 84% is pretty good for having table headings.

Not so good with caption and summary. Yeah, go ahead.

Audience 3: [Indiscernible]

Jon Gunderson: Good question.

Some of the indicators for a complex data table are, one, row and column spans. So you have a column or row that spans more than one cell. Multiple headers, either multiple row headers. So if you have two rows of headings or two columns of headings on a page, those are triggers. If somebody is using a header's attributes on a TD cell, that is also an indication, and that header's attribute has more than two ID refs.

Those are some of the triggers for a complex data table. There aren't many data tables.

But caption and summary, at least if you look at the WCAG 2.0 requirements, require all data tables to have both caption and summary. And you can see here there's very low implementation of that.

In general, though, of the captions that are there,if there's more than one caption on a web page, they are unique.

And then one of the things is that WCAG allows people to either use TH or TD scope to define a header cell. I prefer people use TH, and it looks like in general people use the TH element fairly consistently.

Complex data and headers using the header's attribute. So it seems like most of them use that. Again, complex tables using summary is very low. Although when they do use summary, it's usually unique if there's more than one summary on a page. And almost no pages use caption.

So in terms of data tables, caption and summary seem to be the biggest issues for accessibility.

Image rule implementation. Alt text for images, the poster child for accessibility. Almost any type of automated accessibility tool will tell you if you have alt text on your images.

Here we have about 76% implementation. This is just basically having the alt text on an IMG element. Of the 26,000 pages, there wasn't a single image with a long desk attribute for a longer description.

But of the alt text, very few actually had a file name, used the file name as part of the alt text. So sometimes, early on, especially in programmatic system, people would just repeat the file name in the alt text because, I'm not sure why, maybe for tool tip or whatever, or they had to have some type of description for the image, so they thought the file name of the image was a good description, I guess.

This is just testing the length. Typically, most alt text is less than 120 characters, typically somewhat concise alt text so people don't have to listen to a long thing.

Audience 4: [Indiscernible]

Jon Gunderson: We use 120, but...

Audience 4: [Indiscernible]

Jon Gunderson: Some people set 100, some people set 150, 120.

Audience 4: [Indiscernible]

Jon Gunderson: Well, one of the things I want to do is test it to see, well...

Audience 4: [Indiscernible]

Jon Gunderson: Yeah. It's hard to keep up with assistive technologies and the quirks that they introduce into the accessibility system.

There's always exceptions to the rule with alt text length. What you say a certain number of characters, I really say, 'Well, I've got one...' Yeah.

Audience 5: [Indiscernible]

Jon Gunderson: I think, again, it depends on context. If it's an article about the runners themselves, you might say the runners' names running in XYZ race. It also depends probably on the context of the other information around.

But if it's like a graph, like if we were showing this bar graph, the alt text for an image like this might be image of rule implementation.

We actually have a data table below this, so there's actually a text representation of this. Here I would use markup to say that this is the equivalent of this.

But in general, or if it's just decorative like the image, it might not even be appropriate to be on the page. You might want to put it as a background image. That way you don't have to worry about the alt text at all. It's just generic.

Audience 5: [Indiscernible]

Jon Gunderson: It doesn't know about background images. It's not a part of the markup. It depends on if it's decorative or what kind of information and the context of the page that you're in, and also the context of the other information around the image.

Audience 6: [Indiscernible]

Jon Gunderson: If it's purely decorative images, WCAG 2.0 says that you should set the alt to null so that the image doesn't carry any information on the page.

Audience 6: [Indiscernible]

Jon Gunderson: No spaces. The screen reader will ignore the image then.

Audience 6: [Indiscernible]

Jon Gunderson: Just empty string. I should've said empty string.

Audience 6: [Indiscernible]

Jon Gunderson: Right, no spaces. Right. You're basically saying this image doesn't carry any information on the page.

So that's the easiest way. With Web 2.0, some of the ARIA technologies is another way to do it, too, but probably not appropriate if it's just an image in like a content management system.

We have one rule related to layout, so that's basically looking at the nesting of tables of layout tables.

This basically indicates more than two levels of nesting, so it seems that people aren't using tables for layout as much as they used to. So that seems to be a positive thing. A lot of people here raise their hands with web standards, so people are probably using CSS a lot more for layout. And also moving to that, it allows you to move to mobile web applications because you can just change the stylesheet potentially to get a mobile version of your website.

So what are some of the conclusions of this data?

The Web still has some pervasive accessibility problems. Form control labeling is still the Number 1 issue. And form control, especially in WCAG 2.0... Is anybody familiar with WCAG 2.0 here? What are some of the new form things in WCAG 2.0? Do you remember?

Audience 7: [Indiscernible]

Jon Gunderson: Well, some of the new requirements in WCAG 2.0 is that air and instruction information be accessible. So it's not just about labeling forms anymore. It's also making sure that when people have a problem, there's an invalid form field, that that information is also accessible to people with disabilities, that if you have instructions on your web page on how to fill out the form, that people can understand the relationship between that form and those particular instructions.

WCAG 2 has a number of other additional issues related to accessibility that are really important. You fill out a form field and you get to the end, you hit 'submit' and you don't go anywhere. Well, what happened? Well, if you had some kind of inline information about invalid form fields and the person goes back to the form and they don't hear any problems with that, it basically can't fill out the form.

Data tables, I think, and accessibility still seems to be an issue for a lot of people. And I'm not sure, the use of caption and summary, I think, needs further clarification in the WCAG Working Group's techniques documents.

Audience 8: [Indiscernible]

Jon Gunderson: Well, I asked about that. I asked the chair, Loretta, and she said she couldn't answer that. She wanted the group to discuss it. Because the Open Ajax rule set people, which I helped develop, we got the same question, 'Is this something that's always required?' But it's part of the success criteria, so one of the issues with the WCAG techniques document is some of the success criteria...

Audience 8: [Indiscernible]

Jon Gunderson: Well, there's nothing in the techniques document that is normative. It's all suggestions. And basically at the end of every technique it says, 'You may do this some other way that we haven't thought of.' So things like title only requires that the title element be present on a page.

But things like info and relationships, 1.3.1, with all its table stuff, it talks about caption and summary as meeting the success criteria. So is it, 'and all of these things' or is it this and this and this or is it situational? So I brought out the concept, 'Well, what if there is more than one data table on a page? Is it more important or less important?'

I think there are some issues, and that's one of the reasons I recently joined the WCAG Techniques Group is to ask these questions and to try to get clarification so that as we develop the rules, the rules reflect, again, what are the functional needs of people with disabilities and what are the needs of developers? What kind of guidance do they need to understand? And part of what we develop these tools, too, is help to guide developers in understanding accessibility.

Headings is a mixed thing in WCAG, especially WCAG 2.0. From a best practices standpoint, we thought headings were a critical part of web accessibility. But if you look at WCAG 2.0, the use of headings is what you call a Triple-A requirement that they be meaningful as a Double-A requirement. It's a little bit schizophrenic that way.

I think if you ask a lot of accessibility people, some accessibility people put a lot of emphasis on headings and others don't. Obviously, in our best practices, we did. So I think there needs to be more of clarification on how headings should be used on a page.

But I'm less concerned about headings at this point because we're moving into this Web 2.0 world and something called ARIA and ARIA landmarks, and I think that's really going to take over the function of what headings or I used to use headings for as landmarks. And we'll talk about those in a minute. And tables for layouts seem to be getting better, so...

Some of the litigation. How many people have heard of the Penn State case? OK. For those who aren't familiar with the Penn State case, last December Penn State received a letter from the Department of Justice saying that their websites were inaccessible to some of their blind students and that they were going to have to fix that. Just about a week ago, they found out there was an agreement on what they're actually going to have to fix.

Just to summarize a little bit, basically, of the 8,000 websites at Penn State University, all new websites starting this October have to comply with WCAG 2.0, and any website that's been created or modified since 2009 will have to comply by August of 2014. Library website, next October. Campus search engine, by next year. And they're going to have to junk their ANGEL LMS and have an accessible learning management system in place by August 2014.

So this is what happens when people, at least from external, don't manage the accessibility of their web resources. Not only do they have to comply, but they're given dates they have to be complied by.

I know some of the people at Penn State, and it wasn't that they were ignoring accessibility. In fact, many of them were using some of the tools we've developed there. If you ask Dan Goldstein, who filed the complaint on behalf of NFB, he said it could've happened to any institution. For whatever reason, Penn State was the one they chose. It could've happened at the University of Illinois.

It also affects purchasing. Any new purchasing has to be accessible. An important feature is auditing an annual progress report. So people have to measure, are they meeting the accessibility standards of their policy?

They have to have at least one FTE at each campus responsible for monitoring and supporting compliance to these standards. They're going to be hiring people. By next summer, they have to have, I don't know how many campuses, I think they have at least four or five different campuses.

So this is painful for Penn State. This is not a fun process for them.

Audience 9: [Indiscernible]

Jon Gunderson: I think from NFB's perspective, if you're not, you might be the next campus. Because this is setting the bar for everybody else.

So if people don't understand this or don't think that this is important, until this becomes a practice of most institutions, they're going to continue to file complaints when they find problems. Not that they like filing lawsuits. They don't.

Yes, go ahead.

Audience 10: I'm just curious, I've seen it a couple of times. When they say 'purchasing', what exactly are they?

Jon Gunderson: I think one is making sure that when people do purchase that part of any contract or purchasing RFP, accessibility is included, that when venders come in to demonstrate or try to sell you the product that they actually demonstrate the accessibility features, they just don't claim it.

Most companies will claim accessibility, but very few of them actually deliver on their promises. It's not unique for accessibility. I'm sure you've had venders who promised a lot more than what their systems actually perform. Well, they do the same thing for accessibility.

So you need to make sure if you're implementing a system that it actually has the accessibility features or that it's contractually obligated by that organization to add those accessibility features before you deploy.

We only have a few minutes left here, so...

Google Docs is another area. Both Northwestern University and New York University had complaints against them for using Google Docs. So even free stuff isn't necessarily something that people can use unless it's accessible.

I think Google is starting to get the message that if they're going to be in higher education that they're going to have to be accessible. I met with some of the Google people last week at the EDUCAUSE Conference and I think this whole education area is something new. They don't quite understand why this accessibility issue is so important. But I think they are starting to understand a little bit more about accessibility.

I'd be happy to talk to people more about, this is my perception of what Google is doing in that area. Or maybe you can ask, oh, I don't know if Chris Wilson would know.

But here's a copy of the complaint. So it's not just websites we develop but things we get.

So where do we go from here?

One, from a developer standpoint, there's some new technologies called ARIA for ARIA landmarks. I think they're going to become more important than headings, and our new tools and our new rule sets will support that.

Again, form control labeling. I see it's still a big issue. Twelve years after Section 508 and WCAG 1.0 requirements, we're still struggling to get labels on form control.

Plus all the new WCAG 2.0 things related to making sure instructions and feedback is accessible. Data tables, headings, use of images. I was talking to, I think, John here before about some of the new dynamic content: pull-down versus flyout menus, hide/show like tab panels, ARIA widgets, image rotators. These are all things that we need to have best practice accessible solutions for to help developers like you understand what you need to do to plug in accessibility.

From an administrative standpoint, again, you need to have more than just a policy. I think the Penn State case showed you need to have... These are some of the things that Dan Goldstein, he was at EDUCAUSE last year, talked about.

You need to have implementation deadlines. It can't be just, 'Well, when we get around to it, we'll actually implement the policy.'

Auditing. Annual or semiannual auditing. Where are we? Where are our problems? Where do we need to go? A little bit like the auditing I did here presented some data.

You need people responsible for implementation. You can't just have a policy and nobody enforcing it or being able to provide feedback.

And purchasing and working with purchasing and external venders, making sure the things you buy and the things you use are accessible.

This is just an example web page here. This is a new web page just for our division. It's a Drupal 7-based website. It's fully ARIA-enabled. We have ARIA landmarks on the web page.

 I'll be at the poster session area and if people are interested in what we've done to make some of the new technologies accessible and some of the design issues we had with this, it's got all these nice flyout things, I can talk about some of the accessibility issues with these things.

So an example website. You can go to the presentation if you want to take a look at that.

One of the things that I really tried to emphasize is us working together. We have something we call the Web Best Practices Working Group. And I was thinking during a presentation, 'Why isn't there a web best practices working group at HighEdWeb?' Maybe we need a special interests group here in this area to start getting the best ideas, bringing web developers with real design issues and people with disabilities and accessibility experts together to find solutions that not only work for people with disabilities but work for you developers.

This is a place you can go. If you join this group, maybe we can somehow... I'm going to talk to the people at HighEdWeb here of how we can start a group like... How many people would be interested in participating in a group like that? OK, great.

And that's part of, when we develop our tools, we need feedback from developers and input from developers on what you need to support accessibility.

The other group that I work with is the OpenAjax Alliance. This is developing that open source working group. If people are interested in working on rules, we'd love to have you as a part of that project.

I am teaching an online course starting in a few weeks, there's some flyers, handouts, on designing accessible web forms, so what are the two Web 2.0 requirements, what are the different ways with the new ARIA markup to add accessibility using things other than labels for form controls and to getting accessible feedback and instructional materials. If you're interested in that or know some people who might, I'd appreciate it if you could share that with them.

How much time do I not have left?

Moderator: You still have five minutes.

Jon Gunderson: We still have five minutes? OK. Well, I wanted to leave some time for questions at the end. Questions? Yes.

Audience 11: [Indiscernible]

Jon Gunderson: OK. So why do we have to pay attention to accessibility in higher ed anyway? What are these laws that people are going to probably sue us against?

Well, it really comes from the Rehab Act of 1973 Section 504. That was the first legislation that said that anything had to be accessible, so in higher education at least, if a university didn't want to admit a student with a disability, or if you had a disability that the university was under no obligation to provide any accommodations.

And typically, they didn't. If you were blind or hearing-impaired, you had to figure out how you were going to learn in that environment on your own.

So what does Section 504 say? It basically says, ideally, you have to provide information in an accessible preferred format ideally at the same time you provide it to anybody else.

Before the Web, you had the course catalog. What would you do? The main things universities did, they set up these specialized units for disability accommodations. Most universities have one. What they would do is whoever needed the catalog, they would get an accessible version, so they would take the catalog and either make a Braille copy or some other, I mean, these days there would be a lot of other options, but they might make a Braille copy, they might make a large print copy, they might make an electronic copy, depending on the format that was preferred by the student and depending on the capabilities needed to do that, depending on the period of time that was happening. So for print materials...

But the Web is something different. If we think about the same time and in the preferred format, let's say, I go to a website and it's not accessible, well, obviously, if I have to go to the, I mean, for one thing... Well, maybe it's better to tell a story talk than to talk about all these technical things.

A few years ago, we had a student with a disability on our campus. I was just polling students with disabilities on our campus about web accessibility, so I called up this one graduate student. She was in College of Education. I said, "Well, what about web accessibility? Do you have problems or something?" and she said, "No. Not really."

I said, "Well, what about all that time you spent on WebCT and you had to enter grades?' They were teaching them to enter grades. You had to memorize all of these key strokes, and if they made a mistake they had to start all over again. It took her three times longer than all the other TAs to enter grades.

She said, "Well, we figured that out. I can do that." I said, "Well, what if you want to know if something's going on the crane, etcetera, someplace else?" "Oh, that's easy. I just ask somebody else to find it for me." Basically accommodated herself out of using the Web.

How many of you people could do your job by asking other people to find your stuff on the Web? How many people here could do their job if they were dependent on somebody else to find stuff and to do stuff on the Web for them?

If we're not going to have an accessible Web, we're not going to have what the speaker talked about in terms of this Web where everybody learns and we'll have some people learning and some people doing all these really cool things that some people won't do. Those will be the people with disabilities.

Yes?

Audience 12: [Indiscernible]

Jon Gunderson: Yeah, and I think that's one of the hopes with the... Are we out of time or do we...? OK. Well, nobody's coming in the door yet.

One of the things is like authoring systems, I mean, what we really want is an authoring system's accessibility by default. Right now we have what I call 'accessibility by exception'. You have to know something about accessibility, you have to know what the accessibility features of the technology you're using, whether it's HTML or Flash or Silverlight or whatever, and then you have to try to get whatever authoring environment you're using to use those features. Three pretty big steps.

Well, we need our tools that basically support accessibility, especially if we're non-technical people, so it's harder for them to create inaccessible content than accessible content.

[Applause]