Responsible DesignAccountable Accessibility Billy Gregory @thebillygregory
“Through code ownership, I became moreResponsible for the overall Design of my code.I believed that by holding myself Accountablefor the end result, I could directly improve theAccessibility of my work.” A tall, questionably handsome, man at the front of the room
About meI’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 theimportance of Accessibility, not only to those who rely on itbut to the web as a whole.As the web shifed, grew, mutated, evolved, matured, intothis fantastically semantic place, I began to realize onesimple fact about Accessibility that all developers shouldembrace …
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 developerMy new employer had been working with the TTC (TorontoTransit Commission) for several months and had just begundevelopment on the templatesI was being parachuted into the project just afer thetemplates had come in from the contractor who had beenworking on them
Trial By FireForced to learn the hard wayFor the frst time in my career I was using HTMLelements, tags, and attributes properlyOr in some cases, for the frst time at all.
My moment of clarityMy 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 USEDWhile I never questioned the importance of accessibility, Ilearned that it was not my job or my right to dictate who coulduse this code or HOW
Through Clarity Came FocusI 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 choicesAs 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 2008It was hard enough to get some devs to abandon tablebased layouts let alone embrace semantic codeWe were still years away from the end of IE6
I tried to speak to the creative department, but they didn’tlike me questioning their designs
The UX team didn’t take too kindly to me suggestingalternative approaches
It was tough to get other clients interested in AccessibilityThe most common excuses were that accessibility was “toohard” or “too costly” so it wasn’t included in the specBut, like most devs….
I looked for ways to improve accessibility withoutinvolving the client, the PM, the designers, or the UXteam while not undermining their workThe answer was at my fingertips, and right in front ofme, all alongMy code.I was ultimately responsible for the work I was puttingout there, there was no one else telling me how tocode.I could make it as accessible as I wanted to as long asI didn’t change the look or feel.
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
When good enough stoppedbeing “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 wrongEvery bug could be a chance to learn somethingyou didn’t know before.
My Top TenOver 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
By taking the extra time to carefully craf my code, andfrom taking full responsibility for what I was putng outfor people to use, I became protective of my work.Figuring out what I could do above and beyond justwriting the best HTML was just natural progression.
Thank you! Billy Gregory @thebillygregoryThis presentation couldn’t have beenpossible with help from Ryan Burgess@coveredflth