TNT7: Twin Red-Headed Stepchildren Of A Different Mother: The Usability of Accessibility

Michael Fienen 
CTO, nuCloud

Dylan Wilbanks 
Web Developer and Designer, Company To Be Named Later

The audio for this podcast can be downloaded at

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

Dylan Wilbanks: All right. I'm Dylan Wilbanks. I once upon a time was at the University of Washington, then I left.

Go ahead.

Michael Fienen: No, no, no. Go ahead. Finish. It's OK. No, finish. I'm serious.

Dylan Wilbanks: I left and got a better job. Anyway, I'm back. Don't ask me why.

This man over here is Michael Fienen.

Michael Fienen: I interrupt people a lot.

Yeah, I'm Mike Fienen. I'm from Pittsburg State University. I'm CTO at nuCloud. I'm a .cms guy. People know me by a lot of other names I cannot speak in polite company. My beard is not me. I do not speak for it. I'm just disclaiming that right now. That's all I've got to say.

Dylan Wilbanks: You know what's great is, we never really go to HighEdWeb and ever see really any accessibility talks, so we figured we'd do one this year.


Dylan Wilbanks: That worked really well, didn't it?

So if you have any questions, comments or complaints, this is our hashtag. Talks in the past that feature people yelling about how horrible my talk has been over Twitter, which led to massive explosions. That was enjoyable. It also cost me thousands of dollars in therapy.



Dylan Wilbanks: So here's how the story goes. I was at the University of Washington for 10 years. You might have heard a talk about that last year. I can't remember what it's entitled. Yeah. Anyway.

Audience 1: Ten Years in the Hole?

Dylan Wilbanks: That was Fienen's talk.


Michael Fienen: Wait a second!

Dylan Wilbanks: So after the talk, the infamous story goes that I realized how much I hated my job. So I quit and I went over to a rapidly-growing Cloud-based enterprise software company I shall not name. However, we're hiring. Do you know Java? I get 5,000 bucks if you know Java.


Dylan Wilbanks: Seriously, we've got a lot of money.

So for me, what was interesting was I found myself trading hats. I was always one of the great accessibility people at UDub and I go to a company that doesn't give a damn about accessibility. But they give a hell of a lot of damn about usability because they're having trouble selling their product. So I ended up drawing and essentially being half of the UX team.


But I realized along the way there were a lot of things that were congruent between the two of them. For instance, it's always left for later. And later never comes. People don't design or develop either in mind enough and then ignoring, either one of them comes back to bite you in the butt in the end.

So I realized that they really are the red-headed stepchildren of the Web. Usability and accessibility, the two things that we kind of lay aside, we leave to later. We kind of ignore them, and they come back later, and then we have to worry the hell about them.

And this is the point where I would then start talking about whatever, but I'm going to stop for a second. How many of you all have ever heard the accessibility talk? OK, keep your hands up for a second.


How many of you all, having heard the talk, ran back to your university organization and immediately tried to implement something relating to accessibility? How many of you all actually succeeded?

Michael Fienen: A couple of you.

Dylan Wilbanks: Yeah. OK, here's the deal. And I hate to call Kris Martin-Baker out on this one, but she's dead right. We've had this talk for 10 years now. Every damn conference I go to, we do this talk. Over and over again. And it just absolutely drives me up the wall. We never really seem to make any real difference on it.

So I really want to start straight up by dealing with one of the biggest problems I see with this whole rigmarole we do with this, and that's that usability and accessibility are not the same thing.

I think Karine Joly was going on about how, 'Oh, yeah, well, it's great because somebody's finally talking about how usability and accessibility are the same thing.' I'm like, 'I'm not. They are different.'


And I think it all traces back to one little problem. And I call it the Curse of the Vegetable Peeler.

How many of you all know what this is? What is it?

Audience 2: A vegetable peeler.

Dylan Wilbanks: The OXO vegetable peeler, that is absolutely correct! And how many of you all know the story of the OXO vegetable peeler? As featured in Helvetica.

So the story of the OXO vegetable peeler goes like this. The head of the guy who eventually would found OXO calls up his friend, an industrial designer, and says, "Hi! We're on vacation and my wife's trying to peel potatoes. She has arthritis and it hurts. Can we make something that actually works for people?" And they go, "OK, we can make something that works for people with arthritis." And they put this new tool together, and OXO goes off and sells billions of dollars in tools. The end.

Well, the issue really with it is that we get stuck on one particular version of the story, and that particular version of the story is that this device here, somehow, someway, is this magical key to the world of how we get accessibility into people's hands.


We look at this a lot. Here's an accessibility piece and here's all the wonderful ways we can make it better. I don't know, how about a curb cut?

Michael Fienen: This is where you laugh. It's OK.

Dylan Wilbanks: This is where you laugh.


Dylan Wilbanks: Boy, where did we see a curb cut today?

Let's think about some of the things you could do with a curb cut. You could ride a bike.


Dylan Wilbanks: This looks familiar, doesn't it?

Michael Fienen: It gets better.

Dylan Wilbanks: What about strollers?

Michael Fienen: No.

Dylan Wilbanks: No. Sorry, no ducks. No ducks. I didn't get the duck in there.

Now of course, at the end of it, we mention of course that, 'Hey, someone with a wheelchair could use it!'


