This is a longer version of my presentation "Responsible Design: Accountable Accessibility" but with a catchier name :) This talk tells my story of how I went from front end developer who knew nothing about accessibility to an accessibility advocate. Included in this talk are my "10 Tips" that any developer can use on day one without any experience authoring accessible HTML. This talk was originally presented at the Accessibility Conference in Guelph, Ontario, Canada on May 29, 2013.

1. How Accessibility
Made Me
a Better Developer
Billy
Gregory
@thebillygregory
…
a
developer’s
tale

2. Agenda … or why are we here?
• Who
am
I?
• My
Journey
into
Accessibility
• Ten
“Day
1”
Accessibility
Aps
• QuesAons,
Comments,
Your
stories

3. About me
…or, who the H#LL is Billy Gregory?
I’m
a
front
end
developer
who’s
passionate
about
digital
accessibility.
I’ve
been
working
in
or
around
digital
accessibility
since
early
2008.
I
was
a
member
of
“Team
Canada”
in
the
Knowbility
Open
Air
CompeEEon
in
2012.

4. WE
ARE
LOSING
CONTROL!!!

5. The Web is Evolving
More
and
more
demands
are
being
place
on
our
code.
We
can
no
longer
predict
or
control
how
a
user
accesses
our
code
Accessibility
is
becoming
the
law.

6. So what do we do?

7. My Journey
If
I
can
do
it,
so
can
you.
As
developers,
you
already
possess
many
of
the
required
skills.
…or, if it worked for me…

9. 2008
I
had
just
taken
a
job
as
a
front
end
developer
My
new
employer
had
been
working
with
the
TTC
(Toronto
Transit
Commission)
for
several
months
redesigning
their
site

10. ????
Don’t forget
to make it
accessible!
????
I had no idea what digital accessibility really was.

11. Trial By Fire
Forced
to
learn
the
hard
way
For
the
first
7me
in
my
career
I
was
using
HTML
elements,
tags,
and
a@ributes
properly
Or
in
some
cases,
for
the
first
7me
at
all.

12. Own Your Code
… and not just the
stuff you did right!
The real lessons
are in the stuff
you did wrong

13. Own Your Code

14. My moment of clarity
My
work
took
on
a
whole
new
meaning
to
me…
• I
realized
that
I
was
building
a
tool,
not
a
sta7c
page
• My
code
had
a
life
of
it’s
own,
it
wasn’t
there
to
be
READ,
it
was
there
to
be
USED
Through Clarity Came Focus
I
no7ced
my
skills
as
a
developer
had
evolved
• I
was
carefully
choosing
how
and
why
I
was
coding
every
element
on
the
page,
knowing
it
was
going
to
be
tested
and
I
needed
to
defend
my
choices

15. The Project Ended.

16. Digital Accessibility in 2008
...Was an uphill struggle.

17. I tried to speak to the creative department, but they didn’t
like me questioning their designs
Yo dawg, I heard you like
the color grey…

18. The UX team didn’t take too kindly to me suggesting
alternative approaches
Yo dawg, I heard you like
modals…
So I put a modal…
In your
Modal!

19. It was tough to get other clients interested in Accessibility
The most common excuses
were that accessibility was
“too hard” or “too costly”
so it wasn’t included in the
documentation.
But, like most devs….
But
isn’t
Accessibility
EXPENSIVE?!...
But isn’t
Accessibility
EXPEN$IVE ?!...

20. I ignored the
documentation.

21. DIY a11y
I took it on myself to make my work more accessible
I knew the heart of accessible code, was semantic HTML
I read the WCAG document top to bottom
Then I read it again. And again.
Then I had someone smarter than me translate it so I
could finally understand.
And again.
I reached out to the accessibility community.
#a11y on twitter will yield results.

22. When good enough stopped
being “Good Enough”
I approached my development process a little differently
• I spent more time planning my code up front, which lead to
less time fixing it later
• I always assumed at least SOME level of accessibility
• I stopped LOOKING at the designs I was building from, and
learned to READ them

23. Try
to
assume
at
least
SOME
level
of
Accessibility

25. Looking at your design

26. READING your design

27. What YOU see…
…isn’t always what they get.

28. “You kids today….”
Accessibility
has
come
a
long
way
since
2008.
JQuery
UI
and
other
libraries
have
taken
the
“baked
in”
approach
and
oWen
include
keyboard
support,
WAI-­‐ARIA
and
other
common
accessibility
requirements.
There
are
a
lot
more
tools
available
to
assist
in
Accessibility
tesAng.

29. But what can
I do NOW?...

30.
Day One
Accessibility
Tips!

31. My Top Ten
Over
7me,
I
kept
adding
to
the
list
of
things
I
could
"get
away"
with
or
had
complete
control
over
1) Language
2) Seman7c
mark-­‐up
3) Code
Order
/
Tab
Order
4) ARIA
Landmark
Roles
5) Focus
6) Keyboard
control
7) Skip
Links
8) Form
labels
&
fieldsets
9) Alt
text
10) “Hidden”
text

