Successfully reported this slideshow.
Your SlideShare is downloading. ×

How Accessibility Made Me a Better Developer

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 55 Ad

How Accessibility Made Me a Better Developer

Download to read offline

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.

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.

Advertisement
Advertisement

More Related Content

Slideshows for you (18)

Similar to How Accessibility Made Me a Better Developer (20)

Advertisement

Recently uploaded (20)

How Accessibility Made Me a Better Developer

  1. 1. How Accessibility Made Me a Better Developer Billy  Gregory @thebillygregory …  a  developer’s  tale
  2. 2. Agenda … or why are we here? • Who  am  I? • My  Journey  into  Accessibility • Ten  “Day  1”  Accessibility  Aps • QuesAons,  Comments,  Your  stories  
  3. 3. 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.
  4. 4. WE ARE LOSING CONTROL!!!
  5. 5. The Web is Evolving More  and  more  demands  are   being  place  on  our  code. We  can  no  longer  predict  or  control   how  a  user  accesses  our  code Accessibility  is becoming  the  law.
  6. 6. So what do we do?
  7. 7. 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…
  8. 8. 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  redesigning  their  site
  9. 9. ???? Don’t forget to make it accessible! ???? I had no idea what digital accessibility really was.
  10. 10. Trial By Fire Forced  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.
  11. 11. Own Your Code … and not just the stuff you did right! The real lessons are in the stuff you did wrong
  12. 12. Own Your Code
  13. 13. My moment of clarity My  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 Focus I  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
  14. 14. The Project Ended.
  15. 15. Digital Accessibility in 2008 ...Was an uphill struggle.
  16. 16. 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…
  17. 17. 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!
  18. 18. 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’t Accessibility EXPEN$IVE ?!...
  19. 19. I ignored the documentation.
  20. 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. 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.
  21. 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 always assumed at least SOME level of accessibility • I stopped LOOKING at the designs I was building from, and learned to READ them
  22. 22. Try  to  assume  at  least   SOME  level  of  Accessibility
  23. 23. Looking at your design
  24. 24. READING your design
  25. 25. What YOU see… …isn’t always what they get.
  26. 26. “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  in Accessibility  tesAng.
  27. 27. But what can I do NOW?...
  28. 28.   Day One Accessibility Tips!
  29. 29. My Top Ten  Over  7me,  I  kept  adding  to  the  list  of  things  I  could  "get  away"   with  or  had  complete  control  over 1) Language 2) Seman7c  mark-­‐up 3) Code  Order  /  Tab  Order 4) ARIA  Landmark  Roles 5) Focus 6) Keyboard  control 7) Skip  Links 8) Form  labels  &  fieldsets 9) Alt  text 10) “Hidden”  text
  30. 30. Watch Your Language!   <html  lang="en"> <html  lang="fr"> 1
  31. 31. 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  buons  as  buons,  lists  as  lists,  tables  as   tables,  etc. 2 USE  HEADINGS!!!
  32. 32. Semantic Mark-up   2
  33. 33. Semantic Mark-up   Tables … Yes. Tables. Good  use  of  a  table 2
  34. 34. Semantic Mark-up   Tables … Yes. Tables. BAD  use  of  a  table 2
  35. 35. 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
  36. 36. Code Order vs Tab Order Element Element Element Element This… Element Element Element Element NOT This… 3
  37. 37. ARIA Landmark Roles   WAI-­‐ARIA Web Accessibility   IniEaEve Accessible Rich Internet   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
  38. 38.   ARIA Landmark Roles <header  id=“header”…. <nav  id=“main-­‐navigaAon”  … <main  id=“main-­‐content”  … <div  id=“right-­‐col”  … <footer  id=“footer”  … 4
  39. 39.   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
  40. 40. 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
  41. 41. 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
  42. 42. Focus   ? 5
  43. 43. 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
  44. 44. Keyboard Control   Lots of people don’t use a mouse. 6
  45. 45. 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
  46. 46. 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
  47. 47.   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
  48. 48. Form labels and fieldsets   8
  49. 49. Alternative Text   The  “alt”  aeribute  contains  text  that  describes  an  image alt=“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.”
  50. 50. “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
  51. 51. If you build it...
  52. 52. SomeEmes  it’s  easier   to  beg  forgiveness Than  to  ask  permission  
  53. 53. Thank you! Billy  Gregory @thebillygregory

×