Given from a developer's perspective, this presentation will address the concept of responsible web design as an approach to the authoring of accessible web sites.

1. Responsible Design
Accountable Accessibility
Billy Gregory
@thebillygregory

2. “Through code ownership, I became more
Responsible for the overall Design of my code.
I believed that by holding myself Accountable
for the end result, I could directly improve the
Accessibility of my work.”
A tall, questionably handsome, man at the front of the room

3. About me
I’m a front end developer at CGI in Toronto, Canada.
I am NOT an Accessibility Specialist, expert, guru, ninja, etc…
What I am is a developer who has grown to understand the
importance of Accessibility, not only to those who rely on it
but to the web as a whole.
As the web shifed, grew, mutated, evolved, matured, into
this fantastically semantic place, I began to realize one
simple fact about Accessibility that all developers should
embrace …

5. No.

7. If it worked for me…
I like to explain Responsible Design
using my own story as an example.
Not because it’s particularly unique,
but because it’s incredibly common.
So, using my not so unique story as an
example, let’s start at the beginning….

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 and had just begun
development on the templates
I was being parachuted into the project just afer the
templates had come in from the contractor who had been
working on them

10. I had no idea what accessibility really was.

11. Trial By Fire
Forced to learn the hard way
For the frst time in my career I was using HTML
elements, tags, and attributes properly
Or in some cases, for the frst time at all.

12. My moment of clarity
My work took on a whole new meaning to me…
•
I realized that I was building a tool, not a static page
•
My code had a life of it’s own, it wasn’t there to be READ, it
was there to be USED
While I never questioned the importance of accessibility, I
learned that it was not my job or my right to dictate who could
use this code or HOW

13. Through Clarity Came Focus
I noticed my skills as a developer had evolved
•
My focus was no longer on making my code match the design
•
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
As a result, over a period of time
•
My code had fewer errors
•
There were less cross-browser issues
•
It was easier for the back end team to integrate

14. Accessibility in 2008
It was hard enough to get some devs to abandon table
based layouts let alone embrace semantic code
We were still years away from the end of IE6

15. I tried to speak to the creative department, but they didn’t
like me questioning their designs

16. The UX team didn’t take too kindly to me suggesting
alternative approaches

17. 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 spec
But, like most devs….

18. I ignored the spec.

19. I looked for ways to improve accessibility without
involving the client, the PM, the designers, or the UX
team while not undermining their work
The answer was at my fingertips, and right in front of
me, all along
My code.
I was ultimately responsible for the work I was putting
out there, there was no one else telling me how to
code.
I could make it as accessible as I wanted to as long as
I didn’t change the look or feel.

20. 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. And again.
Then I had someone smarter than my translate it into
developer speak so I could finally understand it.
I learned which points were bound directly to my work
and that I had complete ownership over

21. 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 questioned everything on the page, I made sure it was
documented
•
Wireframes became my recipe, I refused to cook without
them
•
I always assumed at least SOME level of accessibility
•
I stopped LOOKING at the designs I was building from,
and learned to READ them

25. Own Your Code
… and not just the stuff you did right!
The real lessons are in the stuff you did wrong
Every bug could be a chance to learn something
you didn’t know before.

26. My Top Ten
Over time, I kept adding to the list of things I could "get away"
with or had complete control over
1) Semantic mark-up
2) ARIA landmark roles
3) Lists and the many ways we can use them
4) Skip links
5) Focus
6) Headings
7) Forms and labels
8) Alt text
9) Hidden text
10) Testing

27. By taking the extra time to carefully craf my code, and
from taking full responsibility for what I was putng out
for people to use, I became protective of my work.
Figuring out what I could do above and beyond just
writing the best HTML was just natural progression.

28. Thank you!
Billy Gregory
@thebillygregory
This presentation couldn’t have been
possible with help from Ryan Burgess
@coveredflth