Responsible Design: Accountable Accessibility

download Responsible Design: Accountable Accessibility

of 28

  • date post

  • Category


  • view

  • download


Embed Size (px)


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.

Transcript of Responsible Design: Accountable Accessibility

  • 1. Responsible DesignAccountable Accessibility Billy Gregory@thebillygregory

2. 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 3. About meIm a front end developer at CGI in Toronto, Canada.I am NOT an Accessibility Specialist, expert, guru, ninja, etcWhat 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 4. No. 5. If it worked for me I like to explain Responsible Design using my own story as an example. Not because its particularly unique, but because its incredibly common. So, using my not so unique story as an example, lets start at the beginning. 6. 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 7. I had no idea what accessibility really was. 8. 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. 9. My moment of clarityMy work took on a whole new meaning to meI realized that I was building a tool, not a static pageMy code had a life of its own, it wasnt there to be READ, itwas 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 10. 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 timeMy code had fewer errorsThere were less cross-browser issuesIt was easier for the back end team to integrate 11. 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 12. I tried to speak to the creative department, but they didntlike me questioning their designs 13. The UX team didnt take too kindly to me suggestingalternative approaches 14. It was tough to get other clients interested in AccessibilityThe most common excuses were that accessibility was toohard or too costly so it wasnt included in the specBut, like most devs. 15. I ignored the spec. 16. 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 didnt change the look or feel. 17. 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 18. When good enough stoppedbeing Good EnoughI approached my development process a little differentlyI spent more time planning my code up front, which lead toless time fixing it laterI questioned everything on the page, I made sure it wasdocumentedWireframes became my recipe, I refused to cook withoutthemI always assumed at least SOME level of accessibilityI stopped LOOKING at the designs I was building from,and learned to READ them 19. 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 didnt know before. 20. My Top TenOver time, I kept adding to the list of things I could "get away"with or had complete control over1)Semantic mark-up2)ARIA landmark roles3)Lists and the many ways we can use them4)Skip links5)Focus6)Headings7)Forms and labels8)Alt text9)Hidden text10) Testing 21. 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. 22. Thank you!Billy Gregory @thebillygregoryThis presentation couldnt have beenpossible with help from Ryan Burgess@coveredflth