how accessibility made me a better developer
DESCRIPTION
This is a longer version of my presentation "Responsible Design: Accountable Accessibility" but with a catchier name :) This talk tells my story of how I went from front end developer who knew nothing about accessibility to an accessibility advocate. Included in this talk are my "10 Tips" that any developer can use on day one without any experience authoring accessible HTML. This talk was originally presented at the Accessibility Conference in Guelph, Ontario, Canada on May 29, 2013.TRANSCRIPT
How Accessibility Made Me
a Better Developer
Billy Gregory@thebillygregory
… a developer’s tale
Agenda … or why are we here?
• Who am I?• My Journey into Accessibility• Ten “Day 1” Accessibility Aps• QuesAons, Comments, Your stories
About me…or, who the H#LL is Billy Gregory?
I’m a front end developer who’s passionate about digital accessibility.
I’ve been working in or around digital accessibility since early 2008.
I was a member of “Team Canada” in the Knowbility Open Air CompeEEon in 2012.
WE ARE
LOSINGCONTROL!!!
The Web is EvolvingMore and more demands are being place on our code.
We can no longer predict or control how a user accesses our code
Accessibility isbecoming the law.
So what do we do?
My Journey
If I can do it, so can you.
As developers, you already possess many of the required skills.
…or, if it worked for me…
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 redesigning their site
????
Don’t forget to make it accessible!
????
I had no idea what digital accessibility really was.
Trial By FireForced to learn the hard way
For the first 7me in my career I was using HTML elements, tags, and a@ributes properly
Or in some cases, for the first 7me at all.
Own Your Code
… and not just the stuff you did right!
The real lessons are in the stuff you did wrong
Own Your Code
My moment of clarityMy work took on a whole new meaning to me…• I realized that I was building a tool, not a sta7c page• My code had a life of it’s own, it wasn’t there to be READ, it was there to be USED
Through Clarity Came FocusI no7ced my skills as a developer had evolved• 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
The Project Ended.
Digital Accessibility in 2008...Was an uphill struggle.
I tried to speak to the creative department, but they didn’t like me questioning their designs
Yo dawg, I heard you like the color grey…
The UX team didn’t take too kindly to me suggesting alternative approaches
Yo dawg, I heard you like modals…
So I put a modal…
In your Modal!
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 documentation.
But, like most devs….
But isn’t Accessibility EXPENSIVE?!...
But isn’tAccessibility
EXPEN$IVE ?!...
I ignored the documentation.
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 me translate it so I could finally understand.
And again.
I reached out to the accessibility community. #a11y on twitter will yield results.
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 always assumed at least SOME level of accessibility
• I stopped LOOKING at the designs I was building from, and
learned to READ them
Try to assume at least SOME level of Accessibility
Looking at your design
READING your design
What YOU see… …isn’t always what they get.
“You kids today….” Accessibility has come a long way since 2008.
JQuery UI and other libraries have taken the “baked in” approach and oWen include keyboard support, WAI-‐ARIA and other common accessibility requirements.
There are a lot more tools available to assist inAccessibility tesAng.
But what can I do NOW?...
Day One AccessibilityTips!
My Top Ten Over 7me, I kept adding to the list of things I could "get away"
with or had complete control over
1) Language2) Seman7c mark-‐up3) Code Order / Tab Order4) ARIA Landmark Roles5) Focus6) Keyboard control7) Skip Links8) Form labels & fieldsets9) Alt text10) “Hidden” text
Watch Your Language!
<html lang="en">
<html lang="fr">
1
Semantic Mark-up
Make sure your pages are Atled appropriately and meaningfully. • it’s the first thing a screen reader will read
Use elements for their intended purpose.• Use bu\ons as bu\ons, lists as lists, tables as tables, etc.
2
USE HEADINGS!!!
Semantic Mark-up
2
Semantic Mark-up Tables … Yes. Tables.
Good use of a table
2
Semantic Mark-up Tables … Yes. Tables.
BAD use of a table
2
Code Order vs Tab Order
Code Order: The order the elements are marked-‐up on the page
Tab Order:The order in which the elements on the page receive focus.
3
Code Order vs Tab Order
Element Element Element Element
This…
Element Element Element Element
NOT This…
3
ARIA Landmark Roles WAI-‐ARIA
WebAccessibility IniEaEveAccessibleRichInternet ApplicaEons
• ARIA meant to help bridge the semanEc gap between screen readers and HTML5
• Landmark Roles are just the Ep of the iceberg.
• Screen reader users can use ARIA landmarks to help navigate the page
• Provides further semanEc meaning to page elements
4
ARIA Landmark Roles<header id=“header”….
<nav id=“main-‐navigaAon” …
<main id=“main-‐content” … <div id=“right-‐col” …
<footer id=“footer” …
4
ARIA Landmark Roles<header id=“header” role=“banner”….
<nav id=“main-‐navigaAon” role=“navigaAon”…
<main id=“main-‐content” role=“main” … <div id=“right-‐col” role=“complementary”…
<footer id=“footer” role=“contenAnfo” …
4
Focus
In your CSS, for every :hover pseudo element, use the :focus pseudo element• :hover is bound to the mouse. • keyboards don’t hover• Don’t override the outline• Use more than color alone to show the focus. text-‐decoraEon:underline; is best.
5
Focus
Make sure that when new elements are opened, the focus shi_s accordingly. For instance, when a user opens• Modals• Tool Eps
Be careful when forcing focus on an element. • The user might not be expecEng this.• Error messages • Search form on a new page
5
Focus
?
5
Keyboard Control
POP QUIZ!… or trick ques7on
QuesEon:Who among your users might not be using a mouse?
Answer: Anyone! …It’s not up to us to decide that ;)
Example: Have you ever tabbed through a form when you’re filling it out?
6
Keyboard Control
Lots of people don’t use a mouse.
6
Keyboard Control
Test that your work can be navigated by keyboard alone.
Look out for “keyboard traps” – make sure you don’t open something that would result in your cursor / focus being behind an element like a modal window.
*I totally stole the Akbar thing from George Zamfir -‐ @good_wally
6
Skip Links • Skip links provide a means for keyboard users as well as screen reader users a way to skip repeated blocks of content
• Skip links can be used to skip OVER or skip TO parts of a page.
• Be careful to move keyboard focus and not just visual focus when adding skip links.
7
Skip Links
<main id=“main-‐content” role=“main” … <div id=“right-‐col” role=“complementary”…
<footer id=“footer” role=“contenAnfo” …
<a href="#main-‐content">skip to main content</a>
<ul> <!– this is a repeated block of content -‐-‐> …
7
Form labels and fieldsets
8
Alternative Text
The “alt” aeribute contains text that describes an imagealt=“DescripEve text would go in here”
9
TSA To Introduce New Security Measures.BAD alt text:alt=“TSA officer”
GOOD alt text:alt=“A TSA Agent looking into the camera while snapping on a rubber glove.”
“Hidden” Text
One of the best pracEces for “hiding” text off screen is to use css to visually remove text from the code order while sEll keeping it visible to screen readers.
10
If you build it...
SomeEmes it’s easier to beg forgivenessThan to ask permission
Thank you!
Billy Gregory@thebillygregory