The audio for this podcast can be downloaded at http://2011.highedweb.org/presentations/TNT7.mp3
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. 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. [Laughter] 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.
|
|
01:15 |
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. [Laughter] 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. [Laughter] 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.
|
02:14 |
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.
|
03:09 |
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.' |
04:10 |
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. |
05:15 |
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. [Laughter] 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. [Laughter] Dylan Wilbanks:
This looks familiar, doesn't it? Dylan Wilbanks:
What about strollers? 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!' |
06:03 |
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. |
07:09 |
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." [Laughter] |
08:18 |
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? |
09:11 |
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. |
10:05 |
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. |
11:07 |
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. |
12:10 |
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. |
13:10 |
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. |
14:09 |
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. |
15:07 |
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. |
16:16 |
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. |
17:00 |
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. |
18:00 |
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. |
19:01 |
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. |
20:08 |
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. [Laughter] Michael Fienen:
It's not really OK. Don't tweet that. [Laughter] 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. |
21:02 |
Dylan Wilbanks:
Poop on Siri? [Laughter] 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. [Laughter] 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. |
22:11 |
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. |
23:10 |
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. |
24:06 |
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. |
25:13 |
Michael Fienen:
Oh, I thought it was funny. [Laughter] 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. |
26:06 |
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? |
27:11 |
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. |
28:09 |
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. |
29:04 |
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. |
30:07 |
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! |
31:05 |
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. |
32:04 |
And the best tool of all, NVDA is a free open
source...it'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. |
33:01 |
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. |
34:05 |
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. |
35:27 |
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. [Laughter] |
36:01 |
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. [Laughter] |
37:11 |
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. |
38:01 |
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.
[Laughter] 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. |
39:07 |
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. |
40:07 |
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. |
41:03 |
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. |
42:04 |
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. |
43:08 |
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. [Laughter] 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. |
44:13 |
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. |
45:08 |
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. |
46:02 |
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. [Laughter] |
47:02 |
Dylan Wilbanks:
And then I made more money than any of you all could ever
imagine. [Laughter] 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. [Applause] |
48:02 |
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. |
49:00 |
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. |
50:08 |
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. |
51:08 |
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! |