Well, here's the issue with that. It just turns into almost like a talisman for accessibility. If only we had a curb cut, if only we had the vegetable peeler, then accessibility would finally be important to the Web and everyone would just do it, and magical unicorns would fly!

Look, here's the problem. It's what I call the 'surely this' problem. I'm from Seattle. Seattle's a little liberal. I'm a little liberal. Seattle is very liberal. And this is what I heard for eight years about this guy right here was, 'One more scandal, just one more scandal, and we get him out of office.' He was President for eight years. We never got rid of him. He stayed up there.

And the thing is, I hear the same thing from Republicans now about Obama. It's a 'surely this' problem. We may find the magical thing that may bring us once and for all the thing that delivers, the thing we really want. And that's so stupid because, let me tell you why: if you start selling accessibility as better SEO, it's not about accessibility anymore, it's about SEO. Think about it.


Let's go back to our curb cut for a second. Well, here are the two magical things you can do with a curb cut. You could have a stroller go across it or you could do a wheelchair thing. If you start selling it as being about the stroller, it no longer becomes about the wheelchair.

Let's stop doing that, please? Because I'm tired of it. I am dead tired of it. It has driven me nuts for 10 years. Let's not do this anymore.

So now let's talk about usability and accessibility. I think that there are things in usability that really can help with accessibility, and we're going to try to give you a few ways.

But I have to warn you, we're going to give you a huge fire hose. You may have heard a few of these things earlier today. You'll hear that as a recurring theme. This is what happens when you don't call your keynote person first and go, "What are you covering? We'll cover the other bases."



Dylan Wilbanks: Anyway.

And the good news is we put up a little Delicious stack of all sorts of wonderful, Delicious links you can use that you can look at. Everything we have linked in here, please take it, please use it, please run with it.

But the big thing we really want to say is I have both of them in mind. Usability and accessibility, they are different, and they have some congruencies. But do it both.

And the earlier you think about it, the less work it's going to be. Or in the words of a certain former mayor of Chicago, do it early and often. Or in his case, vote early and vote often. But do it early, do it often. Take it in.

So we're going to be going through some implementation pieces. That's going to be Mr. Fienen. I'm going to go back to verification, then he is going to do evangelization to get his eyes blown out, and then I'll come back for a little less round of ranting.

So Mr. Fienen?


Michael Fienen: Just trying to make myself blind to make this thing more realistic.

Let's talk about implementation just a little bit. And again, there is going to be a lot of links. We've got everything under the Delicious stack. We've got a number of tools that you can go use. We're not going to talk about them all, but we'll try to give you a bunch of stuff that you can go back and read and get into.

What I want to talk about implementation, though, is that there are really three things here that you can take and go and do right now, because accessibility is not easy. Accessibility is not necessarily something you just do on a whim. But what we're trying to do, and I love what Doug Tschopp always says here when he tells you that if you're new here and you come to the conference, take away one thing you can do. That's sort of what I'm trying to do here. So I'm giving you three things you can do.

This is what you can start, these are the movable objects. They may be big sometimes, but they are still movable. What these things are are your templates, your forms, and your videos. These are three low-hanging fruit-type items that you can go back and start addressing.


Let's talk about your templates. One of the most important things you can do regarding your templates has to do with your systems supporting them.

You have a CMS. Everybody has a CMS for the most part in here. According to the survey we're doing at .eduGuru, which I hope everybody goes and takes, you all have CMSs. So what you need to do is go ask your CMS vender about accessibility.

This is an important note, obviously. We need to be cognizant of what our venders are giving us and providing us, and what they are also planning in the road map. So it's important to go and say, "Hey, what can we do here?"

For instance, they always give you this argument, they don't say these words necessarily, 'garbage in, garbage out,' but that's really what they get at when they tell you, 'Yeah, we're accessible. We'll print out anything that you put into the system. If you're writing accessible code, then we can put out accessible code. That's not a problem.' But there's way more to it than that. It's way more complicated.

For instance, who here knows about ARIA? Who knows what ARIA is? A good number, about half of you maybe. ARIA is by itself a huge topic, so I'm going to cover just a few of the very top layer of this.


ARIA checks and WCAG verification and all of this are things that you can do within your CMS, and you should ask your vender, "Are you providing these tools to me?"

A good example: things like alt attributes and table summaries. If you have a CMS, who knows what TinyMCE is? Is this a tool that most people are familiar with? For those of you that are not familiar with it, it's a WYSIWYG, 'What You See Is What You Get', editor.

TinyMCE is extremely accessible. Extremely. It's Open Source. You can go in, you can poke around in it. What's great about it is you can require alt attributes be put on images before they're even put into content.

The same thing holds true for things like tables. You can put in there, 'We want summaries. Check first.' They don't have to be required, but they can be prompted before it's saved.

So you can start making your tools work for you. And you need to ask your vender about these things because they may not be telling you about it upfront.

The other end is your tools in general. If I trip tomorrow and fall on two forks and both my eyes are jabbed out, or I walk in front of this projector one more time and burn my retinas out, and I'm blind, I need to be able to use my CMS still.


And a lot of us are in states where that is a requirement. That is an extension of 508, in Kansas it's Policy 1210, that any tool we deploy on campus has got to be accessible end to end.

