Cookies   I display ads to cover the expenses. See the privacy policy for more information. You can keep or reject the ads.

Video thumbnail
My name is Ian Forrest I'm visiting here
from Toronto very excited to be here. You
can find me on Twitter at ianforr with two
R's. I'm an Engineering Manager at Biblio
Commons a SaaS company that provides
services to public libraries like St.
Louis Public Library Chicago Public
Library Boston and many others. When you
visit the library and search the catalog,
place a hold on a book, register for an
event, those are the kind of features
that we provide. Fun public library fact:
we experience a traffic spike every year
in the first week of January that goes
back to normal after a couple weeks...
I'm not sure how those New Year's
resolutions are doing. There's a lot to
talk about when it comes to web
accessibility. I'm not gonna have time to
cover it all. My goal is to provide an
overview of accessibility concepts to
help put things into perspective and to
provide recommendations for what you can
be doing at your workplace
and in your community.
All right this is my dog
Willow, I always include her in my slides
she's a huge Cardinals fan and since St.
Louis is a National League city she
hates designated hitters. She also hates
wearing hats, it was a difficult picture
to take. We're gonna break this into four
sections first terminology. Disability,
what's a disability? A physical mental
cognitive or developmental condition
that limits a person's ability to engage
in certain tasks or participate in
typical daily activities.
Note the word typical, this is key. A
disability is contextual. For example, a
person with a seizure disorder might not
identify as having a disability if they
can depend on public transportation and
it's under control, but the same person
in a rural area who can't have
their driver's license anymore might
identify as having a disability. It also
changes over time. We develop
disabilities as we age, if we have an
accident, if we develop a health
condition. How many of us have parents or
grandparents who need to zoom their
browsers or
or use hearing aids? And it can also go
the other way,
for example, some health conditions like
seizure disorders or mental illness can
improve with medication or therapy.
Assistive technology, my definition here
is tools to help people perform tasks
that might otherwise prove challenging
or impossible. There's a lot of examples:
a wheelchair, a white cane which is
something that a person with vision
disabilities would use to detect if
there's stuff in front of them, hearing
aids screen, magnification software,
screen readers which is software that
helps people with vision disabilities
use computers, examples would include
JAWS, VoiceOver, or NVDA. Speech input
software like Dragon Naturally Speaking,
or even Siri, and there's lots of other
tools for people with motor disabilities.
So if we take a look at this link,
I'm going
to zoom in a little bit so people can
see. Mouth sticks and head wands for people
with physical disabilities, we've got
switches, there's special keyboards for
people with dexterity issues who find it
difficult to use regular keyboards
there's all sorts. A11y stands for
accessibility, there's 11 characters
between the a and the y. Americans with
Disabilities Act, ADA, is the
accessibility legislation in the U.S.
Web Content Accessibility Guidelines, WCAG
defines how to make the web more
accessible to people with disabilities
you might see 2.0 out there but 2.0, or
sorry 2.1, is the current version and
it's been out for some time. It has more
for mobile, low vision, and cognitive
accessibilities. And aria is a tool at your
disposal to help you meet WCAG
standards, some example attributes might
be like aria-hidden or aria-labeledby. It
shouldn't be your first tool of choice
you should be using HTML elements to
their semantic specifications first for
example don't use something like div
class equals button. Div's aren't
focusable by default so use a button and
style them. Now we're going to talk about
why this is important. In our physical
spaces there are a lot of affordances
which exist to help people with
disabilities so we can think of
wheelchair ramps, stair railings, buttons
to open doors. We all use these and we
take them for granted but it wasn't
always the case.
It wasn't that long ago that most of
this infrastructure didn't exist. so in
Toronto our subway stations built in the
60s which isn't that long ago, they're
retrofitting elevators right now which is a very
slow and expensive process. In general
people with disabilities were not valued.
There was a strong disability rights movement
in the 60s and 70s, Ed Roberts was the
first student with severe disabilities
at UC Berkeley, and thanks to the work of
him and others public opinions start
shifting. Hooray! But we still have
problems. The world was not built for
people with disabilities. Here I'm
showing a photo of a wheelchair at a
curb with a five inch drop and if they
keep moving forwards they're going to
fall over. So we invented curb cuts, and
other things like basic human decency
which is still work in progress, but
here I'm showing a picture of a
wheelchair rider at a curb cut. Today
many people don't realize that curb cuts
were designed for wheelchair riders.
People assume that they exist to help
with strollers, with luggage, pull carts,
it just kind of makes sense for them to
be there. That's what the curb cut effect
is - the idea that improvements that we
make for users with disabilities end up
making things better for everybody. And
while this is like nice, it's important
to remember while these affordances are
nice to haves or people without
disabilities, that they're essential for
people with disabilities. For more on
curb cuts than their history and
influence you should check out this
podcast 99% Invisible, they have an
episode called Curb Cuts. I highly
recommend giving that a listen it has
more background on Ed Roberts and on
curb cuts and all that. And another thing in
that last picture with the with curb
cuts - they helped one group of people,
wheelchair riders, but they introduced a
problem for another group.
Without curb cuts, people with vision
disabilities who are using white canes
could tell that they were leaving the
sidewalk. But with curb cuts that causes
a problem
for them so now they frequently feature
a second accessibility affordance called
Tenji blocks or tactile paving which
signals to people with vision
disabilities who are using a cane that
they're leaving the sidewalk, or near
danger like at the edge of a train
platform. But we're still not perfect.
This is a recent photo of an
intersection in Brooklyn where a
wheelchair rider is at an intersection
with no curb cuts and is visibly
frustrated, for a good reason.
This is what it means for them. This is
the distance that they have to
travel versus the distance that a person
who can walk across the intersection along
the diagonal has to travel. This is also
assuming that every nearby intersection
has curb cuts. It's really just terrible.
On a similar note in St. Louis we have
these scooters everywhere. They're like a
plague. I've never - this is new to me. I'm
showing a picture of an electric scooter
parked right in front of a curb cut in
St. Louis. It's not the only one that I
found like this while I was walking
around downtown earlier this week,
they're everywhere. This is going to
block wheelchair riders from using this
intersection and it's also just in like
everybody's way. I get think they can
help some people get around but they
shouldn't leave them around like
this - docks or something might nice.
Ironically it was very close to a street
called Locust Street. So today we're in
the midst of a similar push for
disability rights this time in our
digital spaces the legislation exists,
the standards exists, the fight now is on
the value that software companies place
on people with disabilities. So now that
we've looked at some accessibility
history we're going to look at how to
improve the accessibility of your
websites. I'm not going to be mentioning
WCAG very much - it's really valuable
but it's best to focus on concepts first
and then look at the exact requirements
that you need to meet after you know the
concepts.
Okay so where's the best place to start?
Your keyboard. Making sure that your
website works with a keyboard is really
good and it's also going to be a good
litmus test for other types of assistive
technology. We want users to be able to
tap through your pages in a logical
order generally left to right top to
bottom and that that can tell where they
are. Browsers will show focus outlines
and elements that you can interact with
by default like links, buttons, and form
elements. So let's start off with some
bad examples, come on internet again. Okay.
So I'm just gonna start tabbing and we
can see where we are, this blue focus
outline. The first thing that's a little
odd is that the pagination here goes to
the right arrow first and then it goes
to the numbers. It's not that big of a
deal but something to note. Then I'm on
the the jacket cover, the title, Place
Hold, goes down to the second item
checkbox, then back to the first item Add
Author Alert, the second item jacket
cover, then Add Author Alert for the
second search
result and then it goes through all of
the Add Author Alerts. And then it goes
back to the second items title and then
to the Place Hold button for it and
then sort of normal-ish
again. You can imagine if you have vision
disabilities and you can't see the
screen how confusing this order would be.
Once we get to the bottom of the page,
how many do we got - twelve results. Get to
the pagination. Then it takes you up to
the header, which is probably one of the
first things that you would want to tab
to when the page loads. It doesn't take
you to the log in, my account, my lists,
links. And then we scroll through the
filters on the sidebar there's lots of
them which is fine.
And then it takes us back to more links
that are in the search results so
they're just kind of like spread out all
over the page and it's a very confusing
experience. Another example, St. Louis
Blues website. Congratulations on
winning the Stanley Cup St. Louis, but
your website's not going to win
accessibility awards. I'm tabbing through
it right now,
the first few I couldn't tell where I
was. Now we can kind of see that on the
2019 Stanley Cup Champions text then the
Enterprise logo, and then I'm lost again.
I assume that I'm in the header
navigation. Eventually I see - okay so I'm
in the scores, and I'm just kind of
bouncing all over the place. Again, a very
confusing experience. What's happening
here is that if we - I can't really like
zoom here - but if you inspect the element
and you look what they're doing, they're
actively suppressing the focus outline.
Outline zero, or outline none, it's a
very bad idea.
It's so bad that it has its own website
called outlinenone.com. I'd recommend
going there taking a look at that, but
this makes your sites very unusable for
a large variety of users. People with
motor impairments that rely on assistive
technology like mouth sticks, people with
repetitive strain injuries who use speech
input software... a lot of different types
of people. Just don't do it. Let's look at
a better example here's the St. Louis
Public Library search. The first thing
you're gonna notice is that - the first
thing I do is I hit tab - I come to these
links that weren't there before. These
are called skip links, and they're
basically links that are are in the tab
order but they're off screen.
Screenreader users who are going through
your page, and they can't see the screen,
it's the first thing that they're going to
interact with and it allows them to skip
to certain areas of the page. And also
users with no vision issues
who are using other assistive technology
can use this
as shortcuts to get around your page if
they can't use their mouse. I'm going to
"skip to content". it's just like a regular
anchor on a page that's pretty basic. And
yeah, just tabbing through the page, going
through the sidebar these ones are all
the links and buttons, they're working in
order, it's pretty straightforward. You
get this for free by just doing
literally nothing. Another slightly more
advanced example, zoom in a little bit
here, also "skip to content". Something that
happens on websites that have a little
bit more interactive elements, say an
overlay, is you need to programmatically
manage your focus. So here I'm going to
click on an Event with my keyboard, and an
overlay pops up. What happens
sometimes if you don't move focus
explicitly with JavaScript to within the
overlay, what happens is you get stuck
behind the overlay. So if you can't
see, if you're using a screen reader,
you're not even gonna know that this is
here - you're still going to be tabbing
through the search results. In this case
it works, we're trapped in the, in
the overlay. I'm gonna tab through the
items, get to the close button, now you
can see that I'm tabbing through
the Chrome tabs at the top, so I can't
get out and go behind the overlay which
is great. I'm gonna close it and I move
right back to where I was. That's also
something that you have to do
programmatically, is remember where they
were before and then move them back
exactly where they were afterwards.
This is some sample CSS for skip
links. You just give your link a class
and moves it off-screen and then
whenever it receives focus it puts in
the top-left corner.
But we as BiblioCommons we've come a
long way. This is a Jira ticket that came
in from a library a few years ago where
they logged a bug and said that in
Firefox, probably other browsers, the
active element in the CMS is outlined in
blue. Can we hide this? We went ahead and
we did that. So we've learned a lot since
then.
Focus outlines are a default feature in
all web browsers. They're an example of
a "digital curb cut". They're
helpful for everybody, for example when
you're tabbing through a form it's
useful for everybody to know what input
you're on so as you start typing you
know that you're entering your email or
your password or whatever. Removing them
is like a reverse curb cut effect.
Another one is underlines.
It's not - well there's kind of like a
gray area on this, people can argue
that people are used to the title as
being links so maybe you don't need it
there. Same with these checkboxes perhaps.
But these ones are confusing because for
people who aren't color blind, color
is often used as an indicator for links.
These ones are blue but they are not
links, except the author is a link, it's
sort of an easter egg. But the author
label isn't, so again it's just a
little bit confusing. If you're going to
remove the underlines be
intentional about it and make sure that
there's other affordances so that people
can tell what's a link and what's not.
I made up this quote "I don't like the
way curb cuts a look so let's remove
them to make our intersections more
aesthetically pleasing".
It just sounds ridiculous right? So this
is a person who doesn't know what curb
cuts are for, or developer who uses div
class equals button, if you want a button
use a button and style it, it's a
designer that wants to remove all
underlines from their links without
adding other affordances,
or it's us in that last bug fix. And it
sounds funny but things like that still
happen in physical spaces. David Lepofsky
is a prominent figure in the
accessibility community in Ontario and
he's one of the funniest speakers that
I've had the pleasure to see. He has a
video describing accessibility problems
at Ryerson University, one of their
new buildings in Toronto. I'll show some
screenshots for it, and he also retweets
everything with the hashtag #AODAfail
which is the Ontario equivalent of the ADA
So I did a quick check for #ADAfails
on Twitter. Here is one "when the federal
government doesn't follow a federal
government policy do you report to the
federal government?" and there's a
post-office box right in the middle
of a sidewalk. Another one, this one has
the tactile paving on only half of the
sidewalk so if a blind person is
walking with their white cane they might
not be able to tell and they might just
walk right into traffic. Here is a
screenshot from his video. He's blind and
people who have vision disabilities will
use hand railings to help guide them up
the stairs. So he found this rail and he
was climbing the stairs, and he ran into
this pillar, and he found his way around
it, and found the railing again, and it
loops around and takes him back down the
stairs. Another issue here which isn't
noted is that the hand railing, the way
that is held there, it's very sharp
on the bottom so if you're using that to
guide your way up the stairs you could
cut or hurt your hand. And here's
another one. The main entrance is so
difficult to use that they added an
"accessibility entrance", for a brand new
building, and there's an angled pillar
right outside of it. So he is leaving the
building, he's using his white came to
see if there's something in front of him
and at his feet there's not, but at his
head level there is because the pillar
is angled, and he ends up hitting his
head.
Okay moving on, next alt text and
screenreader text. The goal here is that
screen readers can understand the active
element on your page.
Alt text: many images on your page are
going to be decorative, meaning that they
don't add information to your page, it's
already there. All images need alt
attributes but they don't all need alt
text. You can give them alt equals
"empty string" and then assistive
technology will know that this image is
decorative and not to announce it to
users. Also repetition: it can be
confusing and frustrating to screen
reader users and other users when you
have multiple links next to each other
that go to the same place. We think back
to say the switch device, some
users with severe disabilities,
the one I listed, the person would
be using their head to hit the switch
and if you have too many tab stops
it can cause fatigue. Also if there's a
bunch of links with the same text and
they're using assistive technology
to look at the links and they all
say "click here", that can be confusing too
because it doesn't provide context.
Though there are cases where you want
adjacent elements on the page to link to
the same page and there are ways you can
do this and I'll show that. So let's
take a look at some bad examples again.
This one, before I turn on my screen
reader I noticed recently that they
added this icon of a wheelchair icon
that says "enable accessibility mode". I
don't know what type of person adds an
accessibility mode to their website and
defaults it to off, but when you click it,
it looks like it just adds the skip
links as visible. That's the only thing
that I could tell that it did with a
quick glance. And the other thing is that
whenever you click it it still moves
focus to the search input, so if you are
using a screen reader you're not even
going to know that those skip links are
there because you start tabbing it
goes through the page
afterwards. So we're going to turn on
VoiceOver, make sure I'm muted, I'll read
out the important stuff.
So here if we can see we're on
pagination, but if you're using a screen
reader this says "link 2", "link 3", "link 4".
If you're using a screen reader you
might not know that this is pagination,
it doesn't provide that context to you.
TThat's something that we can make
better. Also the Add Author Alert buttons
just say "Add Author Alert" and that's it,
you don't know what author you're adding
an alert for when you're going through the
page. And I'll turn VoiceOver off. Again
with the decorative images I would
consider these jacket covers decorative.
If you're using a screen reader it
doesn't really matter that they're there
or not because you get the same
information from the title of the item.
So here they just say "link, image,
cover image for X Files Season 5" and the
link says "link, X Files Season 5". It's
the same thing so it just adds an extra
tab stop that could cause fatigue for
users.
Another example bestbuy.ca, which is
different from bestbuy.com, interesting
engineering choice.
On the Canada version it has an issue if you
search, the jacket covers for the search
results are marked as informative.
It looks like the alt text for the
image is like an ID so the
screen reader users will say link image
/m2222017.jpg,
list, 32 items. It's very confusing, it's
unnecessary, you can make this
decorative and you just go through the
search results and it would say Twilight
Zone Volume Two. That'd be much better. So
let's look at a better example, turn on
my screen reader, skip to content,
and there,
okay so here we've made the jacket
covers decorative and we're also hiding
them from assistive technology and
taking them out of the tab order so you don't
tab to them, which is fine, and whenever
you go to a say, a "Place a Hold" button it
says "Place a hold, The Testaments, audio
CD by Atwood, Margaret". So each of
these items is giving more context about
what the link or button is. And then at
the bottom I go through all these search
results,
you can see that the the pagination,
if you can see it's pagination clearly,
but if you can't and you're using a
screen reader they say "go to page 3"
"go to page 4", so we're adding more
context there for screen reader users,
and I'll give some examples
for all that. This one is for the
duplicate links, so if you have an image
and a title that are both going to go
to the same place you can just wrap them
in the same link and make the image
decorative. In this example you make the
image decorative by giving it alt equals
"empty string" and a screen reader will
read this out like "link, heading level 3,
Pride and Prejudice". Sometimes you need
to have HTML in between the other image
and the title. A neat trick that you
can do there is you can use aria-hidden
and this will hide it from assistive
technology, and then you can add tabindex
equals minus 1 and that will take it out
of the tab order which prevents, if
you're using the tab key, it just bypasses
it. So this will be ignored completely
and if you're using your keyboard you'll
get to this link and it will say "link
heading level 3, Catch-22". Be careful with
tabindex, values greater than 0 will
hoist elements to the top of the
navigation flow so if we have them like tabindex
1, 2, 3, those items no matter where they
are on the page are gonna be the first
items that you tab to before anything
else in the logical order, which was probably
what was happening on that earlier
example with the Add Author Alert
buttons. They probably had positive
tabindex values. And here finally if
links had the same text, the screen
readers are gonna be missing context, so
you can add visually hidden text. This is
different than display none or visually
hidden where those CSS rules will hide
that text from screen readers. This class
sr-only is something that shipped with
Bootstrap, there's probably equivalents
in most front-end frameworks. Basically it
kind of clips the text and makes it
hidden but it's still there for screen
readers and they'll read them. So the
first example is just going to say
"link, place hold" you're not gonna know
what it's for. The second example will say
"link, place hold on The Color Purple"
which provides a lot more context.
Headings: you're gonna need to use a
proper heading hierarchy on your pages.
You can think of this as a table of
contents so if it makes sense to be in a
table of contents then you probably want
to make it a heading, otherwise make it a
list or just a div or a paragraph or
whatever. The semantics for headings is
what really matters to screen readers, it
doesn't really matter how they're styled,
so you can have different h2s and have
them look differently. Let's look at some
examples. Chicago Public Library, their
page looks like this I'm going to use a
Chrome extension "Web Developer". View
document outline, and you can see that
this is the headings and the top
navigation. Generally we want the h1 to be
the first item but our accessibility
people said if we're consistent with
this that it's okay. We see Chicago
Public Library homepage, homepage
featured content, and these are all like
content blocks and the h3s within them.
Makes sense.
For a bad example let's look at H&M's
website, it looks like this it's fine. We
look at their heading hierarchy, the
first thing is that they're
missing an h1, every page needs to have
an h1 and only one h1, then they're
missing an h2, then they have a bunch of
h3s where they're yelling at us, and we
keep scrolling down to the bottom
there's a heading that doesn't have any
text in it which is confusing, and then
this looks kind of weird right? I don't
know what's going on here, so we can go
back and take a look. We scroll down to
the bottom we see Magazine, Easing Into
Fall,
Bring back the 80s, Three ways to wear
houndstooth. If we look back here
if you're using - if you can't see the
page and you're using assistive
technology like a screen reader you're
gonna infer that Shop, Corporate Info,
Help, and Become a Member are all sub
items of Three ways to wear houndstooth.
It's probably not the UX that they were
going for. If we look at the page
those were the footer navigation
headings. They should probably be h2s and
they probably just made them h4s because
the default styling for the h4 was
smaller, but you can just style an h2 to
have a smaller font size. Low Vision: you're
gonna have people who need to zoom your
page, the text in your page, in order to
read it. There's two types of zoom,
you can zoom text only or you can zoom all
of the content. It's also a digital curb
cut, there's lots of situations where
people zoom pages. Here we have two
examples of staff lists both zoomed at
200% text only zoom. One looks perfectly
fine the other one has text overlapping
the image and it's not because the image
is on the bottom versus the top. What
happens here is that one of these
containers had a fixed height in pixels
which is a fixed unit. The other one has
a fixed, sorry, the height measured in
rems which is a relative unit and if you
zoom text, if you're using relative units
on your container heights they're going
to adjust with with your text zoom.
You're also going to need to consider
color contrast - again good color contrast
is a digital curb cut so when you're
reading your phone outside on a sunny
day, or some people probably can't even
read this bottom one but it says "thin
light grey fonts on a white background"
It's very difficult to read. Here's an
example of the WebAIM contrast
checker. This is one of our websites,
this is in the footer "Browse staff picks
new titles and more". This is a foreground
color, dark grey, the background color is
a lighter grey, the contrast ratio 4.09:1 which does not
meet WCAG level AA requirements
which would be 4.5:1
for regular weight text. But if we
bolded it,
it has different rules for bold text
versus regular weight text and it would
have been fine. High contrast themes: some
users with low vision are going to use
high contest themes to view your site. These
are gonna look strange to you if you
haven't seen them before but for people
who use them it's much easier for them
to read your page. So let's look at an
example. This is St. Louis Public
Library's homepage, looks fine.
This is what it looks like in a high
contrast theme. It's kind of really hard
to see the the purple on the side on the
projector but on a computer monitor it
does meet color contrast requirements.
The main thing here is that everything
is still here right, so you can see the
the logo up here, regular text and
borders and stuff like that's in yellow,
buttons are in white, links are in blue,
all the images are displaying. We can
just make sense of the page.
Here's Apple who has a reputation for
their amazing design, mid 2018 selling
the iPhone X front and center, and this
is what it looks like in high contrast.
So their photography is completely
absent. What they did was they
implemented their image as a CSS
background and high contrast themes will
correctly infer that CSS backgrounds are
part of the background and not necessary
to understand the page. So the hero
banner on the St. Louis
example is correctly using the image as
an image tag and then here they're using a
CSS background image. It's really basic
stuff again that you get for free when
you use HTML and CSS as they're intended.
Question?
The question was is there a way to
switch between the background image and
the foreground image? There's probably a
JavaScript solution but you can't really
detect whether you're in a high contrast
theme or not with CSS - actually you can
with CSS but you can't with JavaScript
necessarily, but also you could just use
an image tag. Also in this example the
navigation is missing for some reason, I
don't know why that is but that's also
something that's a problem for them.
Another issue,
high contrast themes are gonna make your
backgrounds consistent so everything
goes to black in this theme - there are
other themes and in Windows - to help
remove clutter and to make the page
easier to read. Sometimes background
colors are used to group related page
elements together. Color here is being
used to separate the modal, which has a
white background, from the stuff around
it, which is sort of grayed out.
This is what it looks like in high
contrast, it's a little bit confusing,
kind of looks like there's a paragraph
just sort of stuck in the middle of a
page that's beside the form elements for
"Name" and it's clipping
it. There's a neat trick that you can use
to help, you can add a 1px solid
transparent border to the overlay and
the high contrast themes will pick that
up and preserve that, and whenever you're
not in a high contrast theme it still
just looks the same. So if you have
overlays like this and you're graying
out stuff behind it, you can add a 1px
solid transparent border and it
will make it better for people who are
using high contrast themes. Another
aspect that's often overlooked is
cognitive accessibility. Common examples
of cognitive accessibility issues could
be icons that the user doesn't
understand, when the tab order on the
page doesn't make sense like in that
earlier example, or if your target
audience and the content reading level
don't line up. HemingwayApp is a tool
that you can use to test the readability
of your sentences or paragraphs or
content. Often content writers
will use this as their text editor.
We can take a look at that, I'll zoom a
bit, it looks like this. It will give you
recommendations, using passive voice or
if your sentences are too complex. We can
take a look at one of Toronto Public
Library's kids blogs. This is their
kids blog
it's one of their posts for getting a
library card, I'll copy their text, and here it
says grade three so they did a really
good job. A kid is probably going to be
able to understand this and it gives a
recommendation that "maximum" might be a
difficult word for a kid to understand.
One of our libraries has an
accessibility FAQ that has a reading
level of post-graduate, not very
accessible, possibly written for lawyers.
Finally how to build accessibility
culture at your workplace. First
everybody needs training. Designers need
to be aware of these color contrast
guidelines, product managers need to know
and understand the engineering overhead
required to build an accessible
autocomplete multi-select input, I don't
know if one exists that's accessible,
developers aren't going to just know how
to use a screen reader it isn't the same
as your tab key. Screen readers
have controls and shortcuts, they can
read paragraphs, I've had developers just
tab through a page they didn't know you
could read paragraphs with VoiceOver or
whatever, and it's also different for
mobile devices where you don't have
keyboards and they're gesture based or
for voice recognition software. At
BiblioCommons all the full stack
developers take the online course Web
Accessibility by Google Developing with
Empathy. I would recommend checking that
out it's free and it does a pretty good
job of going into a little more detail
about some of the stuff I'm talking
about here. If you have access to
Frontend Masters, there's also a new
course by Marcy Sutton called
Accessibility in JavaScript
applications which is also good.
You gotta test for accessibility.
Automate what you can and if you can
afford it hire real people or companies
to do some of this for you because none
of us, well, I'm not an expert, I don't use
assistive technology on a daily basis, so
I can't really tell if something is
gonna work for everybody. That's what
these companies are for. If you can't
afford that, your internal QA should be
trained to the best of their abilities
to do this but unless they're using
assistive technology on a daily basis
the results might vary. We work with a
company called Level Access to get
feedback, hi, yeah they're a great company,
they employ people with disabilities who
test our features as we work on them and
give us great feedback to help our
features be more accessible. We also have
an internal accessibility dashboard for
tracking accessibility
metrics. On my team we run pa11y against
our builds, there's a link to it here,
it's open source it's on GitHub. It's
similar to the results you might get on
the WAVE tool. Note that tools like this,
they're good for tracking or catching
low-hanging fruit or simple issues,
like if an image is missing an alt
attribute or if you don't have an h1 on
your page. But they're not good at
finding more complex "real issues"
where say an overlays pops up and you
don't move focus to within the overlay.
Local accessibility communities. Many
cities have these, they're great with
training, there's so much that you can
learn from your community,
and it's important to listen to people
with disabilities and to go to these
meetups and you'll learn a lot. St. Louis
has a brand new one it's just starting
it's called St. Louis Digital
Accessibility and Inclusive Design.
There's a link to their meetup page here.
It's good for everybody: product
managers should go to these, UX
engineering, everybody. If you're from
outside St. Louis, Meetup has a tag for
web accessibility and you can go there
and see if there's one in your city.
Pictured here is one of my coworkers,
he's speaking on a panel at an
accessibility conference in Toronto.
Share your knowledge. As you go through
this process you're going to learn a lot
so make your accessibility knowledge
accessible to other people that you work
with. Document it. Coding best practices,
design practices, processes, all this can
be documented. We've made a lot of
improvements over the past few years and we
use Confluence to document it. It's not
public but other companies have made
their documentation public so here's an
example from eBay called MIND Patterns.
Let me take a quick look at this, but
yeah they have a lot of their examples
like tabs. I'd recommend checking this
out. Here's an example from ours, this
one's about forms, I didn't even talk
about forms, but just to talk about this
one quickly: every form element needs a
label. Placeholder is not sufficient, it's
not going to be read out to screen
readers and also with placeholders as
soon as you start typing in them it
disappears, so if there's instructions
it's not valuable if they go away as
soon as you start typing. If you
really need to have a form input
without a label you can add a screen
reader only label at least. We also have
a Slack channel for accessibility
we call it #guild-accessibility. It's great
for asking for feedback from other
co-workers, sharing resources, and general
accessibility talk. So some some closing
thoughts: accessible patterns benefit
everybody but they're essential for
people that need them the most,
accessibility is about more than just
screen readers, and show some damn
empathy this has an effect on real
people. Thank you.
[Applause]