►
Description
Designing Accessibility for Other Developers- Sarah Higley, SitePen
The moment you step into any large project or open source venture you must accept that code you write will be used in ways you did not originally intend. Part of creating any good UI library is figuring out how to design it to be flexible enough to suit a range of needs while still baking in best practices. This is especially relevant in the case of accessibility: an area that can be crucial to users but is often overlooked.
Take a journey through an office full of all the developers you never hoped to work with, but will encounter nonetheless: the caveman coder, a contractor here to smash your code until it “works”; the blunderer, a dev who always knows just enough to break your builds; the horde of interns, hired last week to “help”; and finally the inventor: the “let’s just roll our own” developer who will abandon your library if it doesn’t support a host of custom features, plus a pony. Then find out how to hint, nudge, and wrangle them into coding accessible UI components for the good of the web.
Sarah Higley
JavaScript Developer, SitePen
Sarah Higley is a JavaScript developer at SitePen, currently working on developing widgets for the Dojo 2 web framework. She started working on web accessibility in 2014, and now spends an unhealthy amount of time reading about WCAG updates.
A
So
before
I
begin,
I
just
like
to
acknowledge
that
I'm
speaking
to
you
on
the
unceded
territory
of
the
Coast
Salish
people,
including
the
territories
of
the
Musqueam
Squamish
and
slay,
with
teeth,
nations
and
I'm
here
to
talk
about
accessibility,
specifically,
accessibility
in
building
component
libraries-
and
hopefully
that's
that's
what
you
came
here
for
it's
not
there's
still
time
the
reason
that
is
not
working
just
working
a
second
ago,
yes,
okay.
The
reason
that
I'm
here
to
talk
to
you
about
this
is
that
I
contribute
to
the
dojo
web
framework
and
specifically
its
widgets
library.
A
So
it
spent
a
lot
of
time
thinking
about
how
to
design
components
for
other
developers
to
use,
because
it's
an
open
source
framework,
so
anyone
could
use
it
and
I'm
not
going
to
specifically
talk
about
dojo
as
a
framework.
This
is
completely
framework
independent.
You
can
use
this
to
go
and
make
a
pattern.
Library,
that's
internal
or
angular,
react
web
components
whatever,
but
that's
what
I
do
and
that's
kind
of
what
I
think
about
and
where
I
come
from,
so
designing
accessibility
for
other
developers.
A
Usually,
when
people
talk
about
accessibility,
they
talk
about
the
user
experience,
how
people
who
are
blind
or
deaf
or
have
motor
disability-
or
you
know
any
other
like
none
or
technical
approach,
or
anything
like
that
interact
with
your
technology.
But
this
is
specifically
trying
to
create
code
that
other
developers
will
then
turn
into
an
app
that
then,
hopefully,
users
will
be
able
to
use
any
user
will
be
able
to
use.
A
I'm
going
to
take
a
brief
detour
to
Ed
Roberts
and
the
rolling
quads
that
UC
Berkeley,
who
are
pictured
here
so
ed
Roberts,
is
this
activist
who
was
at
UC
Berkeley
a
student
there,
a
polio
survivor
and
he
used
a
wheelchair
in
the
60s,
and
he
has
this
story
about
one
about
dating
this
girl.
He
liked
this
girl.
He
liked
it.
A
He
who
was
dating
her
and
he
had
to
have
someone
with
him
to
help
him
get
his
wheelchair
up
and
down
curbs
stairs
and
other
physical
barriers,
and
he
and
the
rolling
quads
would
there's
this
kind
of
apocryphal
story.
I
think
it
was
actually
true,
but
they
would
go
out
at
night
and
build
curb
cuts
with
bags
of
cement
into
the
sidewalks
and
kind
of
more
effectively.
A
They
also
petitioned
the
city
and
they
eventually
created
actual
curb
cuts,
but
what
this
meant
for
him
was
that
he
could
go
on
a
date
with
his
girlfriend
on
his
own
without
somebody
there
to
help
him
and
that's
what
accessibility
really
is
it's
it's
not
some
abstract
like
feature:
it's
not
a
check
box.
It's
on
the
Internet,
we're
building
actual
public
spaces.
More
and
more
that
are
more
integral
to
public
life
and
making
them
accessible
means
in
a
really
real
way.
A
Making
this
online
shared
public
space
that
we
all
create
a
place
where
everyone
can
access
it,
everyone
could
access
it
in
privacy
without
somebody
else,
you
know
having
to
type
in
their
credit
card
info
for
them,
because
they
can't
find
your
input
where
everyone
can
participate
and
where
you
know
just
like
curb
cuts
in
60s
and
70s,
where
everyone
can
come
and
share
and
there's
this
other
side
benefit.
And
this
phrase
the
curb
cut
effect
which
comes
from
the
disability,
rights,
community,
vism
and
disability
rights.
A
Community
I,
really
love,
and
it
refers
to
when
a
small
group
of
people
need
certain
affordances
and
champion
them
and
push
them
into
getting
adopted.
And
then
those
affordances,
like
curb,
cuts,
end
up
benefiting
everyone.
So
if
you've
ever
had
to
push
a
stroller
or
like
a
suitcase
or
maybe
like
a
moving
trolley
around
a
city,
then
you
have
probably
used
a
curb
cut
and
been
really
happy
that
it's
there
and
similar
to
that
similar
to
curb
cuts
benefiting
everyone.
A
Things
like
audio
captions
that
were
championed
by
the
deaf
community
now
help
you
watch
sports
in
a
bar,
or
you
know,
watch
Instagram
videos
in
a
public
space
without
your
headphones
or
see
Twitter
videos.
It
also
helps
second
language
learners,
who
also
benefit
from
seeing
tax
as
well
as
hearing
it.
People
who
absorb
information
better
by
reading
than
by
hearing
all
sorts
of
these
kind
of
unintended
but
beneficial
side
effects
high
contrast
mode.
Some
people
need
it,
I
find
it
easier
on
the
eyes,
distraction,
fee,
free
features.
A
If
you
have
ADHD,
maybe
that's
you
know
really
necessary
to
be
able
to
concentrate
on
something
for
a
long
time,
but
it's
nice
for
everyone,
and
so
when
you
leave
here
today,
I
want
you
to
spend
at
least
a
little
bit
of
time.
Considering
what
the
unintended
beneficial
side
effects
will
be
of
an
accessible
Semantic
Web.
What
tools
could
you
build?
A
What
could
you
make
if
you
could
trust
that
any
webpage
you
went
to
was
semantically
laid
out
that
you
could
parse
it
with
a
computer
that
you
could
read
it
programmatically
and
predictably,
and
that
you
could
trust
that
it
would
do
so
and
that
you
could
do
so?
What
could
you
build
so
hopefully
you're
convinced
about
accessibility,
at
least
so?
Why
a
pattern?
Library?
Why
build
a
pattern?
A
Library
where
you
could
just
build
an
app
that
someone
will
use
and
for
that
I'd
like
you
to
introduce
you
to
your
fellow
developers
who
are
helping
build
the
web?
If
you
don't
work
with
any
of
them
now,
I'm
sure
you've
met
them
or
worked
with
them
in
the
past
there
is
the
caveman
coder
who
is
here
to
just
just
just
smash
code
until
it
works
or
it
works.
There's
the
Horde
of
interns
they're,
definitely
here
to
help
and
there's
the
inventor
who
just
wants
to
roll
his
own.
A
We've
all
been
new
to
something
I've,
certainly
been
new
to
things,
whether
it's
a
library
or
coding
in
general
or
accessibility
or
a
framework
or
whatever
and
I'm
sure.
All
of
you
that
in
the
position
where
you
your
framework,
whatever
like
thing
you're
using
whatever
code
base
you're
using,
doesn't
handle
all
the
features
you
need,
and
you
want
to
just
you
know,
build
your
own,
it's
easier
than
working
with
what
you
have
so
when
you're
in
that
situation,
when
you're
building
for
the
people
in
those
situations,
what
do
you
do
and
to
talk
about
it?
A
I'm
going
to
start
with
what
is
probably
the
most
simple
bucket
for
user
interaction
that
exists,
which
is
a
button?
It's
so
simple.
No
one
could
get
it
wrong
right.
So
to
add
a
little
interest.
I
threw
an
icon
in
there.
I
see
this
all
the
time.
It's
a
super
common
pattern.
So
since,
since
we
see
it
all
the
time,
let's
look
at
what
that
looks
like
under
the
hood.
This
is
a
download
button
from
a
pretty
popular
code
sharing
site
that
will
remain
nameless.
A
It
is
if
you
can't
see
the
code
it's
using
a
button
element
which
is
good,
it's
discoverable
by
keyboard.
It
has
a
click
event
which
is
also
operable
by
keyboard
because
it's
a
button
element,
but
then
it
has.
This
custom
attribute
a
tooltip,
and
that
has
says
download
as
a
zip
file
and
it
has
an
eye
element.
A
That's
displaying
this
download
icon
as
a
front
cliff
in
a
pseudo
element
in
CSS
and
what
a
screen
reader
will
hear
when
it
lands
on
this
is
button
and
depending
it
might
actually
be
worse
than
that,
depending
on
verbosity
settings
and
what
screen
reader
browser
combination
you're
using
because
it
might
try
to
read
the
icon
glyph,
so
that
is
real.
That
is
actual
code
that
I
copied
from
the
internet.
You
know
last
week,
so
how
can
we
do
better?
What
should
this
actually
look
like
the
simplest
version
of
a
button
without
an
icon?
A
It's
just
you
know.
A
button
element
has
some
text
in
it.
Hopefully,
a
good
text
if
you
want
to
add
an
icon
to
your
text.
Button
SVG
is
more
failsafe
than
an
icon
glyph
for
a
variety
of
reasons,
but
also
for
accessibility,
because
you
can,
you
can
add
accessible
text
a
little
better
and
screen
readers
and
other
assistive
tech.
Don't
try
to
read
the
glyph,
so
what
I've
done
here
is
if
the
button
it's
a
search
button.
A
Sir,
and
as
a
third
example,
here's
a
icon
only
button
that
uses
an
SVG
icon
and
it
has
a
title,
a
title
tag
with
an
SVG
which
is
a
supported,
SVG
tag
that
has
the
string
search
and
it
has
ru
labeled
by
pointing
to
the
ID
of
that
title
tag
on
the
SVG,
because
there
are
some
bugs
where,
even
if
you
have
the
title
tags,
sometimes
there
are
certain
screen
readers
that
won't
read
it
unless
and
ru
labeled.
By
helps
with
that
and
yeah.
A
His
role
equals
image
on
there
on
the
SVG
as
well,
because
sometimes
SVG
s
can
be
treated
as
objects
that
will
be
traversed,
and
you
don't
really
want
that
because
it's
functioning
as
an
icon.
So
there
are
a
couple.
There
are
a
couple
other
possibilities
that
I
didn't
put
there,
that
I
chose
not
to
one
is
Aria
label.
You
could
put
that
on
the
button
itself
you
could
put
that
on
the
SVG
and
that
will
provide
a
hidden,
not
visible,
but
excessively
surfaced
label
to
the
element.
The
reason
I
didn't
choose.
A
That
is
because
it
is
ignored
by
certain
translators.
Google
Translate
will
not
translate
any
text
in
Aria
label.
The
Microsoft
translator
I
forget
what
it's
called
that
doesn't
pay
attention
to
text
in
Aria
attributes
either
and
icon
fonts.
There
are
ways
to
make
icon
fonts
accessible.
If
you
go
through
extra
work
and
another
option
that
is
sometimes
super
useful
is
having
just
some
elements
that
has
specific
CSS.
A
That
will
hide
something
visually
but
still
surface
it
for
a
screen
reader
and
that's
not
display:none
or
visibility
hidden,
which
will
also
hide
things
from
a
screen
reader,
so
something
you
may
notice
it's
there,
a
lot
of
kind
of
hidden
gotchas
that
you
might
not
know,
or
that
might
aren't
obvious
and
something
not
a
lot
of
people
talk
about.
Is
that
once
you
get
beyond
the
basics
of
accessibility,
it
actually
gets
quite
complicated
quite
quickly.
A
This
is
just
an
icon
button,
but
say
you
want
to
build
a
calendar
or
a
combo
box
or
a
menu,
a
menu
button
with
a
menu
popup.
These
actually
get
quite
complicated,
and
it's
good
to
talk
about
accessibility
as
accessible
to
developers
so
to
speak
or
as
easy
to
at
least
start
on,
which
is
good,
because
everyone
should
come
build
things
excessively.
A
But
it's
also
important
to
acknowledge
that
once
you
get
beyond
image,
alts
and
labeling
texts
and
associating
labels
with
inputs,
it
actually
gets
complicated
and
it's
it's
good
to
acknowledge
that
and
to
build
for
that
and
to
build
your
components
with
that
understanding.
So
knowing
that
there
are
hidden
gotchas
knowing
that
there
are
complexities,
how
do
you
build
things
for
other
developers?
A
A
So
what
happens
there?
This
I
made
I
made
the
pony
animate
there
we
go
I
apologize
for
nothing.
The
inventor
wants
this
animated
pony
button
that
maybe
like
generates
a
pony
every
time
you
click
it
or
maybe
it
filters
something
or
maybe
it
creates
a
pop-up.
It's
not
your
common
use
case.
So
what
happens
when
you
get
there.
A
Nothing
could
go
wrong
so
one
way
to
approach
this
is
to
try
to
brainstorm
all
possible
use
cases
for
your
element,
and
this
is
actually
a
little
easier
for
more
complex
elements
because
there's
a
limited
number
of
use
cases
for
say
a
date
input
or
a
combo
box,
you
type
in
it
and
you
can
select
an
option
or
you
type
in
it,
and
you
can
select
a
date.
That's
really
it.
A
But
when
you
get
to
something
like
a
button,
well,
when
I
say
that's
really,
it
there's
probably
some
weird
use
case
for
a
common
box
out
there
that
I'm,
not
thinking
of,
but
when
it
comes
to
a
button.
There's
a
lot
of
widely
different
contexts
to
use
a
button
in
and
they
do
actually
have
some
different
semantics
are
required.
So
say
your
submit.
A
A
recent
form
that
we
already
have
type
people
submit
a
reset,
or
you
know,
button
opening
a
panel
now
we're
getting
to
aria
something
like
an
accordion
button
that
opens
something
on
the
page
expands
something
on
the
page.
You
want
to
have
aria-expanded
equals
true
or
false.
On
there
to
know,
when
you
press
the
button,
is
it
going
to
open
the
thing
or
is
it
going
to
close
the
thing
and
to
indicate
that
there
is
a
thing
to
be
opened
or
closed
if
it
has
a
menu?
A
A
So
if
you
leave
too
much,
if
you
build
too
much
flexibility-
and
you
might
get
something
like
this-
which
is
a
button
that
has
aria-haspopup
equals
true
some
classes,
it
says
tooltip
and
it
has
a
little
plus
icon
on
there
and
aria-haspopup
like
caveman.
Coder.
Here
has
has
done
this
because
I
came
in
here
thinks
that
a
tooltip
is
a
pop-up.
Let's
just
throw
it
on
there.
Our
bad
accessibility
is
really
not
malicious.
People
don't
set
out
to
build
something
accessible.
A
A
So
what
happens
now
is
that
Aria
has
Papa,
but
it's
actually
really
only
for
specific
cases
and
a
tooltip
is
not
one
of
those
cases.
Also,
a
tooltip
should
have
something
like
Aria
described
by,
which
is
perhaps
a
lack
of
flexibility
that
points
to
the
tooltip
text,
but
it
shouldn't
have
Aria
pop
up
and
that's
something
that
might
not
be
known,
but
it's
still
a
thing,
and
you
end
up
with
this.
You
might
also
end
up
with
something
like
this.
A
button
with
that's
that's
an
accordion
button.
It
opens
a
panel.
A
It
has
aria-pressed
equals
true,
because
I
guess
you
press
it
to
open
the
panel
re-expanded,
which
is
good.
It
says
open
accordion
and
then
it
also
has
expand
accordion
on
the
icon,
because
icons
should
have
accessible
text
right,
except
when
you
get
to
this
you're
going
to
hear.
If
you
use
a
screen
reader
you're
going
to
hear
open,
accordion,
expand
accordion,
which
is
redundant
and
unnecessary,
and
also
it's
not
aria
pressed
because
it's
not
toggling
a
state
or
it's
not.
It
is
in
a
sense,
toggling
a
seat,
but
then
you
get
to
this
complexity.
A
We're
sure
it's
toggling
a
seat,
but
it's
still
not
correct,
and
if
you
don't
build
enough
flexibility,
you
get
inventor
here,
who's
decided
to
make
it
the
the
dreaded
div
button
which
has
no
tabindex
and
a
click
handler.
Even
if
you
added
tabindex,
you
still
have
to
add
your
own
keyboard
functionality,
because
divs
do
not,
by
default
capture,
Enter
key
presses
and
space
key
presses
as
clicks.
So
you
you
still
want
somebody
to
use
your
button.
A
You
still
want
enough
flexibility
that
they
won't
go
off
and
create
a
div
button,
but
you
want
enough
control
that
they're
not
going
to
be
throwing
like
spraying
Aria
at
the
wall
indiscriminately.
So
where
do
you
want
flexibility?
A
couple
places
to
start
are
visual
styles,
you.
You
will
never
know
at
component
design
time
what
it
will
end
up
looking
like,
and
it
should
have
a
lot
of
flexibility
and
what
it
ends
up.
A
Looking
like,
because
the
visual
styles
are
not
are
not
always
a
perfect
descriptor
of
what
it
does
are
not
always
deterministic
for
what
something
is
layout.
You
don't
know
how
it'll
fit
in
the
general
page
layout
and
child
content.
If
it
accepts
child
content,
it
should
be
able
to
accept
SVG
icons
and
it
should
be
able
to
accept
animated
ponies
just
as
a
random
example.
So
another
way
to
try
to
balance
between
flexibility
and
control
is
build
an
intuitive
API
one
for
developers,
one
that
kind
of
makes
sense.
A
You
don't
want
them
directly
applying
aria-haspopup,
because
that
can
be
confusing.
You
want
something
like
type
which
can
be
submit
reset
or
button
which
are
all
part
of
HTML,
but
maybe
you
add,
like
toggle
menu
and
an
accordion
in
there,
which
lets
you,
which
are
not
types
that
you
will
apply
to
the
end
HTML
but
which
let
you
control
things
like
an
accordion
button
should
not
have
aria-haspopup
an
accordion
button
should
not
allow
open
it.
You
should
not
allow
press
equals
true
or
false,
because
it's
not
a
toggle
button.
A
It
should,
if
you
have
type
equals,
accordion
and
open
true,
then
you
can
make
certain
assumptions
and
apply
certain
elements
in
a
way.
That's
intuitive
for
the
developer,
using
your
element
and
also
it
grants
you
a
certain
amount
of
control
as
to
what
actual
attributes
end
up
on
your
button
and
the
broad
areas
where
you
really
want
to
spend
time.
Thinking
about
this
include
things
that
are
the
things
that
you
think
fall
by
the
wayside
in
the
middle
of
a
sprint.
That's
certainly
accessibility.
That
can
also
be
internationalization.
A
Often,
what
things
look
like
are
not
necessarily
indicative
of
how
users
use
them,
especially
when
you
get
beyond
a
mouse
and
a
pointer
in
a
screen.
So
these
are
both
things
that
are
called
menus,
at
least
when
people
talk
about
them
on
the
left,
the
file
actions
menu,
specifically
the
Edit
menu
from
Google
Docs.
It's
expanded
on
the
right
is
the
navigation
menu
from
The
New
York
Times
I'm,
not
calling
any
of
these
out
I'm
just
using
them
as
like
basic
examples
of
the
sort
of
pattern
we
call
menu
online.
A
One
of
these
is
a
menu
in
the
Aria
sense
and
in
the
user
interaction
pattern
sense,
and
one
of
them
is
not
despite
the
fact
that
they
look
pretty
much
the
same,
and
then
we
both
call
the
menus
and
if
you
might
have
guessed,
but
the
Google
Docs
menu
is
an
actual
menu
and
Aria
menu.
This
kind
of
prototypical
user
performs
actions
on
a
page
menu,
and
what
that
means
is
there
that
there
are
expectations
for
how
arrow
keys
for
how
arrow
keys,
navigate
their
expectations
for
focus?
Tab
stops.
A
It's
a
glorified
list
of
Link's
nested
links
that
is
in,
in
effect,
a
table
of
contexts
that
a
table
of
contacts
table
of
contents
that
has
some
visual
glitter
sprinkled
over
it
to
make
it
it's
to
make
it
there
we
go
to
make
it
look
like
a
set
of
drop-down
menus
for
space.
That's
that's
fine
to
do!
There's
nothing
wrong
with
that,
but
it
shouldn't
be
a
single
tab.
A
Stop
you
could
put
some
arrow
key
things
in
there,
but
you
should
still
be
able
to
tab
through
it
like
you
would
a
table
of
contents
and
that's
important,
because
a
lot
of
people
think
that
they
should
put
role
equals
menu
on
this
and
that's
not
true.
It
should
live
in.
Maybe
role
equals
navigation,
but
not
role
equals
menu
because
role
equals
menu,
introduces
those
expectations,
expectations
for
key
presses
and
interaction
that
shouldn't
be
there.
A
What
are
the
user
pattern?
So
you
want
to
build,
because,
when
you're
building
a
pattern,
library
you're
not
building
the
end,
like
finished,
fancy,
result
you're,
not
building
for
visual
themes.
You
were
building
for
user
interactions,
for
how
does
for
what
is
like
the
prototypical
pattern,
for
how
user
interacts
with
an
actual
menu?
How
does
a
year's
user
interact
with
an
actual
tooltip
and
that's
that's
kind
of
where
you
start,
and
one
way
to
do
that
is
take
take,
say
a
component
like
this
component?
A
This
is
a
combo
box
and
pretend
like
it's
not
super
clear
but
say
you
can
type
in
that
text
and
put
at
the
top
and
select
any
of
the
options
below
and
that's
the
user
interaction
you
type
in
the
top
and
select
any
of
the
options
below.
So
when
you're,
when
somebody
tells
you
build
a
combo
box,
build
a
combo
box
into
your
pattern.
Library
first
try
to
think
what
is
a
combo
box
can
I
describe
in
one
sentence.
A
What
is
it
actually
that
it
does
and
if
I
were
to
try
this
I'd
say
something
like
it
is
a
text
input,
augmented
by
a
list
of
options
that
are
user,
selectable
and
potentially
curated
or
filtered
options,
something
like
that,
that's
more
or
less
what
it
says,
I
think
and
now
here's
a
more
challenging
example.
This
is
the
material
design,
chip
and
I
don't
want
to
rag
on
material
design.
It's
very
nice,
but
it's
primarily
a
visual
design.
A
A
Entering
information
is
typing,
I
think
they
might
mean
like
display,
entered
information.
But
that's
still
just
like
a
list
of
text.
Making
selections
has
certain
user
UI
pattern
expectations
for
keyboard
for
screen
reader
also
for
Mouse
users,
filtering
content,
trigger
reactions.
All
of
these
imply
different
user
interactions,
and
if
you
ever
have
a
visual
design
pattern
that
encompasses
multiple
expected
user
interactions,
then
you
should
really
question
if
you
want
multiple
components
that
just
share
the
same
design,
which
is
easy,
you
can
put
design
over
anything,
but
you
can
only
when
you're
building
component
logic.
A
It
should
really
follow
the
user
interaction
patterns
and
thinking
about
accessibility,
thinking
about
how
keyboard
users
use
this
each
component
should
have
one
paradigm
for
interaction
and
since
I'm
running
this
timing,
I
think
it's
just
about
right.
Okay,
so
now
that
you've
kind
of
we've
kind
of
talked
about
all
the
things
that
go
into
building
a
combo
framework,
all
the
things
you
want
to
think
about
when
you're
starting
out
I,
also
kind
of
want
to
caution
about
the
limits
of
a
framework.
A
You've
put
all
this
thought,
maybe
into
making
your
framework
accessible,
making
it
performant,
making
it
easy
to
internationalize
all
these
beautiful
things,
and
you
want
to
say
my
framework.
My
component
library
is
accessible
use.
It
and
it'll
be
accessible,
your
app
will
be
accessible,
but
that's
not
really
true.
You
won't
be
able
to
ever
force
people
to
write
good
alternative
text
or
labeling
text.
For
example,
you
won't
ever
be
able
to
force
somebody
to
write
a
good
heading,
a
higher
hierarchy.
A
You
won't
ever
be
able
to
force
people
to
use
landmarks
correctly
and
put
your
components
in
them
correctly.
You
won't
be
able
to
force
people
to
think
about
the
focus
order.
Well,
if
they
aren't
inclined
to
you
can't
think
of
every
possible
context
here,
your
component
will
be
used
in
it's
just
impossible.
There
needs
to
be
some
thought
on
the
part
of
the
developer,
who
uses
this
stuff,
and
it's
good
to
be
upfront
about
that.
To
not
pretend
that
you
can
build
a
component
library
that
will
just
take
care
of
this
for
everyone.
A
So
when
you
put
your
components
out
there,
it's
important
to
yeah
be
realistic,
say
that
there
are
still
things
you
need
to
do
when
you
use
this,
maybe
tell
them
exactly
what
things
are
needed
to
do,
how
you
expect
them
to
use
this?
What
pattern
you're
expecting
this
component
to
fit
in
like,
if
you
have
a
text,
input,
be
clear
about
how
you
expect
this
to
be
used
and
needs
the
label.
You
expect
it
to
well
text.
Input
is
kind
of
self-explanatory,
maybe
like
a
date
picker
or
something
like
that.
A
A
Yeah
I
mean
that
works
like
a
a
menu
just
being
a
list
of
links.
Is
you
know
functionally
what
it
is?
A
menu
is
a
list
of
links,
it's
a
table
of
it's
a
glorified
table
of
contents
and
what
a
table
of
contents
is
potentially
nested
or
maybe
just
single
level
list
of
links.
There
is
actually
this
isn't
what
you
said,
but
there
is
actually
on
the
Aria
pattern
site
animal,
an
implementation
of
the
Aria
menu
that
does
look
like
a
navigation
menu.
A
Hayden
Pickering
has
this
great
article
about
menus,
menus
and
many
roles,
and
he
dives
really
well
into
the
difference
between
a
navigation
menu
and
an
Aria
menu
when
I
say
Aria
menu
I
mean
like
a
programmatic
menu,
the
sort
of
menu
you
see
on
your
desktop
and
why
those
are
different.
Why
the
expectations
of
those
are
different
and
it's
a
great
read
if
anyone
wants
to
wants
to
learn
a
little
more
about
menu
specifically,
but
yeah
navigation
menus
as
a
list
of
links
is
great.
A
If
you
do
implement
dropdowns
there's
a
couple
things
to
be
aware
of,
like
is
the
top-level
button
that
opens
your
drop-down.
Is
that
a
link?
Because
if
it's
a
link,
how
do
you
get
to
the
drop-down?
If
it's
a
button
like
how
does
it
really
fit
into
your
navigation
menu?
So
there
are
some
like
there
are
some
complexities
that
come
with
formatting
a
table
of
contents
as
a
drop-down
menu.
A
A
A
It's
after
this,
yes,
so
things
not
to
control
theming,
it
should
fit
in
any
layout.
It
should
be
able
to
be
inline.
It
should
be
able
to
be
block
or
fit
in
something
that's
in
line
or
block.
It
should
be
able
to
accept
all
manner
of
child
content,
because
if
it
accepts
child
content
at
all,
it
should
accept
pretty
much
anything
because
you
really
can't
control
that
and
the
things
you
do
want
to
control.
A
Just
that's
how
it
is
right
now,
it'd
be
great
if
it
weren't,
but
it
is
what
it
is
and
it
often
gets
left
by
the
wayside.
So
I
put
a
lot
of
thought
into
building
that
into
our
widgets
library,
internationalization
performance.
Anything
else
you
can
think
of
that
might
be
your
passion
or
you're
like
bugbear.
Your
thing
that
you
think
always
gets
left
out
make
sure
that
it
gets
built
in
from
the
start.
A
A
Accounting
for
all
possible
use
cases
would
that
one.
So
one
example
is
when
we
were
building
dojo
widgets.
We
built
the
text
input
before
building
the
combo
box
and
the
combo
box
uses
the
text
input
and
when
we
initially
built
the
text
input,
we
were
thinking.
Okay,
this
is
just
a
user
input.
People
type
into
it
has
a
label
yeah.
But
when
you
put
a
text
input
into
a
combo
box,
it
needs
to
have
certain
properties
like
Aria
controls.
Are
you
active
descendant?
A
Aria
has
pop-up.
That
is
actually
a
pop-up.
It
has
a
list
box
pop-up
a
list
box
menu
which
is
a
list
boxes
like
the
base
set
of
options
for
like
a
selector
combo
box,
and
these
are
attributes
that
you
would
never
put
on
a
text
input
outside
of
that
specific
context.
So,
if
I
hadn't
then
gone
and
made
a
combo
box,
I
wouldn't
have
been
thinking
about
any
of
those
requirements.
A
When
I
built
the
text,
input
and
then
really
I
wasn't
I
had
to
go
back
and
make
the
text
input
more
flexible,
so
that
I
could
use
it
in
a
combo
box.
But
that's
one
example
that
I
actually
ended
up
thinking
about.
There
are
plenty
of
other
examples
that
you
won't
think
about,
not
when
you're
designing
it.
People
use
things
in
all
sorts
of
weird
ways
and
all
sorts
of
weird
patterns,
and
you
won't
you'll,
never
be
able
to
account
for
them.
Also,
you
need
to
at
least
make
it
possible
for
maybe
not
always.
A
Maybe
you
say
that
if
you're
using
this
calendar,
as
you
know,
a
date
grid
for
a
scheduling
app,
that's
not
what
it's
built
for,
and
you
have
to
build
your
own.
But
if
you
do
like,
if
you
want
somebody
to
really
be
able
to
use
your
component
in
a
variety
of
different
ways,
you
need
to
think
about.
How
like,
where
does?
Is
flexibility
actually
required.
A
Yeah
I
think
that's
a
do.
You
mean
like
if
you
take
a
more
complex
thing
like
a
calendar
that
has
an
input
that
you
type
into
and
maybe
a
date
picker
drop-down
that
has
like
month
and
year,
pickers
and
date,
cells,
yeah,
I,
think
it's
good
to
break
it
down,
and
that
way
you
don't
end
up
with
like
one
monster
component
with
all
these
different
patterns
built
into
it,
and
you
also
like
you
have
you
also
can
not
recode
every
single
set
of
like
arrow
key
interaction.
A
Over
and
over
again,
you
can
have
like
the
space
thing
that
maybe
handles
like
a
list
of
options.
We
didn't
do
this,
but
I
can
see
a
case
where
you
could
create
a
component
that
handles
like
up
down
home
and
page
up
page
down
key
interactions.
That
brings
you
to
the
first
last
next,
whatever
and
wraps
and
whatnot
that
could
be
used
to
navigate
a
date
grid,
just
as
it
could
be
used
to
navigate
a
list
box.