So start asking your venders about this. Start asking in RFPs. Start forcing them to start addressing accessibility issues because it impacts the way you use your site.

Now, as far as ARIA goes, this is that top sort of skim layer that we were talking about. Landmarks are the best places to start with ARIA because they're super simple. All it requires you to do is add a simple role attribute to your HTML.

Yes, it means your HTML is not going to validate. I don't care. If your excuse for not including ARIA landmarks and accessibility tools is because your HTML is invalidate, you aren't doing it right.

What you can do, and this will sound very familiar in a second, with landmarks, what you can do on your pages is add a role, and you can say, 'Hey, this is a navigation. This is a header. This is a search area.' And what that does for people with screen readers is it lets them semantically understand the structure of your pages.


What's great is that this future-proofs your site, because what you do is you're applying extra markup to help the people that can use it and you're also addressing the fact that ARIA's not well-supported across every single platform equally.

This sounds very familiar if you know anything about HTML5. The cool thing about HTML5 is that a lot of our HTML5 tags like section, header, footer, these things are already mapped to the ARIA landmarks in many of the current versions of screen readers.

So if you double up on these elements, you're setting yourself up to hopefully help anybody who's using your site with a screen reader. So that's a good way to get started with some of that.

Another thing: mind the CSS you are using, please. Aim for your golden ratio. That's 4.5 to 1, 4.5 to 1 between your font and your background or your images and your background. Doing 4 to 1 pretty much covers you at any font size and gets you Double-A WCAG-compliant. You can actually go up to 7 to 1 if you want to get Triple-A-compliant across the board. That's a little excessive, but still good.


We actually ran into this because our designers originally built our pages with a gray font on a white background because it was easier on the eyes. It was less eye strain. If people are getting eye strain because they're reading black text on white pages on your pages, you have way too much content on your site to being with.

So dial it back, deal with people, and get your contrast ratios right.

Next, hiding elements. How many people have skipped the content on their pages? In their header, somewhere? How many of you are using 'display: none' or 'visibility: hidden' to hide that? Or do you know?

Nobody. I'm going to assume a few of you are lying, hopefully, because otherwise this example doesn't really work.

Don't ever use 'display: none' or 'visibility: hidden' on things you don't want sighted people but accessible people to see. Here's the thing: screen readers on or Internet Explorer's or Firefox's rendering engine most of the time; if you use 'display: none' or 'visibility: hidden', you're hiding it from everybody, not just the sighted people. Screen readers will skip over that.


There's an article that is in the Delicious stack, Elisa Park, that covers this very well, and it talks about positioning stuff off the page so it remains in the flow but it's just out of sight. That's the right way to come about this.

Similarly, if you're using hover states on your CSS so that obviously you want people to be able to see when a link is active, that's fantastic. What if I'm not using the mouse? What if I can't hover your link?

A lot of people don't double up with focus. By using focus, you're also covering people who may be tabbing through a page. This gives you highlight states if you're tabbing through on links, buttons and things like that.

By doing these three things in your CSS, you've already made your page a lot more accessible to people. It's simple stuff. This is easy. This is the stuff you can take back and do now.

So let's talk about 'why'.

Just code well. Code things semantically, code things smartly, and you will avoid a lot of the traps that come with accessibility. If you're doing tabled layout, that makes your page inaccessible. It also is making a bad page in general. So focus on coding well. Code semantically. That's your first line of defense.


Your forms. Forms are ounce for ounce the single most interactive component on your website. Maybe not singularly, but together, think about how people use forms on your site: for applications, enrollment, financial aid, maybe they apply for an audition in your music department, maybe they're an international student that's looking for a ride from the airport to get to your school.

From students to faculty to staff to alumni donors, everybody's using forms on your site, so it's up to you to make sure they are accessible.

How many here like making forms, you just enjoy the heck out of it? What is wrong with you people? And Dylan as well. I don't know about the rest of you; I hate it, because it's a time suck. It's not that it's hard, it's just that it's labor-intensive.


But there's still some stuff that you need to take care of. I said that already.

In WCAG 1.0, one of the big complaints was what you could do with Javascript and what you couldn't. In the latest revision of WCAG, they really tried to address this idea of what you can do dynamically on pages and making sure screen readers are alerted and all this other great stuff.

The bottom line is you can absolutely use Javascript on your forms. And it's really, I would encourage you to do it. Just make sure to do it right. Enhance stuff, bring it up.

A lot of people resize the text on your forms maybe. Do input validation. Just make sure you're not relying on it so hard that you break your forms. If you break your forms when Javascript is turned off, you have built it wrong, period. There is no excuse you can give me that will convince me otherwise, because you should still be able to handle that form server side and spit out whatever you need to do.

There may be technological limitations that come into play there. Deal with them. Figure out a way to work around it, because that's the bottom line there. Focus on progressive enhancement and bring your stuff up.


Think about what labels do for you. Labels are great for screen readers, aren't they? It lets people know what options are in front of them and which ones to select. Relatively simple.

How about us? Smartphones? How many people have logged into a form on a smartphone before, either logging into something or signing up for something? You ever checked a checkbox or radio button on the smartphone? Yeah, you do the whole zoom dance so you can click on it, right?

