Responsible DesignAccountable Accessibility

Billy Gregory@thebillygregory

“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

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 …

No.

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….

2008I 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

I had no idea what accessibility really was.

Trial By FireForced 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.

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

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

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

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

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

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….

I ignored the spec.

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.

DIY a11yI 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 bottomThen I read it 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

And again.

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

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.

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-up2) ARIA landmark roles3) Lists and the many ways we can use them4) Skip links5) Focus6) Headings7) Forms and labels 8) Alt text9) Hidden text10) Testing

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.

Thank you!

Billy Gregory@thebillygregory

This presentation couldn’t have been possible with help from Ryan Burgess @coveredflth