ADRIAN ROSELLI: Hi.
I'm Adrian Roselli.
You might have seen pictures
of me around the office.
I'm sorry.
I'm here to talk
about accessibility,
but I have two slides
dedicated to my ego.
One of them says, look,
I've written some stuff.
Good for me.
Another one says that I work
with the HTML Working Group
from the W3C.
I'm on the Accessibility
Task Force.
I've been building
for the web since '94,
so almost since the
start of the web.
I have a software development
company, Algonquin, which
I co-founded 18 years ago.
I have a website, which
is crazy nowadays, right?
I have a website at
AdrianRoselli.com,
and you can avoid-slash-follow
me on Twitter @aardrian.
I think that's how
it's pronounced.
You shouldn't have to say
your Twitter handle out loud.
I know.
So to dive right in, if you have
been on the internet, if you
have been using Twitter,
mailing lists, et cetera,
you might have seen a11y.
a11y is a numeronym, and
it means accessibility.
Essentially all it does it
takes the A first letter, the Y
last letter, replaces
all the letters
in between with a
number representing
the number of characters
that have been excised.
So localization is l10n.
Internationalization is i18n.
This is really
popular on Twitter
because it's working in your
favor for character limits.
It's also a great way with
the hashtag, the a11y hashtag,
to see what people
are talking about that
is accessibility-related.
I often talk about how
accessibility gets no respect.
We'll be talking about
it in the software world,
but I'd like to point out
here in the day-to-day world.
So we've been
redoing our office.
That's not the furniture
we have right now,
but the furniture we have now
blocked too many of the colors.
So we have these three colors
that we've been very fond of,
this gray, this
green, and this blue.
The green is called Lime Ricky.
The blue is called Online,
because that's a cool name.
And the gray of the ceiling
is called Cyberspace.
So Sherwin Williams
seemed to think
that these were a great set of
names for colors, so much so
that when it came time to choose
what they were going to name
the color of putty-- it's
like the '80s IBM desktop
computers-- Accessible Beige.
So the concept of
accessibility getting
respect outside of
the software world,
yeah, it carries through
to paint colors as well.
So sort of keep that
in the back your head.
You might sort of run across
this trend in the real world
in other places as well.
We are going to go
over some statistics.
I'm going to pitch to you
the idea of being selfish.
I'll go through some
techniques, basic tests
that you can run yourself.
For those who are
technical, I'll
even talk a little bit about
ARIA and HTML best practices.
If you're not technical,
we can breeze through that.
I am available for questions,
here and on the internet.
And then I'll have
some links at the end.
So to dive right
into the statistics,
not always super
exciting, but it's
good to know what these
numbers look like.
In the United States in
the 21 to 64 age bracket,
we're looking at
a population of 10
and 1/2 percent that have
some form of a disability.
As you hit the 65 to
74-year-old age group,
you're talking about a
quarter of the population.
When you get above 75, that's
half of the US population
has some form of disability.
These do include
visual disabilities,
visual impairments, hearing
impairments, mobility,
cognitive, and then the various
flavors of those as well.
For vision impairments,
Americans from just under 2%
in the 21-64 age bracket up
to about 10% of the population
when you get 75 and up.
Worldwide, we're talking
about 285 million people.
39 million of those are blind.
For hearing loss, in the 45
to 64-year-old age group,
almost 20% of the population
has some hearing loss.
When you get above 75 years old,
you're looking at about half
of the population, half
of the US population.
Worldwide, 360 million people
have disabling hearing loss.
I gave a talk at Accessibility
Camp New York City
a couple weeks ago,
or a few weeks ago,
and there was a woman who said
my statistics are out of date.
I haven't been able to
validate the new numbers.
But she says that it's 360
million people worldwide.
It's closer to about
500 million people.
So these numbers might
even be an underestimation.
Mobility impairments-- 21
to 64-year-old age group
is almost 6%.
75 and up age group, a
third of the population
has some form of
mobility impairment.
Cognitive impairments,
which can include things
like dyslexia,
dyscalculia, which
is sort of the numbers version
of dyslexia, memory issues,
ADD, ADHD, et cetera,
there's a pretty broad range.
You're looking at 4.3% in
the younger age bracket,
up to 14+% in the
75-and-up age bracket.
There's a trend
with these numbers
that I think you've
probably seen,
is that that number tends to
increase as the age increases.
So I've given you
the statistics,
and statistics really
don't sell people
on why they need to
support accessibility.
Raw numbers are
just raw numbers.
They don't always
get the point across.
So I'm going to preach to
you on how to be selfish
and how this can be good.
Web Accessibility In Mind
has this wonderful hierarchy
for motivating accessibility
change within an organization.
At the bottom of
their pyramid, they
have guilt. You can guilt
people to support accessibility.
Then you can start
to punish them.
You can make it a requirement.
You can work to reward
them, enlighten them,
and ultimately, you
want to inspire them.
You want people to feel inspired
so that they'll support users
with disabilities.
I think this is a great model.
I think it falls short.
I think that we can modify this.
And the star on top of this
thing is to make it about me.
If you start to look at
it as how it affects you,
you might start to accidentally
support some disabilities.
So getting older-- as I was
doing the opening numbers,
you saw the numbers
of people who
are affected with
different disabilities
tends to decline as people age.
Getting older does
affect nearly everybody.
There are some people who
might be fortunate enough not
to get older.
Unless you're Superman, that
probably doesn't bode well.
It means you're dead.
It does, as I say, carry
risks and side effects,
definitely not for the young.
In this image, there are two
couples sitting on the curb.
They're basically
doing the same thing.
They might be debating
where to go for dinner.
They might be looking at
what they want to do next.
The only thing that's separating
them, besides about four feet,
is probably 40 years in age.
They're really the
same set of people,
same objectives, same goals.
Here we have two
women on a bench.
They are both reading.
They're separated by
about a foot and probably
another 40 years.
Also, one of them is our reading
off of a solar-powered device.
The other one is not.
That's hilarious.
Are people laughing
on the hangout?
No?
OK.
[SIGHS] Tough internet crowd.
Accidents-- accidents
are a thing that happen.
All of these listed
here are just
examples of what's
happened to me--
broken limbs, eye
injuries, hearing injuries,
head trauma-- big
fan of head trauma.
An example of somebody who
has their wrist in a cast.
When you don't have
access to that wrist,
it makes it a little bit hard
to type or use your mouse
or do other
day-to-day activities.
This can happen to anybody.
You can have an
eye injury, which
means now you're limited in
peripheral vision and binocular
vision.
Some people might do it
strictly for fashion.
That's a personal choice.
That is not me,
despite the hair.
Some people are sort of
predisposed to circumstances.
This is a scenario in
England where people chase
a wheel of cheese down a hill.
They're chasing a wheel
of cheese down a hill.
At the bottom of
the hill, they have
ambulances waiting
to take people away
who've been injured.
This is a thing they do.
Assuming they don't have a
disability when they start,
a lot of them do
when they finish.
Now, you could believe
that you're like me.
You're invincible and
allergic to nothing.
But there are other things
that are factors here.
Lots of people
like to multitask.
People like to work in
the sun, eat at your desk.
Sometimes you don't
have headphones handy,
unless you're at
the airport and they
have that vending
machine where they
charge $20 for the headphones.
And then what are you
going to do with them?
They don't work half the time.
I guess that was
just me this morning.
Also, content isn't always
in your native language.
So here is somebody trying
to work while eating lunch.
This describes my day-to-day
activity pretty much.
Eating at the keyboard
leaves me with one hand free.
Become very comfortable
using a keyboard instead
of a mouse in that scenario.
Somebody working in the sun--
I had to have a cat image,
so I put it in there.
So if you've worked
in the sun, you've
tried to use your
mobile phone in the sun,
you probably recognize you
can't see the screen very well.
You need to turn up the contrast
and/or turn up the brightness.
These guys are
among my favorites
because they are working in
the sun, they are distracted,
they are computing
with one hand.
Frankly, I'm not even
convinced that they're working.
I think it is quite
likely that they are just
taking a very long lunch
and calling it a work day.
I want to be those guys.
This guy, though,
is my favorite.
Here's somebody who's working
in a park on the bench, who
has affixed papers to
himself to block the sun.
And the best part is, if
you look really closely
on his lap, that's a typewriter.
That guy is awesome.
Maybe Williamsburg
this was taken.
I don't know.
Somebody working in a cafe--
he's got a video camera
on the counter next to him.
He's got his
headphones plugged in.
Probably he is doing
some video work.
And if so, if he's
in a cafe, he's
not going to be able to hear
the audio from his video,
and he needs to plug
in his headphones
in order to do the work
that he's trying to do.
Somebody in bed with his
significant other, or pet,
matter of perspective.
If like me, you've tried
to do any computing in bed,
you don't want to wake
up the person who's
with you, because that
doesn't always go well.
And certainly the ability to
use headphones and control
brightness is very
important in that scenario.
This image is analogous
to where I live.
I don't live in
these apartments.
I live in a house, but on
either side of my house
is a motorcycle.
And one side is a
guy with a Harley,
and the other side is
a guy with a Honda,
and they like to see who can
out-motorcycle each other.
They like to rev their
engines, and their engines
are always revving right during
a critical moment in whatever
show I'm watching or
conversation or whatever.
So sometimes the
environmental factors
are outside your control,
even when you're at home.
This young woman is
in another country,
doesn't speak the language.
She's trying to find information
about how to get home.
The keyboard is probably not
in her native language, either,
which means the
keys are different.
The screen is different.
She's just not used to this.
She's a completely
competent computer user,
but when you're
in a foreign land,
things just aren't
quite so easy to use.
Tech support is another
factor to consider.
If like me, every time you
go to your parents' house
for Thanksgiving, the
first thing you have to do
is get the printer working
again, fix the browser,
uninstall some malware,
and all those other things,
that's a lot of time that
you spend on your holiday
when you could be eating
turkey and pie that you are
busy trying to help
get your parents up
and running again so that
they don't have to call you
during the week in
the office to ask you
what that big purple box is
in the corner of your browser
that's blocking 800 trackers.
So the general message here is
that supporting accessibility
now, today, is going
to help future you.
Because you're all
going to get older.
You're all going to get older.
Am I breaking the
fourth wall there?
OK.
Nobody's laughing.
Laugh.
So it's going to help
serve future you.
Supporting accessibility
now also helps
the injured version of you and
the encumbered version of you.
You don't have to be broken.
You could just be working
in the sun or on the train
or on a staircase.
I don't know why you would be.
If you get younger developers
to buy into this now,
it's helping future you.
Get that next generation
of developers to say,
yup, we see what
you're talking about.
Let's make that happen.
And as you age, and
ostensibly as you move away
from doing day-to-day
development
or being able to be involved in
software the same way you maybe
are now, you'll have a
whole generation behind you
who can make sure that you can
still do the things you do.
So accessibility is often
regarded as a checklist.
There are the Web Content
Accessibility Guidelines.
There are internal checklists.
There are different standards
that talk about the things that
you should or shouldn't.
Do but accessibility
is not a checklist.
It's a good place
to start, but it
doesn't get you to the finish.
This example I think is a
beautiful example of somebody
who has satisfied all
the checks on a list.
They had a set of stairs.
They needed to have a ramp.
They probably had limited space.
They still needed
to have hand rails.
They satisfied everything
on the checklist.
The problem with
these stairs, though,
is if you aren't using a
wheelchair, step, step, trip,
stumble, stumble, step, step,
step, step, trip, stumble,
stumble, step, step.
If you're using these
stairs just as stairs,
that ramp cuts through
at an awkward angle,
and people are always
tripping on them, OK?
If you're using these
stairs in a wheelchair,
the angles are all wrong.
Not only do you have to
make a really tight turn
at each platform, but
the slope is too great.
The average wheelchair user
can't navigate that easily.
So those turns that you see,
each little platform, ends
in a stone wall, except
for the last one, where
it ends in a hilarious
staircase fall in case
you get going too fast.
That's unusable.
It's actually dangerous for
somebody in a wheelchair.
And it's moderately
dangerous for somebody
who's not in a wheelchair.
But they satisfied a checklist.
So good for them.
They did that.
Accessibility is
an ongoing process.
You can't just do the
checklist and call it done.
You need to pay attention
that things change.
Situations change.
Technologies change.
Assistive technology changes.
This is a drugstore that did
a great job putting a ramp in.
But what they failed to
do is clear the snow off.
And when they did
that, then they
put potted plants on the ramp.
So yeah, we put the ramp up
there, and we did it right,
and the angles are right
and everything's perfect.
But now that winter
has come, we've
made it completely unusable--
completely unusable.
So this is an ongoing process.
This is something that you have
to constantly stay on top of.
So I'm going to talk
about some techniques.
Some of you might have
worked with user stories.
Has anybody in the room worked
with user stories before?
OK, good.
I'll spend a little bit of
time on this, not too much.
If you're unfamiliar with
them, the idea of a user story
is you talk about a user, the
outcome that that user wants,
and the value of that outcome.
When you're writing
them out, As user,
I want outcome so that value.
There are some variations
on how you write that.
So I have some
selfish user stories.
As a user, I was
on a sunlit patio.
I want to be able to read the
content and see the controls.
Maybe I'm looking something up.
Maybe I'm actually doing my job.
If the sun's shining, I still
want to be able to do my job.
As a user in bed with
a sleeping spouse,
I want to watch a training
video in silence so that I
can get caught up at work.
I'm sure many of us have spent
some time trying to get caught
up at work on our own time.
And in bed is kind of
a nice way to do it.
That way if you fall asleep,
you're already there.
It's easy, other than
drooling on the keyboard.
In order to click links, as a
user was no elbow room in coach
class with the tiny
track pad, I want
click areas to be large
enough and adequately spaced.
I'm sure all of you
have been on a flight.
I'm sure some of you
have tried to use
your computer on a flight.
And you know your
elbows have to stick
to your pelvis to do anything.
And suddenly you have
a mobility impairment.
It becomes very difficult
to mouse around on a page.
As a user distracted
by the TV, I
want clear headings and labels
so that I don't lose my place.
I like to watch television
while I'm filling out tax forms.
Call me crazy.
And I want to know
what my progress is.
I want to know what
those fields are.
Sometimes when it's
a placeholder instead
of a label on the field,
once I type in there
I have no idea what
I just entered,
and I have to go back and
delete and start over.
So I've broken them down
for some different types
of disabilities for
physical impairments.
As a keyboard-only
user, I want to be
able to use the
entire application.
I want to navigate a product
list with the Tab key
so I can find the right option.
In order to click links as
a limited-mobility user,
I want click areas to be large
enough and adequately spaced.
Because when you hit the wrong
one and you have to go back,
that's time.
That's time and frustration.
Visual impairment--
as a color blind user,
I want to be able to see the
links in the page content.
As a low vision user,
I want to zoom the page
so that I can read the content.
In order to use the
site as a blind user,
I want to use a screen
reader to navigate.
That's a form of
assistive technology.
Hearing impairment--
as a low hearing user,
I want to be able to
access transcripts.
I want access to
closed captions so
that I can use training videos
or just watch the Star Wars
trailer.
It's a timely reference.
OK.
It's timely.
In order to participate in
a webinar as a deaf user,
I wanted real-time
captioning or transcripts.
This is really key
at conferences,
and some of the better
conferences are doing that.
While the speaker is
up there, somebody
is live transcribing
it, and it's awesome.
And you also see how often
you say the word "um."
So it's a little bit humbling.
Cognitive impairment-- as a user
with a vestibular disorder--
that is an off-kilter
balance, essentially-- I
want to be able to disable
parallax scrolling,
because that can cause
disorientation and nausea.
As a user with
dyscalculia-- that's
the number transposition-- I
want distinct number fields
for each block of digits
in a credit card number
so that I can
purchase a product.
One long field where you
enter all 12 to 16 digits
can be very confusing.
Breaking them up can be useful.
In order to not get confused on
pages with long text passages,
as a user with dyslexia I
want control over text size,
spacing, and/or
alignment, essentially
allowing me to shape the content
to a way that's easy for me
to read.
I was tempted to put
personas in here,
but Sarah Horton and
Whitney Quesenbery
have done a great job on putting
together personas already.
And you should go steal them,
because they're pre-written,
and they're good to go.
One thing I would
like to note, though,
having worked with personas
before, I know from experience
that personas are sometimes the
first thing that will get cut.
You want to get
down to n personas,
often that number is
maybe four or five.
And once you start
folding in personas
that are dedicated to
people with disabilities,
those are often the
first ones to get cut.
So what I do is I fold
in some variations.
I take a regular persona,
and I add some things to it
from these selfish
approaches that help.
So if I'm a persona, I work
when I should be relaxing,
and I relax when I
should be working.
I have a reverse day, because
I'm weird, or I'm a slacker.
I'm not sure which.
I live between
motorcycles, which
means I've always
got audio issues,
always got a hearing impairment.
I work late at night with the
TV on, so I'm always distracted.
I use the subtitles in Netflix.
I'm always relying on
the closed captioning.
I'm heavily reliant on that.
I also keep all screens
as dark as possible,
partly because I want
to save my battery,
and partly because I don't
want to scorch my retinas
in the middle of the night.
So these are all
scenarios where you
can fold these into a persona.
And just as I had run through
some sample user stories,
you can quietly fold these in
without necessarily giving up
that that's what
you're trying to do.
You can sneak them in.
So this one is one
of my favorites,
the click links as a user with
no elbow room in coach class.
People are going to say this
is important for the CEO.
We need the CEO
to like this piece
of software, this application.
Then you start to
ask some questions.
Does the CEO work on the train
or on a plane or in a boat
by a moat?
These are all factors
that you can use
to fold into your user stories.
Listen, this is something
that he'll encounter.
We're now supporting the CEO.
We are now doing that
thing that you want.
We're making it work for him.
Nobody needs to know
that you're actually
sneaking in some
accessibility best practices,
just like nobody needs to know
is that they map to real user
stories or that you're
folding some of these ideas
into personas that otherwise
might be completely discarded.
So you can sort
of stealthily fold
some of this stuff
in there, and people
don't need to know about it.
We're going to run
through some basic tests.
These are tests
that anybody can do.
If you have a web browser,
you can do the tests.
It's really that simple.
Click on the field labels.
When you're on a form,
it's the quickest way
to see if the field label
is associated with the form
control.
Usually it's the label element.
So when you click it, does
the field get focused?
Does the radio button or
checkbox get selected?
So in this example from
Buffalo Soccer Club,
an inner-city youth
soccer program
we started up at
Algonquin a few years ago,
and which we're very proud
of and which you are now
going to see as my
example throughout these
slides because it's awesome.
The contact form, if I
click on Name-- boom--
it puts focus in that
field, ready to go.
That means that those two
fields are correlated.
That means that
assistive technology will
be able to draw a
connection between them,
and the user will know
specifically what field
he or she is filling out.
Unplug your mouse.
My variation on this is to
unplug somebody else's mouse.
Because that's hilarious,
unless it's your boss.
Then it's not
quite so hilarious.
And then you have to
apologize, return it.
So turn off the track pad.
Turn off all those
pointing devices.
And see if you can still
use the entire application,
if you can use the entire page.
Can you tell which
item has focus
if you're tabbing through?
Do you know at a glance
where is the cursor,
where is it right now?
And does it match
your expectations?
If you start to tab
through the page
and it goes, field
1, field 2, field 14,
you've got a bit of a problem.
And you'll need to take a
look at what's causing that.
In this example,
I show that I've
started to tab through the
navigation of the site,
and I have the arrow pointing
at the sub-navigation that
has focus.
It follows the same
styles as the hover,
and it also has the outline,
the browser's default caret
to show me, yup, that's
where I am right now.
Turn off images.
Images aren't necessarily always
going to load anyway, but just
turn them off.
Let's see what happens.
Remember users can
have bad connections.
The images can be messed up.
If you can still make
sense of the page,
you're doing pretty well.
If content is missing,
you've got a problem.
If you can't use
the site at all,
you've got an even
bigger problem.
It also lets you see if the
alternative text you've put
behind those images is useful.
So here's the same page.
I turn off the images.
The page is still usable.
Some things to note-- up in
the corner, upper left corner
where the logo was, it
says Buffalo Soccer Club.
That's fine.
That's great alternative text.
That's exactly what it is.
The big picture where the
kid was standing-- nothing.
It's blank.
There's no alternative text.
And that's OK, because that
image is purely decorative.
Its presence there
doesn't add anything
to the value of
the content, and I
don't want to take somebody
on your screen reader
and have them listen to this
long description of kid happily
running after a
soccer ball, and right
after I took this
picture, he fell down,
and we all laughed, and
then we felt terrible,
and we apologized for an hour.
Because that's unnecessary.
You might also
note that there are
icons in the navigation across
the top and on the left side.
Those go away.
They don't add anything.
They're not necessary
to understand.
You will, however, notice
that the social media
icons aren't showing alt text.
There is alt text behind them.
You can see that pretty
quickly if you just view
the page or cursor over it.
There is alt text there.
The browser just does not
expand the space of the image
to display the alt
text, and since my goal
is for users of assistive
technology, that's OK.
Turn on high contrast mode.
If you have a Windows machine,
left Alt key, left Shift key,
and Print Screen drops your
rate and a high contrast mode.
And what that will do is
totally swap out your background
images.
It removes the
background images,
and it also replaces
all the colors
throughout all of your
stylesheets-- text colors,
the background
colors, et cetera.
So here's that same
page, ready to go.
There it is Windows
high contrast mode.
Background images have
gone away-- not a problem.
I know this because I also
tested it without images.
But also, everything
is still legible.
It's still a usable site.
So not high contrast
mode, high contrast mode,
it should still work.
There are media queries,
which I touch on later--
there are media queries
that allow you to detect
high contrast mode
in Windows, and you
can use those to do other things
as well, maybe scale text,
maybe do something else.
But I wouldn't do that
without first testing.
Turn off your style sheets.
This can be very eye-opening.
If important content or
functionality disappear,
as you need to consider
if that's good or bad.
It isn't necessarily
bad, but you
need to understand the impact.
If the error messages
are useless now
and you can't find them,
you've got an issue there.
Remember a style sheet can
be chunked on the download,
and that can be a problem.
If the content is still
in a reasonable order,
you're pretty good.
You want to check to see
if any styles are still
in place-- text effects,
colors, things like that.
That suggests that there
is some inline style
in your code, which
may or may not
be good, depending on what the
page is supposed to be doing.
I look for that, and I usually
flag that as a potential error.
So that soccer club page
with the CSS turned off,
I've scrolled down past
the navigation, which
is just a nested bullet list.
But otherwise, the
page just flows--
breadcrumb, h1, content,
picture of a kid--
pretty straightforward.
We're not losing anything there.
Test for color blindness
and color contrast.
Make sure there's
enough contrast.
This doesn't just
help the people
who are using the
screens in sunlight,
but it helps
potentially everybody.
Are the hyperlinks and
menus still visible?
If they aren't, you do
have a problem there.
I have some links in here
for some different contrast
checkers.
There are many, many
of them on the web.
Some are built into the browser.
Some are some add-ons.
These slides will be
available afterwards
so you can follow those
links at your leisure.
This is the same page as
viewed if you had protanopia,
deuteranopia, and tritanopia.
These project a
little differently
than they appear onscreen.
But onscreen, it's still usable.
It's still legible.
The colors still make sense.
You're not losing anything.
Look for captions
and transcripts.
If you have videos, if
you have audio files,
check to see if there
are audio descriptions.
Look to see if there are
links to those transcripts
and those captions.
You want them to
be easy to find.
You still build them into
whatever the player is,
but in case that player
doesn't support it
or the assistive
technology doesn't
support the player's
way of supporting it,
keep plain text links.
It's great.
Text alternatives
are a good way to go.
I have some tutorials
here as well.
I have a YouTube
captioning tutorial.
I think you guys have
heard of YouTube.
There is a great video, "The
Lady Vanishes," on YouTube,
which is the entire movie
that has closed captions
and audio descriptions.
You can watch the entire movie.
It's great.
And I think it's
in Spanish as well.
So watch it, and you'll
get a good example
of how these can be effective
and how they can be useful.
And for giggles, just
put mute on your computer
or your headphones.
Hyperlinks-- hyperlinks
are sort of the thing that
make the web what the web is.
If you have a click
here, more, link to,
consider changing those.
Let those be descriptive,
what the user
is going to actually
end up going to visit.
Assistive technology
allows you to navigate
through all the links,
and they're just
going to hear click here, click
here, click here, click here,
click here, click
here-- not very useful.
If you're using all caps
or a full URL or emoticons,
remember that might
be pronounced in a way
that you don't expect, maybe
spelled out letter by letter.
A URL spelled out letter by
letter is painful to listen to,
by the way.
I recommend you try it sometime.
It's awful.
Are you warning the user
before opening new windows?
This is critical
for managing focus
for users who are using either
assistive technology or not,
who just have trouble managing
the multiple interfaces.
At least give them a heads-up
that's going to happen.
Do links to downloads
provide helpful info?
Are you telling them this
is a PDF and it's 35 meg?
They can choose to
download it, but it's
better than surprising them.
Are you using pagination links?
If it's a blog, for example,
can they jump ahead a few pages?
Can they jump back?
Is this something they
have the freedom to do?
Are your links obvious?
I always recommend
underlining them.
But make sure that
they're are obvious.
Make sure that there is alt
text for any image links.
Just because the image means
one thing in one context,
if you make it a
link, it probably
should have its alt text
updated to reflect that.
And is the link text consistent?
If you're pointing to the same
35-megabyte PDF annual report,
maybe every time
you link to it, you
should say Annual
Report 35 meg PDF.
That way they
don't think they're
getting a different
document every time,
and they're not downloading
it over and over and over.
How much time do I have again?
WOMAN: You've got until 3:00.
ADRIAN ROSELLI: Until 3:00?
[SIGHS] We're going to
go over by like an hour.
It's so weird.
There's an all-seeing
eye right there.
It's so uncomfortable.
Hi.
I'm going to jump into
some technical bits here.
The nice thing is this
is the last section.
So that's awesome.
If you don't know what ARIA is,
Web Accessibility Initiative--
Accessible Rich
Internet Applications.
ARIA adds accessibility
information to HTML elements
and to elements that
aren't necessarily HTML.
It can be sued with
prior versions of HTML.
So if you, like me, are rocking
some HTML 3.2 page somewhere,
go nuts.
Just be prepared to
throw some ARIA on
there so that it can
be useful for people
with assistive technology.
The 1.0 specification was
published in March of 2014,
but it had been in use and
been supported for a long time
before that.
So this technology
has got great support
and has been out
there for a while.
There are five
rules of using ARIA.
They're pretty straightforward,
which is awesome.
And they're simple.
The first is if you can use
a native HTML5 element that
has the semantics or behavior
that you want built in, do it.
Just use it.
Good to go.
You don't need to
worry about it.
You want an h1?
Great.
You want a header tag?
Great.
A footer tag?
Awesome.
You're off to the races.
You probably don't
need to use ARIA.
You're doing a good job with it.
Do not change native semantics.
That h1, if you want
people to click on it,
don't put a role
of "button" on it.
Once you start changing
those semantics,
assistive technology doesn't
know what to do in every case.
It's not going to bind
that to keys, for example.
Leave your h1 as
an one as an h1.
Put a button in there if
you really want a button.
All interactive
ARIA controls must
be usable with the keyboard.
So if you want
somebody to click,
let them also use the Tab
key to get to it and Space
or Enter an order
to activate it.
If there's a drag
and drop, you need
to figure out a way to make that
work with the keyboard only.
Do not use role "presentation"
or ARIA-hidden "true"
on any element that gets focus.
By focus, I mean
tabbing through the page
until it gets that
outline, that caret.
If you do that, users
won't be able to focus it.
I can't tab to
that element once I
put hidden "true" or ARIA-hidden
"true" or role "presentation."
It just isn't available
in my tabbing order.
All interactive elements
must have an accessible name.
Typically if you have
a button element,
it's the text inside the button.
That's pretty easy to do.
Alt text on an
image, for example,
that is the accessible name.
There is a relatively
complex way
of doing the accessible
name calculation.
I'm not going to stress you
out with that, because it's
very easy to just fire
up some technology
and check to see what
it's speaking to you,
and then you'll know if
you're doing the right one.
So here's an example of
something not to do with ARIA.
So some people like to
take divs and make them
into buttons or links.
So they put an onclick
handler on a div.
Well, they do that,
and then they quickly
find out that, well, they
can't use it with the keyboard.
So they add a tab
index of zero to it.
OK, now I can at least get
there with the keyboard.
But when I hit the Enter
key, nothing happens.
So I have to put an onkeypress.
OK, so I put the onclick.
I put the onkey press.
I can tab to it.
By the way, I'm excluding the
key codes and other things.
I'm keeping this short.
Key codes are at the
bottom if you really
want to check my math.
But the thing is still
not completely useful,
because it doesn't get
the native features
from the browser.
So now you put a
role "button" on it.
So now you can do all
the things with this div
that you could do with
the button element.
Or you could use a button.
I mean, it is that simple.
The element already exists.
In most cases when you're
trying to repurpose an element,
there's already an element
that will do it for you.
There's already some ARIA
that will help you there.
This is just standard HTML.
There's no ARIA in there.
And that's probably
the best use of ARIA
is not using it because
you don't need it.
There are some things to note.
ARIA can be overused.
There are cases where
people have said, oh, well,
don't worry.
We'll just sprinkle some
ARIA on it, and it will work.
And I link to two articles,
one by Jared Smith from WebAIM,
"Accessibility Lipstick
on a Usability Pig."
It's a great read.
Marco Zehe also has "What
is WAI-ARIA, what does
it do for me, and whatnot?"
And those are both
cautionary tales
of how you can
overuse it and create
very much the opposite
effect that you're going for.
HTML5 has these
beautiful elements
built in that have
accessibility already
there built into it by default.
It's just what it does.
Header, nav, main, use
one per page, please.
A side footer, form,
it's already there.
The browser knows what to do.
It can through these landmarks.
It can navigate into
different sections of them.
They map to ARIA
landmark roles already.
Header has a role of "banner."
Main has a role of "main."
They're already built in.
So you don't need to
add the roles on there.
And the browsers support
it reasonably well.
So if I do a generic
desktop layout,
there they all are, the footer,
the header, the main, the nav.
They're there.
If you were to view
it mobile-- and I
say mobile because
in responsive design,
it usually just
means linearizing
for a narrow screen.
Same stuff, just use
the right elements.
They've already got
the stuff built in.
You don't need to
rely on the roles.
ARIA isn't needed, because
it's already there.
Leave the roles out.
You're good to go.
HTML5 headings-- a lot of people
will navigate by headings.
Go in order.
Don't skip around.
h1, h2, h3, step
back out of it OK.
Don't go h1, h2, h4.
You're creating some confusion
for a user at that point.
There is no document
outline algorithm.
It's mentioned in
the specification,
but no browser supports it.
So if anybody's telling you
that the document outline
algorithm is something
that needs to be supported,
which is every time you do a
section you put an h1 in it,
for example, ignore that.
Just follow good
heading structure.
Section and article are often
misused as generic containers,
and they are not.
Those can overwhelm users
of assistive technology,
because they're just
thrown all over the page.
My rule of thumb
is unless you're
going to put a heading
in there in h1 through 6,
then don't make it a section.
Don't make an article there.
It's unnecessary.
If you need a
container for styling,
use a div-- no big deal.
Virgin America website has been
hailed as a really good design.
There is no indicator anywhere
on the page where I am.
As I tab through
this page, I have
no sense of what's
going on, of where I am.
It's a simple, simple fix
and an absurd oversight.
You need to have
the focus styles.
Keyboard users can't use
your site or your software
without them.
If you already
have a hover style,
a colon hover,
put a colon focus.
Match the selector, put focus.
If you are using
libraries, see if they
have focus styles in them.
And if they do, look for the
outline none and remove it.
You'd be amazed at how
removing that one line of CSS
makes a whole lot of
sites and applications
suddenly conformant.
Suddenly they're usable
again just by removing that.
See, we're almost done.
This is actually perfect.
Alternative text on
images-- do use it.
Use it every opportunity you
have where it makes sense.
In particular,
think about images
where the image contains
a lot of content.
Think about
infographics, probably
the most inaccessible
form of graphic expression
we have right now on the web.
An infographic can't be
read by a screen reader,
and alt text is usually
insufficient in order
to convey what's in there.
There is an attribute in
HTML called Long Desk.
Also, ARIA-describedat
is the ARIA equivalent.
And all you do is you provide
a URL to a longer description.
And in the image here, I
have a pretty large graphic
on the left, and on the
right I have the full text
transcription of everything
that's going on in the image.
When I did that, that
links to a separate page
that held all of my
long descriptions.
Since then, some
research has been
done that shows
that users really
prefer keeping that long
description on the same page
so that you're not sending
them to another page,
and then they have to
hit the back button
and load the page two
more times in total.
But it's pretty easy
to write that out,
and I'm speaking-- this
is going to sound weird,
but if you're a company that
worries about search engine
optimization, for
example, it's a great way
to get some valid keywords in
there without keyword stuffing.
If anybody in the
room thinks I'm wrong,
this is probably the
best room to tell me so.
Anybody on there?
What's that?
AUDIENCE: [INAUDIBLE].
ADRIAN ROSELLI: Aw.
I was counting on you, too.
There is an alternative
text decision tree.
I'm putting this up
there to show you
that somebody has
actually mapped out a way
that you can use a simple
flowchart to figure out,
should I put alternative
text on the image?
It looks complex.
It really isn't.
Most people already
intuitively understand it.
You look at it,
and you go, what?
Is it useful?
Is it informative?
Should I describe that?
Does it have value?
This is just a
framework just to make
sure you're going
down the right path
and to sort of validate what
it is you're already doing.
At the end, I have a
bunch of resources.
And like I said, these
slides will be available.
So the W3C has put together
this great article,
"Web Accessibility
and Older People--
Meeting the Needs
of Aging Web Users."
It's also got "Easy
Checks-- A First
Review of Web Accessibility,"
which is a checklist.
But like any checklist,
it's just a starting point.
And it talks about how you make
sure that these things stay
current and up to date.
Also, there's a great
article about how people
with disabilities use the web.
It's an overview.
You can dive into
a lot more detail.
These are really
simple overviews.
There's a lot more
good stuff out there.
I have references
for ARIA in here.
All of these things I think you
guys can also find on your own,
but Role, State, and Property
for the Quick Reference,
and all the ARIA dash
whatever attributes.
And then there are
accessibility tips, designing
for the elderly, how
to write user stories,
book excerpt, "A
Web for Everybody,"
which talks about more of those
user stories and personas.
And that is my talk.
Down here I have a URL,
which I'm going to repeat,
because I'm going to
post these slides later.
And you are all welcome to
comment with corrections
or other things,
Rosel.li/Googa11y.
So I'll spell that out.
R-O-S-E-L.LI/G-O-O-G-A-1-1-Y.
It sounded punny when
I came up with it.
And now that I've set it
aloud, it sounds dumb.
But that's the URL I've
already put together.
The slides aren't up there yet.
Probably tonight or
tomorrow I will post them.
I will tweet a URL, and I
will send it to whomever
is interested as well.
So that's the nature of my talk.
WOMAN: Great.
Well, thank you so much.
This is so great.
ADRIAN ROSELLI: Thank you.
Thanks for having me.
[APPLAUSE]