By putting labels on your elements, you take the hit space on a smartphone from this to this. That's usability in action. You're helping accessibility, you're helping usability. You're making things work for everybody better.

That's why you focus on this. Make sure it's done right. Don't copy everything and then not check your IDs and not check your names and all this. Make sure it's right.

Also, back to HTML5. HTML5 has the required attribute that you can put on elements. This allows browsers to natively identify which form elements are obviously required. That's great.


Screen readers don't necessarily get that all the time. So again, ARIA comes into play. ARIA has a required attribute that you can put on set to 'true'. If I'm using a screen reader, I will actually hear that read back to me as a required field, so that that way when I'm going through there, I know what I have thought and what I don't. So it's very helpful for then.

Video. Last section in this whole thing, and then we'll go back to Dylan, who's way more interesting to listen to than me. Video is probably one of the biggest topics in terms of multimedia accessibility. Why? Captions.

OK, so here's the thing about captions. It's not all about the deaf. Captions do not just tell people who can't hear your video. This is all about SCO to start with.

YouTube is now the second-largest search engine in the world. YouTube. This is important because it means if you have captions on your videos, they index those now. That adds metadata to your content and helps people find it. Much more than an accessibility issue.

Also, international users. Again, stop me if any of this sounds familiar. International users, ESOL users on your own campus who may be local students. They don't have to be necessarily international.


There are plenty of people who are English as a Second Language. These folks may not be able to understand, for instance, how fast I am talking now, but they could follow the transcript along just fine.

And normal people, too. I regularly have people come into my office. I just don't want them to know what I'm watching because I'm not working, and that's OK.


Michael Fienen: It's not really OK. Don't tweet that.


Michael Fienen: My beard will tweet it later, don't worry.

But normal people like having captions, too. Even in my own house, I turn on captions on movies and stuff when I just want to have stuff on the TV but not the noise. So keep that in mind.

Now, I want to tell you one thing about machine transcription. People love when stuff screws up, doesn't it? I'll moderate my language here. Poop on Siri, brand new site. Everybody has maybe seen what the stupid crap that Siri does when you talk to it.

Dylan Wilbanks: Oh, but it's Shit Siri Says.

Michael Fienen: OK, sorry. Shit Siri Says. You feel better now? I'm sorry.


Dylan Wilbanks: Poop on Siri?


Michael Fienen: I'm trying to be family-friendly.

Dylan Wilbanks: Poop on Siri!

Michael Fienen: We don't know who's watching at home!

Dylan Wilbanks: Oh, I feel sorry for every girl in America named Siri.


Michael Fienen: Oh, that's mean.

You have Auto-Correct Fail, you've got a million different sites that are devoted to things that screw up, because people love seeing stuff screw up. Your machine transcriptions are a huge target for this. Mashable's got several of them, again, linked in the Delicious stack. Instead, what you need to do is get your stuff transcribed.

Quick quiz. Let's see who's paying attention. How much does it cost to get a minute of video transcribed? It's about a dollar, right? Farm it out. There's several sites, CastingWords, Automatic Sync. There's several others out there that will do your transcribing for as little as a dollar a minute. You can actually get it done much quicker if you're willing to pay a little bit more.

And here's the way you weigh it. Is a dollar a minute not worth a lawsuit? That's how you weigh that. And it doesn't even come down to what it's going to cost you to settle or what it's going to cost you in adjudgment.


When Penn State went up against the National Federation for the Blind, that wasn't necessarily about the money at the end, because there was no money at the end. All that was about was the NFB wanted to get Penn State to change their ways, and they succeeded in that.

In the meantime, Penn State decides to spend money fighting that battle. Was it worth $60 to do an hour's worth of video? I mean, really?

So keep that in mind. When you take that up and they say, 'Why do you want to spend $60 on an hour's worth of video?' that's why you want to do it. Either that or go hire students.

Dylan Wilbanks: Ask yourself what the hourly rate on a lawyer is compared to the hourly rate on getting students.

Michael Fienen: Yeah. Hire students, pull people in. There's a lot of ways you can get this done.

If you're doing any kind of real produced video, like stuff that is made by your marketing department or anything, if you're doing it relatively properly, you're already halfway there. You should have scripts already done. The only thing you have to plug in are the interviews. I give a lot of credit to our videographer on campus because he has been fantastic at this.


YouTube I come back to a lot in this area because it really is, I think, the pinnacle in terms of video and accessibility for us. YouTube compared to Vimeo, God forbid Facebook, is miles beyond them.

For instance, when we talk auto-timing versus machine transcription, auto-timing is like the steroids that you need to get your transcripts done quickly into captions. Machine transcription is going to screw you over and you're going to regret it.

If you take your transcript you have from your produced video and drop it in here and let YouTube auto-time it, you will love it forever. Because if you've ever written captions manually, it is a pain in the butt. It takes forever and you spend more time writing the time coding than the actual captions. YouTube does it for you and does it very well.

The other thing: how many billions of videos are we up to now a month that people watch on YouTube? It's crazy. People are familiar with that interface. It's something they understand. From a usability point of view, it's sort of that golden goose that we know about.


The caption tool is one of those components that people know where it is, they know how it's going to behave, they know where it's going to be on the screen. That's one reason why it's important.

