Responsible Design: Accountable Accessibility
6 likes•4,755 views
Billy Gregory, a front-end developer, shares his journey towards understanding and prioritizing accessibility in web design, emphasizing the importance of code ownership. He describes how his experiences, beginning in 2008, led to a transformation in his approach to development and a commitment to making his code more accessible. Through self-education and practical application, Gregory outlines key practices that contribute to improved accessibility in web development.
Responsible Design: Accountable Accessibility
- 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