32. Watch Your Language!
<html
lang="en">
<html
lang="fr">
1

33. Semantic Mark-up
Make
sure
your
pages
are
Atled
appropriately
and
meaningfully.
• it’s
the
first
thing
a
screen
reader
will
read
Use
elements
for
their
intended
purpose.
• Use
buons
as
buons,
lists
as
lists,
tables
as
tables,
etc.
2
USE
HEADINGS!!!

34. Semantic Mark-up
2

35. Semantic Mark-up
Tables … Yes. Tables.
Good
use
of
a
table
2

36. Semantic Mark-up
Tables … Yes. Tables.
BAD
use
of
a
table
2

37. Code Order vs Tab Order
Code
Order:
The
order
the
elements
are
marked-­‐up
on
the
page
Tab
Order:
The
order
in
which
the
elements
on
the
page
receive
focus.
3

38. Code Order vs Tab Order
Element Element Element Element
This…
Element Element Element Element
NOT This…
3

39. ARIA Landmark Roles
WAI-­‐ARIA
Web
Accessibility
IniEaEve
Accessible
Rich
Internet
ApplicaEons
• ARIA
meant
to
help
bridge
the
semanEc
gap
between
screen
readers
and
HTML5
• Landmark
Roles
are
just
the
Ep
of
the
iceberg.
• Screen
reader
users
can
use
ARIA
landmarks
to
help
navigate
the
page
• Provides
further
semanEc
meaning
to
page
elements
4

40.
ARIA Landmark Roles
<header
id=“header”….
<nav
id=“main-­‐navigaAon”
…
<main
id=“main-­‐content”
… <div
id=“right-­‐col”
…
<footer
id=“footer”
…
4

41.
ARIA Landmark Roles
<header
id=“header”
role=“banner”….
<nav
id=“main-­‐navigaAon”
role=“navigaAon”…
<main
id=“main-­‐content”
role=“main”
… <div
id=“right-­‐col”
role=“complementary”…
<footer
id=“footer”
role=“contenAnfo”
…
4

42. Focus
In
your
CSS,
for
every
:hover
pseudo
element,
use
the
:focus
pseudo
element
• :hover
is
bound
to
the
mouse.
• keyboards
don’t
hover
• Don’t
override
the
outline
• Use
more
than
color
alone
to
show
the
focus.
text-­‐decoraEon:underline;
is
best.
5

43. Focus
Make
sure
that
when
new
elements
are
opened,
the
focus
shi_s
accordingly.
For
instance,
when
a
user
opens
• Modals
• Tool
Eps
Be
careful
when
forcing
focus
on
an
element.
• The
user
might
not
be
expecEng
this.
• Error
messages
• Search
form
on
a
new
page
5

44. Focus
?
5

45. Keyboard Control
POP
QUIZ!…
or
trick
ques7on
QuesEon:
Who
among
your
users
might
not
be
using
a
mouse?
Answer:
Anyone!
…It’s
not
up
to
us
to
decide
that
;)
Example:
Have
you
ever
tabbed
through
a
form
when
you’re
filling
it
out?
6

46. Keyboard Control
Lots of
people don’t
use a mouse.
6

47. Keyboard Control
Test
that
your
work
can
be
navigated
by
keyboard
alone.
Look
out
for
“keyboard
traps”
–
make
sure
you
don’t
open
something
that
would
result
in
your
cursor
/
focus
being
behind
an
element
like
a
modal
window.
*I
totally
stole
the
Akbar
thing
from
George
Zamfir
-­‐
@good_wally
6

48. Skip Links
• Skip
links
provide
a
means
for
keyboard
users
as
well
as
screen
reader
users
a
way
to
skip
repeated
blocks
of
content
• Skip
links
can
be
used
to
skip
OVER
or
skip
TO
parts
of
a
page.
• Be
careful
to
move
keyboard
focus
and
not
just
visual
focus
when
adding
skip
links.
7

49.
Skip Links
<main
id=“main-­‐content”
role=“main”
… <div
id=“right-­‐col”
role=“complementary”…
<footer
id=“footer”
role=“contenAnfo”
…
<a
href="#main-­‐content">skip
to
main
content</a>
<ul>
<!–
this
is
a
repeated
block
of
content
-­‐-­‐>
…
7

50. Form labels and fieldsets
8

51. Alternative Text
The
“alt”
aeribute
contains
text
that
describes
an
image
alt=“DescripEve
text
would
go
in
here”
9
TSA
To
Introduce
New
Security
Measures.
BAD
alt
text:
alt=“TSA
officer”
GOOD
alt
text:
alt=“A
TSA
Agent
looking
into
the
camera
while
snapping
on
a
rubber
glove.”

52. “Hidden” Text
One
of
the
best
pracEces
for
“hiding”
text
off
screen
is
to
use
css
to
visually
remove
text
from
the
code
order
while
sEll
keeping
it
visible
to
screen
readers.
10

53. If you build it...

54. SomeEmes
it’s
easier
to
beg
forgiveness
Than
to
ask
permission

55. Thank you!
Billy
Gregory
@thebillygregory