Also, from keyboard end, I had just mentioned it's probably the most keyboard-accessible tool out there. And also, keep in mind all this includes lecture capture, and I hate bringing that up. We talk mainly about marketing-type video, but if you're doing lecture capture, anything your school's putting out technically falls under the exact same rules, and it's something to keep in mind.

Now I'm going to stop for a second. I'm going to let Dylan take over here on verification because I need to sit down.

Dylan Wilbanks: You need to sit down. I'll start ranting again.

Verification. Let's be simple here. It's just about testing. Testing, testing, testing, and that means not only quantitative testing but qualitative testing.

Shawn earlier today said ABT, Always Be Testing, and I totally believe that. I was going to put an Alec Baldwin up behind this, but I couldn't find one of a decent size that would fit. Accessibility is for closers.


Michael Fienen: Oh, I thought it was funny.


Dylan Wilbanks: Well, what speaks well of me, speaks well of you.

Don't be afraid to iterate. Seriously. There's nothing wrong with moving forward piece by piece, slowly as possible. I mean, as fast as you possibly can. There's no problem with iteration. Because the thing I kept hearing over and over from people is, 'Oh my God, the whole damn site is just incredibly inaccessible. We can't do it.'

You know what I say to that? Everest isn't a day hike. If it is this huge challenge, take it piece by piece. You can't climb a hill the size of a huge mountain like this and think you're going to be down by dinner. Unless you're crazy.


What you need to focus on is find the things that you can address now, take care of them, and keep moving forward.

There is no big solid 'Oh my God, everything is over and we're done, the end, we've won' sort of thing. It's all process, because you will still find issues years after you think you've made it accessible.

In terms of tools, in terms of quantitative testing, we threw a bunch of them in there. You probably could name half a dozen of them off if you already know what they are. But here's the big deal: not everything can be done quantitatively.

Cynthia says sometimes, how many times do you see NA? I mean, even if WCAG 2 where you have so much that is now down to quantity, 4.5 to 1, that's huge. WCAG 1 is like, yeah, it just needs to be like that, some sort of a vague Cloud thing.

4.5 to 1 is really easy. It's really simple. But there's a lot of stuff that you're going to look at the content and actually ask those questions. Is this really accessible to somebody who fits our mode of people with fixed sensibilities?


So here's a question to you: how many of you all actually have an accessible technology lab on campus? All right. And now how many of you all think you have an accessible technology lab on campus but just now thought, 'Well, there might actually be an accessible technology lab on campus'? Yeah. See?

All right, here's my suggestion to you: go find it. Introduce yourselves, make friends in the facility, make friends with the users. Bring them cookies, maybe gluten-free. You never know. Because, trust me, if you can get an interaction with them and maybe say, 'Hey, would you be willing to sit down and test with us?' it's huge.

And then you'll listen to them and they will tell you what's going wrong. And if you listen to them, they will talk to you. And if they talk to you and you listen, you will make changes, positive changes, and they will see those changes, and you will build the political capital in that group to help you not look like the enemy anymore.


I know a lot of people out there who feel like they're totally at loggerheads with the entire accessibility, people who have disabilities. It's a simple case of listening.

This came by on Twitter about a month ago, and it just dawned on me that he's absolutely right. All good accessibility testing if it's one-on-one is it's simply doing usability testing with people who have disabilities.

So my suggestion is go grab this book. Who all has Steve Krug's "Rocket Surgery Made Easy"? Yeah, it's a great book. Because here's what's great about the book: it has probably the simplest usability testing methodology imaginable. It's not like coach, it's not whatever, but it does give you the ability to just simply do a monthly continuous improvement process for that.


And it's really easy to drop into an accessibility model. It just requires you to bring in people who have disabilities who can use the tools and show you what went wrong, and you video it.

And trust me about this one, there is nothing more powerful than watching something you made fail, especially if you do it in front of CEOs and deans and everybody else. Because you hear the stories. CEO comes in, just goes, 'What are you all doing about usability testing?' And then five minutes later, 'Marlene, cancel all my appointments for the rest of the day. This whole site's broken.' And then he starts banging his head against the desk. Well, OK, maybe it doesn't really happen. But we all think it does, right?

I'm going to throw this up here. This is a really rough set of things I used to use at the U. Don't trust them as the greatest tests in the world. I'm afraid that Shawn's going to beat me to a pulp when I walk out of this room. And Christopher may join in, I don't know. But let's go with this.


And look, it's impossible to read because it got so damn small.

So here is something really interesting I discovered about colorblindness. How many of you all have Photoshop CS5? Yeah. Do you know what you can do in CS5? You can change the environment.

If you look at the environment, there's one that says 'Protanope' and there's one that says 'Deuteranope'. And you know what both of those do? They let you change the color palette for a particular image you're looking at to look as if it's someone with red-green or yellow-blue colorblindness. It's dead easy.

Totally discovered it on accident. I nearly tweeted Matt May like, 'Did you know about this?' Yeah, they only showed it to me when they were just demoing it one day. I didn't even see it coming. But it's there. It's totally awesome.

If you don't have that, there's tons of color tests. Or here's an even really cool idea. All right, we'll try this right now. How many of you men in this room have colorblindness? A-hah!


Every one of you, if you look around, one in 10 to one in 15 of the men in the area you work in, right now, have color blindness. Solved. Ask them what it looks like. Ask them if they can do it without the colors.

