How Accessibility Made Me a Better Developer
Upcoming SlideShare
Loading in...5
×
 

How Accessibility Made Me a Better Developer

on

  • 476 views

This is a longer version of my presentation "Responsible Design: Accountable Accessibility" but with a catchier name :) ...

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.

Statistics

Views

Total Views
476
Views on SlideShare
476
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
2

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

How Accessibility Made Me a Better Developer How Accessibility Made Me a Better Developer Presentation Transcript

  • How AccessibilityMade Mea Better DeveloperBilly  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.
  • WEARELOSINGCONTROL!!!
  • 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  codeAccessibility  isbecoming  the  law.
  • So what do we do?
  • My JourneyIf  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  developerMy  new  employer  had  been  working  with  the  TTC  (Toronto  Transit  Commission)  for  several  months  redesigning  their  site
  • ????Don’t forgetto make itaccessible!????I had no idea what digital accessibility really was.
  • Trial By FireForced  to  learn  the  hard  wayFor  the  first  7me  in  my  career  I  was  using  HTML  elements,  tags,  and  a@ributes  properlyOr  in  some  cases,  for  the  first  7me  at  all.
  • Own Your Code… and not just thestuff you did right!The real lessonsare in the stuffyou 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  USEDThrough 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’tlike me questioning their designsYo dawg, I heard you likethe color grey…
  • The UX team didn’t take too kindly to me suggestingalternative approachesYo dawg, I heard you likemodals…So I put a modal…In yourModal!
  • It was tough to get other clients interested in AccessibilityThe most common excuseswere that accessibility was“too hard” or “too costly”so it wasn’t included in thedocumentation.But, like most devs….But  isn’t  Accessibility  EXPENSIVE?!...But isn’tAccessibilityEXPEN$IVE ?!...
  • I ignored thedocumentation.
  • DIY a11yI took it on myself to make my work more accessibleI knew the heart of accessible code, was semantic HTMLI read the WCAG document top to bottomThen I read it again. And again.Then I had someone smarter than me translate it so Icould finally understand.And again.I reached out to the accessibility community.#a11y on twitter will yield results.
  • 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 toless time fixing it later• I always assumed at least SOME level of accessibility• I stopped LOOKING at the designs I was building from, andlearned 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 canI do NOW?...
  •  Day OneAccessibilityTips!
  • My Top Ten  Over  7me,  I  kept  adding  to  the  list  of  things  I  could  "get  away"  with  or  had  complete  control  over1) 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  readUse  elements  for  their  intended  purpose.• Use  buons  as  buons,  lists  as  lists,  tables  as  tables,  etc.2USE  HEADINGS!!!
  • Semantic Mark-up  2
  • Semantic Mark-up  Tables … Yes. Tables.Good  use  of  a  table2
  • Semantic Mark-up  Tables … Yes. Tables.BAD  use  of  a  table2
  • Code Order vs Tab Order  Code  Order:  The  order  the  elements  are  marked-­‐up  on  the  pageTab  Order:The  order  in  which  the  elements  on  the  page  receive  focus.3
  • Code Order vs Tab OrderElement Element Element ElementThis…Element Element Element ElementNOT This…3
  • ARIA Landmark Roles  WAI-­‐ARIAWebAccessibility  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  elements4
  •  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  EpsBe  careful  when  forcing  focus  on  an  element.  • The  user  might  not  be  expecEng  this.• Error  messages  • Search  form  on  a  new  page5
  • Focus  ?5
  • Keyboard Control  POPQUIZ!…  or  trick  ques7onQuesEon: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 ofpeople don’tuse 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_wally6
  • 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”  9TSA  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