►
Description
Scaling Accessibility in the Age of Components - Ayesha Mazumdar, Optimizely
Speakers: Ayesha Mazumdar
We often build component libraries to improve consistency, collaboration, and customization for a given product. But what if a component library could also scale accessibility across the entire organization? Building accessible components can help distribute responsibility across all of design and engineering, without needing everyone to be an expert on the nitty-gritty details. In this session, we'll go through specific component examples and use cases to help you and your team contribute to a better, more inclusive web.
A
I
actually
hit
12
o'clock,
and
everyone
hear
me,
although
in
the
back
yay
awesome,
thank
you
all
for
joining
I
hope,
you're
having
a
lovely
time
in
Montreal
I'm
super
excited
to
be
here.
Today's
talk
will
be
covering
scaling
accessibility
in
the
age
of
components.
Who
here
knows
what
accessibility
already
means
awesome
by
the
end
of
this?
Hopefully,
everyone
will
be
able
to
raise
their
hand,
so
I'm
Aisha
I
currently
work
as
a
senior
UX
engineer
at
Optimizely,
which
is
an
experimentation
software
company.
A
Some
of
you
might
use
it
familiar
with
it
before
that
I
was
working
on
the
Lightning
design
system
at
Salesforce.
Most
importantly,
I
am
dog,
mom
pepper,
there's
a
picture
at
the
end.
If
you
can
stick
it
out
and
I'm
also
a
proud
musical
theater,
geek
I
spent
a
lot
of
time
on
stage
singing
and
dancing
and
I
joke
that
this
is
my
new
way
of
getting
on
stage,
even
though
I
work
in
tech.
A
So
my
job
as
the
UX
engineer,
Optimizely
generally
covers
four
main
areas.
The
first
one
is
our
component
library.
It's
called.
Oh
you
I
stands
for
Optimizely
UI
if
you're
French,
it
just
looks
like
wheat.
We
also
have
a
design
system.
The
component
library
is
obviously
part
of
that.
It
also
includes
lots
of
documentation
on
how
to
use
the
different
components
and
one
to
you
something
over.
Another
also
includes
accessibility
guidelines
and
our
color
tokens.
I
spend
part
of
my
job
working
on
that
design
system.
A
I
also
do
a
lot
of
prototyping,
so
I
partner
with
our
PMS
and
our
designers
whenever
they
have
something
either
new
or
updated
that
they
want
to
test
with
customers.
I
work
with
them
to
create
a
prototyping
code.
Typically
HTML
CSS
react
that
they
can
use
and
put
in
front
of
customers
before
we
start
building
I,
also
every
now
and
then
get
my
hands
dirty
in
the
front-end
code
base.
A
So
I'll
make
some
UI
UX
updates,
especially
if
they're
updates
that
need
to
be
made
because
a
component
was
updated,
but
throughout
all
this
work,
the
underlying
part
is
really
the
component
library,
so
I
use
this
day-to-day.
A
lot
of
our
engineers
also
use
it
day-to-day.
Our
hope
right
is
that
everyone
is
using
it,
but
the
other
key
part
is
also
accessibility.
A
A
So
we'll
look
at
button
icon
and
how
this
can
improve
the
visuals
of
your
application,
especially
contrast
look
at
inputs
and
what
this
means
for
screen.
Readers
we'll
get
into
a
little
bit
more
later
and
a
select
drop-down,
a
custom,
select
drop-down
and
how
you
need
to
do
work
for
the
keyboard
navigation
part
of
that,
but
before
we
get
started
for
those
of
you
who
didn't
raise
your
hand,
I
just
want
to
make
sure
we're
all
on
the
same
page
about
what
accessibility
entails.
A
So
the
way
I
like
to
describe
it
is
that
I
ensure
everyone,
no
matter
their
ability
can
perceive
understand,
navigate,
contribute
to
and
interact
with
an
application.
Basically,
anything
one
person
can
do.
Another
person
can
do
doesn't
matter
their
ability,
it's
also
commonly
referred
to
as
a
1:1.
Why?
Because
accessibility
is
kind
of
a
hard
word
to
spell
I
appreciate
that
abbreviation
it's
a
1:1.
Why?
A
Because
there
are
11
letters
between
the
a
and
the
lion
now
who
benefits
from
accessible
and
assistive
technology
a
lot
of
times,
I
think
when
we
first
think
about
this,
we
just
think
of
the
permanent
column,
people
who
are
deaf
or
blind
trying
to
use
an
application.
However,
the
Microsoft
team-
they
have
amazing
accessibility
to
and
they've
created
these
inclusive
design,
personas.
A
Right,
you
may
be
blind
from
birth,
in
which
case
you
might
use
a
screen
reader
to
interact
with
technology,
or
you
might
have
had
eye
surgery,
and
suddenly
you
only
have
one
eye
at
the
moment.
You
want
the
other
ones
covered
by
an
eye
patch.
You
might
also
benefit
from
assistive
technology.
Ideally
you
probably
benefit
from
at
least
good
contrast,
so
that
even
with
your
one
eye
and
it's
compensating,
you
can
still
perceive
everything
on
an
application
or
it
might
be
situational.
A
Anyone
here
ever
tried
to
work
outside
in
the
Sun
and
if
a
certain
page
has
pretty
low
contrast
ratios,
it
can
be
really
hard
to
see
some
of
the
items
on
the
page
or
on
the
projector
right.
Is
everyone
ever
done?
The
projector
test,
where
it
looks
fine
on
your
computer
and
you
put
it
up
on
the
projector
and
suddenly
everything's
washed
out
by
improving
contrast
ratios,
we
can
make
sure
everyone
gets
to
benefit.
A
Secondly,
component
libraries:
they
are
an
amazing
tool
because
every
change
you
make
to
a
component
as
long
as
your
developers
are
using
those
components
that
change
gets
permeated
throughout
the
entire
ecosystem.
Right
you
can
make
one
change:
I
can
make
one
accessibility
fix
and
suddenly
everyone
consuming.
That
component
also
gets
that
fix
super
handy,
it's
an
ideal
world
to
live
in,
but
it
also
means
that
every
change
gets
permeated
throughout
the
entire
ecosystem.
So
you
can
also
introduce
a
bug
and
suddenly
everyone
consuming
that
component
gets
that
bug
bugs
typically
get
caught
with
tests.
A
What
might
not
get
caught
is
an
accessibility
bug
or
a
accessibility
issue
right
if
I
make
a
change
in
a
component
that
deters
the
accessibility.
The
unfortunate
part
of
component
libraries
is
that
everyone
else
consuming
that
component
is
suddenly
inaccessible
as
well,
but
with
great
power
comes
great
responsibility
and
an
endless
opportunity
to
make
the
web
more
accessible
place.
So
if
you
have
any
influence
over
a
component
library,
you
have
a
chance
to
scale
the
accessibility
throughout
your
application,
just
by
making
a
few
changes
to
the
underlying
components.
So
that's
what
we'll
dive
into
today.
A
Who
is
familiar
with
this
beautiful
fuzzy
blue
outline
that
the
browser's
have
introduced
all
buttons
and
links
right?
Browser
default
has
some
kind
of
focus
ring,
but
a
lot
of
people
call
it
it's
not
the
prettiest.
Sometimes
it's
a
little
bit
overwhelming
or
obnoxious.
It's
also
always
a
certain
color,
so
it
might
not
fit
your
brand.
So
how
many
people
are
familiar
with
this
bit
of
code?
Yeah
I've
done
this
I've
done
the
button
reset
to
outline:none
I'm
sure
plenty
of
people
in
this
room
have
also
done
it.
It's
no
ill
intent
right.
A
It's
just
that.
We
want
to
have
a
better
solution.
The
problem
is:
if
we
remove
this,
we
need
to
add
something
back
right.
We
can't
just
take
this
away
and
say
all
right,
we're
great
all
good.
We
don't
have
the
ugly
blue
outlines
anymore,
because
now
we've
introduced
a
huge
accessibility
problem.
Funny
thing
is
that
this
was
baked
in
right.
This
was
done
for
us
and
the
browser's,
and
now
we're
overriding
it.
A
The
fun
secret
is
that
this
is
not
the
same
button
four
times.
This
is
actually
a
in
four
different
states:
very
different
states.
The
neutral
the
hover
state
focused
and
focused
in
hovered.
Now,
I,
don't
know
about
you.
I
can't
tell
a
difference
between
any
of
these
I
had
a
really
hard
time
keeping
the
screenshots
apart
when
I
was
trying
to
do
this
slide,
I
had
to
remember
which
order
I
had
done
the
screenshots
and
because
they
they
don't
look
any
different.
A
There
is
technically
a
color
change
for
the
hovers,
but
it's
practically
missing
now,
with
a
few
fixes,
I've
darkened
the
difference
between
neutral
and
hovers,
so
the
hover
token
is
now
using
a
shade,
a
couple
shades
darker
from
our
design
tokens
and
instead
of
the
outline
I've
added
a
box
shadow
for
the
focus
state.
Now
these
at
least
aren't
starting
to
look
a
little
bit
different.
We
could
go
further,
but
this
is
a
good
starting
point.
A
If
I'm
looking
at
this
I
can
definitely
see
the
difference
between
neutral
and
focus,
which
is
a
huge
improvement
and
there's
a
discernible
difference
between
when
I'm
hovering
and
when
I'm
not
easy
fix.
This
reminder,
if
you
take
off
the
outline,
you
need
to
put
something
back
in
in
its
place.
Otherwise,
people
trying
to
use
the
nav
the
application
with
keyboard
navigation
will
lose
track
of
where
their
focus
is,
if
they
don't
have
a
clear
way
to
know
exactly
which
element
is
currently
being
focused
so
the
next
bit.
A
This
was
our
button
icon
component,
it's
pretty
straightforward.
You
passed
an
icon
name,
we
automatically
filled
it
with
one
of
our
dark
purple,
color
tokens,
but
we
got
a
request
for
some
more
customized
ability,
and
so
we
added
a
prop
called
icon
fill
its
initial
start
was
just
a
string
prop
type
you
could
pass
in
any
hex
value.
It
would
update
the
fill
of
the
SVG
used
in
this
button
icon.
This
is
great.
It
gives
people
a
lot
of
chance
for
customization
people
are
very
happy
right.
A
They
can
put
any
color,
they
want
the
problem
is
they
can
put
any
color.
They
want
and
there's
no
way
to
know
that
a
certain
developer
has
done
the
due
diligence
to
make
sure
that
this
color
would
pass
a
contrast.
Ratio
against
white.
You
can
see
my
favorite
go
to
ABC.
Abc
does
not
by
any
means
past
a
contrast
ratio
against
a
white
background.
So
how
do
we
improve
this?
How
do
we
prevent
the
onus
being
on
developers
to
know
exactly
which
color
would
be
a
good
choice?
A
We
created
a
little
utility
that
looks
like
all
of
our
color
tokens
that
we
export.
We
behind
the
scenes
do
the
test
to
make
sure
that
each
of
these
color
tokens
passes
the
contrast
ratio
against
a
white
background,
and
now
our
updated
prop
type
no
longer
takes
any
arbitrary
string.
It
points
to
this
map
and
it
says
you
have
to
pick
one
of
these
colors.
We
also
change
the
token
names
a
little
bit
to
be
a
little
bit
more
human-friendly,
so
you
don't
remember,
base
or
blue
dark.
We
just
say
default,
aqua,
green
orange.
A
So
now
as
a
developer,
you
have
to
pick
between
one
of
these
nine
choices.
I
see
a
little
seem
a
little
limiting,
but
in
reality
this
is
actually
a
benefit
for
the
designers
as
well
and
the
aesthetic
of
the
entire
application,
because
now
we
know
all
of
our
colors
are
actually
being
pulled
from
our
official
brand
tokens
right
now.
Our
application
is
going
to
look
a
lot
more
consistent
throughout
all
of
our
button
icons.
A
A
Lastly,
titles
I
use
these
a
lot,
especially
in
something
like
the
S
code
that
has
a
lot
of
button
icons
and
you're,
trying
to
figure
out
what
all
those
different
icons
do
you
hover
over
it
and
the
little
tooltip
pops
up
and
tells
you
ideally
what
this
button
does
now.
This
title
is
also
used
for
screen
readers.
So
if
someone
is
navigating
something
with
a
screen
reader,
this
title
is
used
to
tell
them
what
the
button
they're
currently
on
is
going
to
do.
A
The
code
underneath
might
look
something
like
this:
if
person
passes
in
a
prop
stunt
title
we'll
set
that
title
attribute
on
the
button
itself
now,
the
key
here
is
not
making
this
optional
we're
using
the
is
required
attribute
of
the
prop
types
to
ensure
that
everyone
who
is
using
a
button
icon
is
adding
this
title.
That
way,
that's
at
least
one
small
Sandi
check.
We
can
make
to
ensure
that
everyone's
got
a
title
on
their
bat
and
icons.
Quality
of
the
title
is
up
to
the
developer.
A
That's
where
design
system
Doc's
come
in
handy
right,
you
can
say:
okay,
this
shouldn't
describe
the
icon,
like
it
shouldn't
be
paperclip.
It
should
be
attach
a
file,
something
like
that,
but
that's
where
a
component
library
in
a
design
system,
work,
hand
in
hand
now
button
icons
are
surprisingly
quite
tricky.
Unfortunately,
screen
readers
don't
have
a
standard
way
of
handling
the
title
attribute.
You
can't
guarantee
that
that's
going
to
work
on
a
screen
reader,
so
there
are
a
lot
of
different
options:
I
like
using
Aria
label.
A
So
that
might
look
something
like
this:
I
don't
want
to
require
users
to
pass
yet
another
crop
plus.
If
I
had
a
separate
prop
for
Aria
label
and
title
they
might
get
out
of
sync,
they
might
be
different.
I
don't
need
that
I
can
just
use
the
same
title
prop
for
the
Aria
label
and
the
same
way
it'll
be
passed
on
to
the
component.
A
A
A
It
doesn't
semantically
make
sense
to
have
a
label
without
any
Associated
input,
so
here
label
is
being
used
for
its
style
and
not
for
its
semantic,
meaning,
which
has
a
really
big
accessibility
issue.
We
want
to
make
sure
that
the
components
were
using
the
underlying
HTML
elements,
especially
are
used
appropriately
and
they
apply
in
an
appropriate
situation
versus
this,
where
they're
being
used
just
for
stylistic
differences.
A
A
What
that
means
is
if
I
turn
on
a
screen.
Reader
and
I
go
to
this
input.
It's
just
going
to
read
edit
text
blank.
If
I'm
a
screen,
reader,
user
and
I
can't
see
this
I
have
no
idea
what
input
I'm
suddenly
found
myself
in
it
could
be
a
phone
number.
It
could
be
a
password.
There's
no
clue
to
me
as
a
user,
to
know
what
I'm
supposed
to
be
typing
here.
A
If
we
look
at
the
underlying
code
behind
this
issue,
we
start
to
see
the
problem.
This
code
was
relying
on
developers
passing
in
a
label
property
in
order
to
properly
apply
an
actual
label
element,
but
if
they
didn't
pass
in
this
label,
all
we
got
was
an
element
of
an
input.
There
was
no
Associated
label
for
this
input.
A
So
a
few
quick
changes
for
our
input
component.
We
require
an
ID
and
we
require
a
label.
Now.
What
this
means
is
that
in
our
code,
we
no
longer
have
an
if
statement
right.
We
know
a
label
has
been
passed
and
we
say:
okay
use
the
label
component.
This
is
the
inputs
ID.
This
is
the
labels
text
and
render
the
competi
it
put.
What
that
looks
like
further
down
is
that
the
label
is
properly
using
a
four
attribute
that
points
to
the
inputs,
ID
and
the
input
has
that
same
ID.
A
So
this
match
this
four
and
the
ID
attribute
those
two
matching
and
having
the
exact
same
string,
it
is
case-sensitive
means
that
now
my
label
is
properly
associated
with
my
input.
So
if
I
were
using
a
screen
reader,
it
would
say
something
like
edit
name
next
now
a
fun
way
to
test
this
without
going
all
the
way
into
a
screen
reader.
Yet
you
have
to
do
that
part,
but
if
you
want
to
do
a
quick
sanity
check,
you
actually
click
on
the
label
of
any
input,
and
it
should
automatically
focus
you
in
the
input.
A
If
it
doesn't,
that
means
the
two
are
not
properly
connected.
This
also
works
for
checkboxes
and
radio
buttons.
If
you
ever
click
on
the
actual
text,
like
the
read
terms
and
conditions,
you
click
on
that
it
should
be
checking
the
checkbox
and
they
do
that,
because
the
checkbox
is
a
very
small
tap
target
right,
if
you
maybe
are
not
the
best
Mouse
user,
for
whatever
reason,
it
can
be
very
hard
to
be
very
particular
about
where
you're
clicking
by
making
the
label
an
access
point
for
that
checkbox,
you
make
it
a
lot
easier
for
you.
A
This
is.
It
was
just
a
quick
way
to
ensure
that
those
two
attributes
have
been
connected
properly.
The
last
change
we
made
was
actually
removing
our
exported
label
component
right.
We
no
longer
want
people
using
this
willy-nilly.
We
know
it's
associated
with
inputs,
so
it's
going
to
be
used
underneath
the
surface.
The
input
component
developers
never
have
to
worry
about
it.
A
Last
section
keyboard
navigation:
anything
you
can
do
with
the
mouse
I
can
do
with
the
keyboard.
Vice
versa,
right
I
shouldn't
need
to
use
my
mouse
in
order
to
use
a
patient
so
many
times
we
create
customized
select
dropdowns.
So
there
is
a
native
select
element
that
uses
option
children.
This
gives
you
kind
of
a
default
look.
Sometimes
you
need
to
go
beyond
that.
You
should
have
a
very
good
use
case
for
going
beyond
that.
A
You'll
see
why
in
a
second,
but
if
we
are
creating
our
custom
select
drop-down,
there
are
a
few
things
we
need
to
do
to
the
markup
to
make
sure
it
works
for
both
keyboard
navigation
and
screen
readers,
for
example,
the
trigger
needs.
An
aria
has
pop-up
to
true,
and
are
you
expanded
to
true
or
false
whether
or
not
the
drop-down
is
showing
or
not?
A
The
containers
surrounding
the
options
should
have
a
roll
of
menu,
and
each
item
should
have
a
role
of
either
menu
item
or
placeholder.
Placeholder
is
used
like
if
you
have
a
heading
for
a
certain
number
of
options,
and
then
you
have
another
heading,
those
headings
would
be
placeholders.
We
also
set
tabindex
equal
to
negative
1
so
that
we
can
programmatically
focus
on
these
items
without
introducing
them
into
the
tab
series,
so
you
shouldn't
be
able
to
get
to
them
with
a
keyboard,
but
this
lets
us
give
a
kind
of
foe
focused
state.
If
you
will.
A
This
is
an
example
of
all
the
extra
markup
you
need
to
add,
and
then
we
have
to
go
a
step
further.
Now,
when
you
interact
with
a
select
drop-down,
especially
the
native
one,
you
can
trigger
the
drop
down
to
show
by
hitting
Enter
or
space,
and
then
you
can
use
your
up
and
down
arrows
to
go
through
the
different
options
and
then
hit
enter
to
select
something.
Now
all
of
that
is
given
to
you
by
default
at
lebackes
for
free.
A
A
You
need
to
be
checking
the
different
keys
being
pressed
and
see
if
it's
something
that
you
need
to
react
to,
if
I'm,
hitting
the
up
or
down
key
I'm
going
to
stylistically,
maybe
add
a
class
that
helps
the
user
know.
Okay,
where
is
my
focus
which
one
am
I
currently
on
in
a
sense
Fame
for
escape
if
I
hit
the
escape
key
I
expect
the
drop-down
to
disappear.
This
all
stuff.
You
have
to
wire
up
yourself
if
you're
going
to
roll
your
own
Fleck
drop-down.
A
So
this
is
my
plea
to
you
all
to
use
a
semantic
element
if
it's
present
and
if
you
don't
need
to
build
custom
things,
then
don't
because
it's
definitely
a
lot
more
work.
So,
given
all
of
this,
what
is
the
big
picture?
These
were
just
a
certain
set
of
components
that
I
chose
to
talk
about.
We
have
about
54,
maybe
almost
16,
now
components
and
oh
you
eye
there's
a
lot
of
different
things.
A
So
my
number
one
tip
is
start
with
your
most
ease
components
when
I
first
started
that
Optimizely
I
was
looking
at
this
list
of
about
60
components
and
wondering
okay.
All
of
these
need
accessibility,
help.
Where
do
I
start,
and
my
takeaway
was:
let's
look
at.
What's
the
most
used
interface
right,
we
use
button
icons
all
over
the
place.
Many
applications
do
because
they
are
a
great
space
saver,
especially
if
you're
doing
editor
type
stuff,
taking
up
full-length
buttons
with
text
every
time
might
not
be
an
option.
A
So
a
lot
of
times
we
rely
on
button
icons.
Those
are
very
prevalent
in
prevalent
in
the
Optimizely
UI
same
for
inputs.
Probably
very
common.
Ours
is
very
forum
based.
There
are
a
ton
of
inputs
that
you
fill
out
on
a
regular
basis
if
those
inputs
aren't
accessible,
it's
very
hard
to
complete
a
standard,
workflow
and
Optimizely
and
same
for
select
dropdowns.
A
We
have
custom
select,
dropdowns,
especially
ones
that
we
use
for
setting
your
project
type
or
navigating
and
trying
to
take
any
basic
workflow
with
just
your
keyboard
was
very
hard
because
our
select
dropdowns
have
no
way
of
being
keyboard
accessible.
So
you
never
had
a
way
to
choose
your
next
thing,
so
you're
basically
blocked
you
were
stuck.
So
my
recommendation
is
look
at
what
is
in
your
UI
most
often
and
see
what
gives
you
the
most
win
for
fixing.
A
Second,
make
it
easier
to
do
the
right
thing.
So,
as
we
saw
with
button
icons,
we
can
take
the
pressure
off
of
our
developers
and
move
it
on
to
the
component
itself.
Do
they
need
to
worry
about
whether
or
not
a
color
is
passing
the
contrast
ratio
against
white?
They
shouldn't
have
to
right.
They
should
just
be
able
to
say:
okay,
I
need.
This
is
green,
because
it's
representing
something
maybe
successful,
I'm
going
to
use
the
green
fill
right.
A
Some
things
shouldn't
be
flexible.
Like
inputs
right,
we
don't
want
the
flexibility
of
people
using
labels
wherever
they
want.
We
need
to
control
some
things
in
order
to
ensure
that
we
are
keeping
accessibility
top
of
mind.
This
is
also
a
great
learning
opportunity.
If
people
start
asking
you
well,
why
don't
we
have
a
label
component?
You
can
explain
to
them.
They
can
learn
that
Oh
labels
are
always
associated
with
inputs,
so
we've
baked
it
in
making
that
property.
The
label
property
required
is
also
a
great
learning
moment.
A
If
people
start
wondering
oh,
why
is
this
label
required?
They
might
go,
look
into
the
code
and
see
what
it's
being
used
for
and,
lastly,
good
things
take
time
and
effort.
Great
life
advice,
really
it's
not
just
for
components,
but
as
I
was
looking
at
a
huge
list
of
components
that
needs
to
be
updated,
I
recommend
tracking
it
against
effort
and
impact
right.
How
much
impact
is
this
going
to
have,
and
how
long
is
it
going
to
take?
How
much
effort
is
it
going
to
take
to
fix
it?
A
Some
things
might
be
huge
impact
and
very
low
effort,
like
the
button.
Icons
I
think
that's
a
very
large
impact
across
our
application,
because
it's
used
so
often,
but
it
was
a
few
lines
that
fixing
right,
pretty
simple
versus,
select
drop
down,
select
drop
down
also
has
a
huge
amount
of
impact
because
it's
used
so
often,
but
it's
also
a
lot
more
work
to
make
it
simple.
So,
by
kind
of
plotting
these
different
components,
you
can
get
a
sense
of
okay.
This
is
where
I
start.
A
Hopefully,
by
intentionally
creating
these
accessible
components,
you
can
start
to
see
the
impact
across
your
organization,
even
if
it's
not
immediate,
just
by
giving
somewhat
similar
presentations
to
this
I've
had
developers
come
up
to
me
whenever
they
are
creating
new
UI
components
and
start
asking
me,
you
know
what
do
I
need
to
do
for
accessibility.
Is
this
accessible?
How
do
I
test
this?
What's
the
expected
keyboard
interaction?
A
This
is
a
great
way
to
ensure
that
you
are
truly
meeting
all
the
requirements
and
making
it
an
enjoyable
experience
for
someone
who
relies
on
a
screen
reader.
The
a11y
project
is
a
site
you
can
go
to.
Has
an
amazing
checklist.
I've
covered
a
few
things
off
of
their
checklist,
having
gone
into
full
depth
just
for
the
sake
of
time,
so
I
highly
recommend
checking
that
out
and
reading
over
and
learning
what
it
means
to
be
accessible.
A
A
Airbnb
is
react,
dates
is
what
we
ended
up
using
when
we
needed
to
build
a
date
picker,
because
the
last
thing
you
want
to
do
is
try
to
make
that
picker
keyboard
accessible,
there's
a
lot
to
it
and
screen
reader
usable,
so
many
different
things
you
have
to
take
into
account.
It
is
not
worth
trying
to
do
that
yourself,
so
if
there
is
something
out
there
that
you
can
use
start
there,
the
very
first
starting
point
should
be
the
semantic
HTML
elements
that
already
exist
and
then
go
from
there.