Second one, and of course, this is the old-fashioned 'rip out your mouse, try to navigate with the keyboard, fail miserably.' It's old, it's simple, it's not the best test in the world, but it works.

And the last one. The nice thing about voice browsers nowadays is there are a lot of different ways you can do this. Henny Swan actually just put up, Henny Swan's been just going gangbusters on mobile and accessibility lately, but one of the things she's done is a simple test to basically see what a screen reader is going to do to your content. Better than that, you've got Firefox. Fangs still works all right if in terms of seeing how JAWS works.


And the best tool of all, NVDA is a free open's not a voice browser, I'm sorry. It's a screen reader. Totally my fault. For Windows. You can install it and run it. And those of you all who have Mac, you've got VoiceOver in OS X. All you have to do is turn it on and you see what most people with disabilities on a basic level can see the Web like.

And now we're running as fast as we can because we have 10 minutes left.

Michael Fienen: I will speed through this. I know we lost some time.

OK. So of course one of the big challenges we have, you people know the technical stuff, right? I hope. If not, you are aware of the technical stuff, because I just talked about it. So take your notes better.

Here's the thing: the challenge is not the 'how'. We know this. As Dylan pointed out, we've been talking about this forever. This is not new. The only thing that changes is the technology.

The real challenge with us is getting the buy-in. So I'm going to talk to you a little bit about how to evangelize this on campus in a way that hopefully will get you a little bit of social capital.


Think of yourself as the minister. You are the minister. Your people who work underneath you to build your site are your congregation, and the people above you, your vice-presidents and such, are your deacons and cardinals. And I'm not Catholic, so I probably screwed that up.

But think of yourself in that kind of position. Your secretaries, your faculty, all these people are the ones that you need to get buy-in from. So you can go down. You got up, you got down. Down is where you're talking to these people that are not necessarily technical.

So the key is that I can tell you a lot about this, I can tell you what has worked for me. But ultimately, we've all got different organizational structures, and that's the biggest challenge going down the ladder instead of up. And that makes it also the hardest possible way you can do this.

But I will try to give you a few little elements. First off, keep in mind that people who have very limited technical experience will be very hard to work with in this capacity. They see it as just extra work and extra stuff they don't understand and they think you're throwing stuff at them just to frazzle them. That's the first thing that you have to be aware of.


To combat that, first off, know their limitations. Take time to talk to your folks and just figure out what they can and can't do. Pick out the people who are the strongest in different areas. You'll have probably two or three that are more capable than others.

Then break yourself down into chunks that they can address. Don't come at them with all the video and all the image stuff and all the table stuff all at once. Come at it in little chunks that they can digest.

The other problem is that these people who are limited in their technical experience, that doesn't mean they don't understand. They still get that accessibility is important; that doesn't help them employ the techniques. I can tell you why the fuel-to-air mixture in your car is important and why it makes it go; you're still not a mechanic and you still can't fix your engine when it breaks down. That's the other challenge.

So instead, make it part of the process. Work the secretaries before. Has anybody ever done this? You trained your secretary, used the CMS to put in pictures and all this? So you'll be familiar with this process of, 'Wait, wait, wait, slow down.' They grab the steno pad, they grab the pen, 'OK,' they draw the bullet point, and they start writing down word for word everything you say. 'Click the button in the upper left corner that says File, then go down to Save.' They do that. It's a great opportunity to make this part of the process.


Don't treat alt attributes like it's some extra accessibility thing. Just tell them to do it. And they will mimic you from that point forward because they're too afraid to work outside of that. 'He showed me what was right, so I'm going to do it.' It's a great way to work within those limitations.

And ultimately, be prepared to just do it for them. And I know that it sounds like me saying, 'Be prepared to do more work.' It's not. Because you're going to do the work anyway. I mean, let's face it. Realistically, they're going to call you in six months and you're going to look at their pages, and you are going to headdesk harder than you have ever headdesked in the world.



Michael Fienen: It's true.

So take it as an opportunity to just be like, 'You know what, email me what you need. Let me just do it.' Two minutes, you're done, and you don't have to worry about it again.

Up is what's much easier. Up is simple because the people above you are much more scared of the liabilities created by accessibility stuff.

We're going to break this down into four quick gambits here.

The legal is the worst. I hate the legal option, because legal is just a threat, and people don't ever respond well to threats. That's never a good way to do it because it's not proactive. The Penn State deal is a good example of them getting threatened into doing something that worked, but it really just ground the wheels and created a lot of friction in the industry.

So don't approach it that way. Instead, think of it this way: be proactive instead of reactive. It's like building codes. If I go and build a house, I don't get my permits, I finish everything up, I invite all the inspectors in after the fact, they tell me my HVAC's in the wrong place, my plumbing's going to cause mold, my electrical's going to burn my dog house down, which is not necessarily a bad thing. You've got to see my dog. My wife's dog, I'm sorry.



Michael Fienen: You do it from the ground up. You bake all this stuff in from the start. You start working on making sure you've got the right stuff in your templates, that you're doing your video planning right and everything, so that when the inspectors come, and by God they will come, everything is right from the start.

Kansas is already in the process of working on monitoring all state agencies for accessibility compliance. Everything. Now I tell them they are crazy about trying to do that, but they are trying. But it is something you have to be cognizant of.

