hi everybody uh how's everybody doing
pretty good cool cool
so my name is Trish you can also find me
at Beach on the internet and my pronouns
are she her presently I am a front-end
engineer at slack where I focus on
working with a team of amazing front-end
engineers building our internal design
system and component lower library
specifically building out react
components that comprise a foundational
layer of the slack client you know and
love so I've been working in the tech
industry a little bit over 10 years at
this point and if there is one thing I
am familiar with its failure but I'm
here to tell you that that's ok
everybody fails we fail and then we
learn and then we probably fail again in
an equally spectacular way for example
just today at lunch
I grabbed my Colby and Fried Chicken and
went by the pool to sit with Johnathan
to have food and and I realized but 10
minutes later my shorts are all wet
because I sat in a pool of water which
then of course like luckily went
upstairs changed my pants and then I
realized oh I was wearing these I wasn't
wearing these shorts because I spilled
food on them yesterday that's ok I will
learn my lesson and tomorrow I'll look
if I sit down before sitting in another
pool of water oh good I'm sure as
front-end engineers yourselves you are
all equally familiar with this feeling
of failure
everybody knows browser rendering
inconsistencies often feel like you're
in the Wild West dealing with web
compilers are kind of like a black box
of nightmares and then there's the
dreaded last step of any project
accessibility
so allow me to share a personal story of
failure has anybody here you slacked
before
cool cool okay so maybe a little bit
over a year ago I was getting ready to
launch my first big feature while
working at slack and I felt super
excited I was gonna share this new tool
with everybody here who raised their
hands a bunch of my friends a little bit
of my family and it was great great
feeling and then I got a message like
this one
so this reads hatred Congrats on the
launch by the way are you using options
list because I'm not sure if you realize
but your feature is completely
inaccessible that means I can't use it
with my screen reader so sorry to rain
on your parade love George oh it was
really hard for me not to feel like a
complete failure at this point
thankfully at SLAC I'm really proud to
say that we treat accessibility bugs as
broken functionality and product
blockers what and the web accessibility
bug means is that there's real humans
out there on the internet who cannot
interact with your website or your web
product and for slack where we have over
10 million users online daily being
unable to communicate with your
teammates interact with content or being
blocked from your doing doing your work
at all is completely unacceptable
but accessibility is by no means easy
even the queen bee herself had some
issues with this earlier this year when
she was sued over her website Beyonce
calm being inaccessible
since then the Internet has come
together to put a petition to hire one
of my amazing and talented co-workers
Mina Marcum you may have heard of her to
remedy the situation so I do hope you
will all go and sign this petition so we
can resolve this matter quickly
so I am NOT an accessibility expert but
luckily when I received this message
from Jorge on our accessibility team it
was only after an internal lunch and all
that he was letting me know was that I
had a lot more to learn and a little bit
of work to do before I could launch this
to the general public since then I have
gone through a ton of training and I've
learned a lot about the complexities of
screen readers how to test for
accessibility and how to build inclusive
experiences and that's what I want to
share with y'all today as it turns out I
am NOT an accessibility expert but you
don't need to be to do this kind of work
so let's flip the script and instead of
talking about how to fail let's talk
about how not to fail at accessibility
cool yes awesome
all right so we'll cover three main
areas today first how do you know
whether or not your website is
accessible or inaccessible to start with
secondly once you've identified some
bugs how do you go about coding to fix
those bugs and then lastly how can you
adapt your process to prevent bugs like
that from happening in the first place
okay kicking things off with testing so
what is accessibility you mean at all
it's a very broadly scoped term but it
look luckily it is thoroughly documented
if you've ever had to look up the
definition of an HTML element or a CSS
property you may be familiar with the
w3c organization not only do they have
that handy resource but they also have
what is known as the web content
accessibility guidelines or W CAG for
short so if you visit this website you
will find a very lovely text heavy
verbose document where you can learn
anything that you've ever wanted to know
about accessibility some light reading
if you will what they distill are what
feature what makes features on the web
accessible or not accessible and they
grade them based
a double-a and triple-a at SLAC we shoot
to have double-a compliance for all of
our features that we release and
wherever possible triple a compliance as
well cool so the spectrum of human
abilities and the tech that exists to
support them is infinitely broad and
while I'd love to cover everything we've
got like 20 minutes left so we're gonna
start with the hello world of
accessibility if you will so here are
some four areas that you can get started
with testing today cool first one is
color contrast the Teenage Mutant Ninja
Turtle talked earlier help preface this
so it's awesome second up is user
interface zoom then keyboard interaction
model and lastly building in screen
reader support okay so what does color
contrast mean we got a brief look at
this earlier but in general we're not
trying to analyze every single color
across your beautiful website instead
we're trying to make sure that the
information and interactive elements
that you have are understandable and
perceivable by all users and that
specifically is looking at things like
the normal text on your website large
text on your website which is 14-point
and bold and above or 18-point and above
and also interactive or user interface
elements such as iconography and form
elements there is a super handy tool
called the color contrast analyzer where
you can either input your hex values or
even just use the eyedropper tool and
it'll immediately tell you at the bottom
whether or not you're hitting those
contrast standards there are also a few
websites I think somebody mentioned one
earlier web aim where you can input the
URL of your website and it'll do a scan
to kind of check if there are any in
[Music]
areas that don't meet the guidelines it
should come as no surprise but using
light grey text on a white background
not meet accessibility standards okay
next up we have user interface zoom and
this one my coworker jokes that this is
the easiest one to test for but it's
also the easiest one for people to
forget the user interface zoom refers to
the browser's built-in functionality to
zoom into your web content using either
Apple plus minus or control plus minus
at slack our designers provide mock-ups
at all of the levels of zoom that we
support and the easiest way for you to
go about testing this is just doing that
you can take your website hit Apple plus
plus and then spend like a week using
your website like that and try to see if
you notice anything where areas feel
funky or broken next we've got keyboard
interaction model or keyboard
navigability this refers to navigating
your website entirely with a keyboard
only using the common patterns of tab
and shift tab to move backwards and
forwards through elements and then using
things like the arrow keys enter escape
and spacebar to interact with those
elements every year in May our
accessibility team hosts a challenge for
the global accessibility awareness day
where we encourage all of the employees
at slack to take our mice and put them
in the desk drawer and only use your
keyboard to navigate our products like I
tried this last year and I was really
really surprised to see what areas I was
able to make more efficient and what
areas I got stuck because I wasn't
familiar with the common patterns that
existed we also have a handy palette of
keyboard shortcuts that you can access
using command /and this is awesome
because it not only helps folks with
limited mobility but it also helps
enable to enable people to become power
users of slack so once you've got your
keyboard navigation down the guidelines
also require you to indicate what has
current focus you can tell here with the
focus ring it's like the blue fuzzy
circle that follows around where you
navigating with the tab and lastly if
you are navigating around and you notice
that you can tap into an area but you
can't tab away from it
this is what's known as a keyboard trap
and it's something that you should avoid
like this cat very sad sorry cool okay
so last but not least we're moving it to
some trickier territory and testing for
screen reader support luckily if you've
already cleaned up your keyboard
interaction model you're 50 halfway
there to making sure your website is
screen reader supported if you are using
a Mac there's software built-in to help
you test this and you can access it
through the system's preference panel
then the accessibility pane and then
enable voiceover there are also free
software options for PCs and other
platforms like NVDA ok anybody here use
a screen reader before oh it's good nice
very nice ok so let's let's listen to a
quick example of what it's like using a
screen reader so I want you to listen
along here and see if you can identify
what is happening you are currently on
web content to enter the what area press
control option shift down arrow lay like
page button leg pushing love-struck cat
face play video button you are currently
in the group to exit link pushing much
like page button link video lunar new
year duration 7 seconds public button
like like toggle button you are loved
toggle button you are currently on a
toggle button inside of a toolbar to
select or deselect this checkbox press
control option space to navigate items
on this toolbar press control option and
then up arrow power toggle button Wow
toggle button any guessin oh nice nicely
then okay so let's look at that one more
time with the visual cues for anybody
who didn't get that it was Facebook so
you'll notice that as you're navigating
the keyboard or the screen reader will
announce what has current flow
yes it'll say what is that type of
element that is being focused the
definition of it and with things like
the the like where you can choose six
different legs it'll update as you are
interacting with that element you are
currently on web content to enter the
wet area press control option shift down
arrow lay like pinch button link pushing
lovestruck cat face play video button
you are currently in the group to exit
link pushing love strike page button
link video lunar new year duration seven
seconds public button like like toggle
button you are loved toggle button you
are currently on a toggle button inside
of a toolbar to select or deselect this
checkbox press control option space to
navigate items on this toolbar press
control option and then up arrow pas
toggle button Wow
toggle button cool okay so in addition
to these basics screen readers also we
use a tool known as the rotor and this
is one of the most important reasons you
should make sure you have clean and
semantic HTML because the rotor scans
your content and that's what it uses to
populate the menus here's what it looks
like Chrome recipe Google search Google
Chrome window hope Mr P Google search
web content links menu you are currently
in a voiceover menu this is a list link
link accessibility help link XS headings
menu heading level 1 accessibility
heading level heading level 1 surf
heading left heading level petit level 3
heading level 3 easy homemade ok to now
full recipe link easy homemade recipe
just cool so you can pull up that menu
using the control was it control option
you and then left and right to navigate
between the different menu options
you'll notice that it had like one two
three and those are like h1 h2 h3 and
also that the screen reader did not know
how to pronounce po k properly it said
poke pretty sure cool alright nice job
everybody you're all on a roll so give
your neighbor a high-five and like we'll
keep on moving oh sweet
okay so the next area here is how do we
improve our code to have clean
accessible experiences there are three
broad level things that you want to
consider here first of all as I
mentioned for screen readers providing
clean semantic HTML and also proper Aria
labels is super important then you'll
get very comfortable with programmatic
focus management which everybody loves
JavaScript so hopefully easy and then
you can figure out how to leverage
modern modern coding practices to help
as well okay let's step back earlier to
that call-out from George the feature
that I was working on at the time was a
pretty common web interface pattern so
there's a box there's a list below it
you type into the box the list below it
gets filtered this is what's known as a
combo box so I want you to take a look
at the before and after I'm fixing
before and after I fix the accessibility
issue can anybody tell the difference no
not a trick is a trick question okay to
me they look exactly the same they both
still have a box for the list below it
the problem was that I when I first set
out to build it I approached it exactly
the way that it sounds so I built the
text element and then I built a list
menu element and since they are like
typographically similar there have
closed composition on the page or like
told pixels apart and they're contained
together against like a white background
box obviously they're related elements
the problem there is with my initial
assumption even though to me they were
visually distinct as separate elements
to a screen reader they do not have the
benefit of those visual cues so we were
still treating it as two separate
elements instead I needed to switch to a
completely different underlying
architecture from two components to one
component so this way using the Select
even though it also has the text input
and an options list the screenreader can
only maintain focus on one
at a time so this breeder will focus on
the select and then the internal child
components have a way of updating the
parent component to then tell the screen
reader what is happening whether
somebody is navigating up and down in
the list or if they are typing into the
box but how does that even work weird
okay
so back to that handy w3c document
they've also defined an API for
indicating to assistive technologies
what is happening on screen this is
known as Aria or accessible rich
Internet applications what's happening
behind the scenes is that this
accessibility API parses the Dom on your
website communicates that to the screen
reader or whatever assistive technology
is being used and then that information
gets output to a human on the other side
so spoiler alert but just in the same
way that browsers sometimes have trouble
rendering CSS they can also sometimes
have a little bit trouble understanding
your Aria labels this is not a huge
problem just there reminder to always be
testing thoroughly across cross platform
and cross browser as I'm sure that you
all already do okay so it's like we've
now learned to build an aria pattern
with each techSpec we write so that
before we start coding anything we
should know that the component should be
accessible from the start however as I
mentioned we're building component
libraries and since they have to support
a multitude of different use cases
sometimes doesn't look as simple and
inside it looks a little bit more like
this just make sure that you workshop
these things with your peers and that
you're covering all of your bases once
you get to the code level things start
looking a little bit more like this
where you may have a feature spread out
across a few separate components and
then you can use things like JavaScript
utilities to build and connect the IDs
that are informing your Aria attributes
okay once you have everything built out
properly here's what a combo box should
sound like when it's word filter fortune
list combo box search message actions
start the thread slack add reaction
slack app copy leg slack delete message
slack
click wool tee hey our star our message
slack start the thread slack star
message slack okay cool
so you all are on a roll thank you again
for sticking through it we got one more
section to go okay
the next section I know everybody here
oh oh okay I know everybody here loves
bugs but how do you prevent bugs from
happening in the first place I've gone a
few going over a few tips but let's step
back to what things look like it's like
a year ago when I joined there were 75
front-end engineers but there was only
one accessibility expert as I mentioned
I am NOT that expert we have the famed
Todd Kurtz who is incredibly talented
and amazing to work with
but even so one engineer is not enough
to support all the accessibility
features we want to include so over the
past year we've rolled out training
similar to this one to ensure all
front-end engineers at slack understand
the accessibility criteria that we are
shooting for and how to build and test
for it more importantly that means that
since we all have this understanding
when we're reviewing each other's code
reviews and code and pull requests that
we know how to test accessibility for
everybody else those features too we've
taken it one step further and we also
ensure that our designers know what
accessibility is and isn't and they
provide things like the keyboard
interaction model for us so we can then
build it out we haven't are using our
internal design system has helped
formalize a lot of best practices so
over the last year we've also conducted
a color audit to simplify and ensure
that our smaller new set of colors meets
all of our contrast standards we've also
set up things like linters to prevent
folks from adding one-off colors this is
just one of the steps that we've taken
to help prepare for one of the most
requested features of slack dark mode so
that once it does roll out
we can ensure that it'll still be fully
accessible so having front Enders use a
centralized component library that is
accessible by default is awesome we
currently use these components and
nearly 75% of applicable areas of our
code base and we're trying to increase
that steadily but the single most useful
thing I've learned is that you need to
consider accessibility as early on in
the process as possible because it's
easier to add the blueberries in before
you bake muffin somebody once said we
also have a dedicated QA team to run
throw checks before we launch a feature
and also you to utilize a third-party
service called Ultra who conduct an
audit as well so even if you don't have
the benefit of a component library or
design system or QA team and you're so
loads of working by yourself
hopefully this starter kit is enough to
get you learning to become your own
resident expert awesome so nice job
everybody you've learned a ton and I
know that you're gonna apply all these
best practices once you're back in the
real world but I want you all to stop
for a minute and think about how you got
to where you're sitting here today in a
conference room in Hawaii
maybe you first heard about this
conference on Twitter and you thought it
sounded cool so you navigated onto their
website you really liked the lineup and
the idea of learning JavaScript on a
beach so of course we bought a ticket
then you went on to buy a cheapest plane
ticket possible to get yourself here and
of course you asked all your friends for
the best food recommendations so you
knew where to go for pookay and local
moco once you were on the island a
recent study in the UK found that nearly
70 percent of their web sites were
inaccessible so I want you to think
about all these websites you've touched
along the way just in one day and
imagine that every time you want to fill
out a form or even just browse and read
content you were hit with a javascript
error I've always found it
interesting that other engineering
professions have a lot more strict
certifications that they have to undergo
so think about civil engineers need to
be tested before they can build bridges
and buildings to make sure that they're
safe for humans and while I do not want
this type of gatekeeping behavior in our
industry I do want us to hold ourselves
and each other more accountable to make
sure that we are responsible with our
code and that we are building an
internet that is safe for other humans
to use to I hope that this is something
that you remember once you're all back
and you have a p.m. breathing down your
neck about an upcoming deadline your
peers are trusting your expertise in all
things front end and that includes
knowing that for to have a complete web
project it has to be accessible even
though it takes a little bit more time
upfront it'll save you infinitely long
in the long run it's become more and
more apparent that there are no average
users this is a myth instead we should
be designing for the extremes of human
ability much like everything else and
especially with Emily's talk earlier
prioritizing inclusivity and designing
for the most marginalized groups
actually makes a better experience for
everyone
I there are countless examples of this
too I'm not sure the last time you
enjoyed a video that had closed
captioning or if you enjoy text
messaging or any voice-activated
software all of these have their roots
in assistive technology so I hope you'll
take this as a sign that you too can
build for accessibility even if you're
not an expert and if you want to get
stuck along the way or if you just want
to tell me about your favorite
accessibility bug you can find me at
fish on the internet or come find me
after the talk or if you want to come
work it slack and build component
library things more than happy to hear
about it thank you all for having me
thank you for the organizers for
bringing us all here to cool look
you
[Applause]