PR is actually pretty easy. Who's in marketing, communication, PR, web office, that area? You guys are actually in a really good position, because PR loves anything that makes you guys look good. So if you can say you're the first something, if you can say you're the best at something or the leader in something, that's a great opportunity to get buy-in from these folks to back you on anything you want to do in accessibility.


The other one is enrollment. If you can take some simple forms ahead of time and make them all accessible, mark them up good and show them how you've changed the conversion rate on your forms, and have we address some of the stuff on our request information forms in our application, we can improve things for everybody.

They get buy-in, you get money, because these are the people who hold the purse strings to your enrollment process and they can help you out.

IT is actually really easy. IT, just approach it like it's a deliverable. Give them very specific instructions as to what you expect to get out of whatever it is you're giving them to build. That makes this much more simple than a lot of places.

Also, make sure you talk to the right people. Don't take UI requests to the programmers. They aren't people people.


Michael Fienen: They aren't meant to take the specifications from the collar and take it to the other people.

Yeah, go ahead.

Audience 3: Programmers are also very UI people.

Michael Fienen: Then you are in a whole heck of a lot of trouble, honey. No, I say that jokingly. I do know programmers who are fantastic UI people, too. That entirely depends on whether or not you trust them. That's where that comes down to.


We actually had that situation where we do have programmers doing UI at our university. Our new CIO came in last year and actually made them go through accessibility training, which was very cool actually on her part.

But I'm going to speed it up here a little bit so we can get to our closing stuff.

In general, make it about the people. That's what we're really getting at here. Because it's the people who are going to be able to help you change things.

Frame this as being about user experience. I just said that because I'm trying to go faster now.

Ultimately, you're trying to give people a voice and give the disabled folks a voice on campus. This is why we bring up the thing about getting to your usability lab and working with those people, because when you sit them down and you get an administrator listen to them, or you get whoever is holding your purse strings to listen to the problems they're having, that's where the power comes from.

So it's so important to make sure you've got 7,000, 10,000, 30,000 people on some of your campuses. All of them can help you with this. And you should be talking to them. You should be getting out of your office and working with them and giving these folks a voice.


So let's take it away, Dylan.

Dylan Wilbanks: I have 52 seconds to do the altar call, great.

A big takeaway: early and often. Make an accessibility early. Grill your CMS venders early. Put it in the RFP. Trust me. Test and assess early and often. And this is the same sort of thing we do in usability. You try to attack the design issues in the design process, not in the implementation.

Push the case for accessibility on campus early and often. And that means winning whatever affinity you can, anything from a secretary of an 'HTML for Dummies' book all the way up to a president or a chancellor who has whatever frustrations. Do what you can, but do it early and do it often. And listen to people with disabilities.


Early and often. I can't emphasize this one more.

And the thing is, accessibility isn't easy. I think one of the problems we've seen is we've been sold the sort of bum bill of goods. 'Oh, you just put an alt attribute and that solves everything.'

I'm reminded of Matt May earlier this year put out this blog post talking about the accessibility mess, and there was a quote in there talking about this problem of people saying it was easy. And he ends up saying, "Quite often, accessibility work is time-consuming, expensive, and very technical, especially to someone who doesn't know all they need to know about it or someone who went too far down the wrong path before accessibility was called to his or her attention."

And then you call Shawn. She calls everyone else who can consult and come in and save these poor people.


This isn't a problem if you get help, and this isn't a problem if you attack it early and often, because you're going to get out ahead. You're going to find them, you're going to figure out how to solve the issues, and your site's going to be that much better. Just like accessibility. Just like usability.

Boy, we came back full circle, didn't we finally?

Stay simple, and don't be afraid to iterate. You won't get it right. Remember, the thing that got Penn State off the hook with the NFB was not that they solved all the problems, it was they had a plan. And they said, 'We will do these things and we will move in order and we will make it better.' Do that.

Start early. Work often. You're going to get it wrong repeatedly. Trust me, I did, and I'm supposed to be an accessibility person. Just keep going.


And it's ultimately about people. Listen. I can't say 'listen' enough. Listen to people who have disabilities on your campus.

And now, just one more little thing and we'll get through this, and please don't start eating each other because I know you really are hungry. 


Michael Fienen: It's the microphone's fault.

Dylan Wilbanks: Yeah, I'm sorry. Eat the microphone people, not me.

Let's talk about this guy again. Let's talk about me talking about how it's not usability, it was accessibility. There's another way you can look at it. I mean, it's a really good peeler. Trust me, I hate peeling vegetables, and I love this thing. I can pound through a ton of potatoes in no time. I hated old peelers, but this is like amazing stuff.

But here's the great thing about it: it's got a grip that's perfect for people with arthritis, because it's something called universal design.


And it's this idea that we're building objects, sites, tools with everybody in mind, that's it a tool that people can use regardless of their level of ability.

And what happens in universal design? You bring usability and accessibility together into a single piece. They are loved as stepchildren in this single unit.

I'm reminded of, this is one of Wendy Chisholm's slides I shamelessly stole from her, because I love Wendy and she wouldn't kill me if I stole it from her, but this is totally true. It's the stairs that make a building accessible, not the wheelchair.


You need to build things that keep everyone in mind and not think a bit about trying to put pieces on to open access when you can just build it right the first time.

For instance, we have this little park in Seattle. It's called the Olympic Sculpture Park. It's down by the waterfront. The art museum has put all these statues out here. It's an open area, it's outdoors, it's a really nice place to go on one of our two or three sunny days we get every decade, and it gives people the ability to interact with art and see art and have a little lunch and play with the kids and do whatever else.

But here's the central piece of the park: there's a path that goes from the bottom to the top, and it's a ramp in the shape of a Z.


And this ramp is open and available for anybody. It is built with universal access in mind. Regardless of whether you are in wheels or whether you are walking, you can get to the top.

This park was built for every Seattlite to enjoy. The signs have Braille now. It didn't originally, but that's a different story. Mobility is here for everybody. This is for every Seattlite.

If in the built space already now we can build things that are universally designed for all people, why can't we do that in the Web? Because in the end, we want one Web for everyone.

And you guys are smart. You guys are some of the best damn Web people on the planet. And I can tell you that because I was once one of you.



Dylan Wilbanks: And then I made more money than any of you all could ever imagine.


Dylan Wilbanks: But you can solve this. You can totally solve this, because the purpose of education is to uplift every single person and to give them the knowledge and this ability to get better jobs, to solve the problems of our world. And the ability of the Web is to level the mountains that have stood between people who haven't been able to access this stuff before.

It's everything that Shawn talked about. Suddenly we have the ability. It no longer matters what your disability is, because we all have the same abilities on the Web. That's what matters.

You guys can do it. I trust you, and I know you can. So please, do it.

Thank you.



Moderator: Dylan and Michael. Questions?

Michael Fienen: I just found three copies of "Universal Design" up here for people who are here for the first time.

Dylan Wilbanks: Please come forward.

Michael Fienen: You come forward and I may give you one. Just saying.

Dylan Wilbanks: Just as I have.

Michael Fienen: Yes, sir.

Audience 4: Well, now that you mentioned that they didn't have Braille in the beginning and try to make it even though they tried to do it all right, they didn't do it all right and add that later.

Dylan Wilbanks: Yeah, exactly.

Michael Fienen: Enjoy.

Dylan Wilbanks: Well, you can come see us or just run away.

Michael Fienen: We're here all week!

Audience 5: Thank you for coming.

Michael Fienen: Thank you. It's always fun.

Audience 5: I appreciate that.

Michael Fienen: No, absolutely. Absolutely. Anytime.

Audience 6: We follow you on Twitter, so it's nice to see your face.

Michael Fienen: Great! I'm glad. I'm glad you get something out of it. I'm impressed people stayed. We ran a little long.

Audience 5: Actually it's good information. It's what we're here for.


Michael Fienen: Great.

Audience 7: Few questions.

Michael Fienen: Yeah, go for it.

Audience 7: On the 4.5 to 1, this came up actually, we've got a new web designer in Southern Mississippi just the other day. What about font drop shadows? She was asking about that as trying to account for sort of that contrast.

Michael Fienen: Yeah. Right now, WCAG doesn't account for drop shadow as far as I know. They're talking about just the base font color versus background color, or whatever, foreground versus background.

Audience 7: Is there a good way to test an actual photographic or something as opposed to the text?

Michael Fienen: Yeah. There are some tools that you can, and they're in the Delicious stack actually, that you can upload images to, and they will process them for you. That's one test.

Audience 7: By taking some of those things like font?

Michael Fienen: It tries. Like I say, it's not perfect. Accessibility in a lot of ways is a lot of art more than science in some places, so there is no perfect, there is no 'This is right and this is wrong' in some of the areas. It's 'Can you justify it?' and 'Are you trying to make it better?'

The drop shadow thing I wouldn't worry too much about if your base font is a good contrast with the background. You're probably going to be plenty OK.


But the challenge is when you do a drop shadow, you're going to know how you're doing it. If that shadow is dark, you are hurting the contrast and making it hard to see.

So like I say, there is no right answer to that. Unfortunately, that's the case a lot of times.

Audience 7: Sure. The one thing that occurred to me during Shawn's talk is if we're doing all of those stuff like mobile apps. What about app accessibilities? Are we talking about this?

Michael Fienen: Oh, yeah. There's whole groups for it.

Audience 7: OK.

Michael Fienen: And in fact, I've actually had the pleasure of working with a blind person who uses an iPhone, because Apple specifically, and Android is I think getting better, I don't think they are totally there, but your iPhone can read to you. You can do text-to-speech on it and it can tell you where to hit on the screen. It's actually really cool. If you could find somebody who's blind with an iPhone, it's really cool to watch.

But it's a lot of these exact same issues, though. Now that's definitely more about blind than, say, motor control disabilities or things like that. That's kind of another world in that case.


And that's something I didn't do a real great job driving home, but it's not all about blind. There is so much more to it than that. But blind tends to be the one we focus on a lot.

But, yeah, you can do mobile. You can do accessible mobile. It's just about, again, laying things out well, marking it up well, focusing on your contrast. It's like any other app then, really.

Audience 7: OK. Sounds good. Thanks.

Michael Fienen: Great. I'm here all week. What?

Dylan Wilbanks: Your mic.

Michael Fienen: Oh, is it? Yay!