Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Introduction to mobile accessibility, 2015

4.071 visualizaciones

Publicado el

This is a full day workshop I gave at AccessU 2015 and an updated version of the same workshop I gave at AccessU in 2013 (also on Slideshare).

As an introduction to mobile accessibility it covers key concepts, user experience, development and some QA. It is intended mostly for a non-technical audience who are looking for an introduction to mobile web accessibility and native apps although it does contain some technical guidance.

Publicado en: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Introduction to mobile accessibility, 2015

  1. 1. Introduction  to  mobile  accessibility Henny  Swan
  2. 2. This  is  a  full  day  workshop  I  gave  at  AccessU  2015   and  an  updated  version  of  the  same  workshop  I   gave  at  AccessU  in  2013.     As  an  introduction  to  mobile  accessibility  it  covers   key  concepts,  user  experience,  development  and   some  QA.  It  is  intended  mostly  for  a  non-­‐technical   audience  who  are  looking  for  an  introduction  to   mobile  web  accessibility  and  native  apps  although   it  does  contain  some  technical  guidance. 2
  3. 3. Agenda • Requirements  and  planning   • User  experience   • Development   • QA  and  testing 3
  4. 4. Hand  outs  and  slides • Handouts  available  now  in  
 http://bit.ly/1e0Wn8g   • Slides  to  follow   • Follow  @iheni  for  URLS     • All  questions  are  good  questions   • Today  is  about  sharing 4
  5. 5. Henny  Swan • User  Experience  and  Design  Lead,  The  Paciello  Group   • Formally  BBC,  Opera  Software,  Royal  National  Institute  of   Blind  People   • Specialize  in  accessible  user  experience,  mobile,  media   players,  strategy   • Member  of  W3C  Mobile  Accessibility  Task  Force.  User  Agent   Accessibility  Working  Group  and  Web  of  Things  Task  Force
  6. 6. You • Name   • Company   • Role   • Your  experience  of  accessibility   • Device
  7. 7. MOBILE  ACCESSIBILITY   LANDSCAPE
  8. 8. Audience:  who Diversity  in  disability:   • Type  of  impairment(s)   • Severity  of  impairment(s)   • Circumstances  of  acquisition  of   impairment(s)   • Changeable  impairment(s) 8
  9. 9. Audience:  who Diversity  in  disability:   • Assistive  technology  and  settings*  used:   • Vendor   • Version   • Configuration   • Aptitude  in  using  AT   • Attitude  to  using  AT   *  Assistive  technologies  include  screen  readers,  zoom,  text  resizing,   voice  input,  invert  colors 9
  10. 10. Audience:  who We  all  face  being  impaired:   As  a  child…   Unable  to  hold  a  tablet   Unable  to  use  certain  gestures   Unable  to  understand  text  and  iconography   As  an  older  user…   Reduced  sight,  hearing,  cognition   Problems  with  perception   Temporarily     Broken  wrists,  RSI,  carpel  tunnel   Designing  touch  tablet  experiences  for    preschoolers  –  Sesame  Street 10
  11. 11. Audience:  Personas • Persona  resources  from  the  W3C  Mobile   Accessibility  Task  Force 11
  12. 12. Judy  Dench   Ability:  Advanced  macular   degeneration  and  mild   arthritis   Aptitude:  Hasn’t  really   used  tech  much  but  realizes   she  now  has  to  and  uses  an   iPad   Attitude:  Willing  but  is  too   busy  to  dedicate  the  time 12
  13. 13. Gary  Numan   Ability:  Autism  Spectrum   Disorder.  Uses  zoom  and   occasionally  VoiceOver  when   he  is  tired   Aptitude:  Uses  tablets  for   news  and  research,  but   doesn’t  learn  new  sites  easily   Attitude:  Prefers  apps  to   mobile  content  and  an   established  routine 13
  14. 14. Sinead  O’Conner   Ability:  Fatigue  from   fibromyalgia,  touch  screens,   tapping  and  scrolling  are  hard   Aptitude:  Average  user,  has   good  days  and  bad  days   Attitude:  Wishes  the   hardware  made  more  sense   14
  15. 15. Marlee  Matlin   Ability:  Native  language  is   ASL;  can  speak  and  read  lips;   uses  SMS/IM,  Skype,  and   video  chat   Aptitude:  Good  with  graphic   tools,  and  prefers  visuals  to   text;  poor  spelling  makes   searching  more  difficult   Attitude:  Gets  annoyed  by   lack  of  subtitles 15
  16. 16. Stephen  Hawking   Ability:  Suffers  from  acute   Motor  Neurons  Disease,  no   movement  or  speech       Aptitude:  Super  user,   patient,  curious,  but  is  a  busy   man   Attitude:  Tries  anything,   knows  what  he  wants,   determined  -­‐  this  is  his  only   line  of  communication 16
  17. 17. Barriers  -­‐  Input • Dexterity  and  touch   • Single  handed   • Environment  and  voice 17
  18. 18. 18 I’m  going  to  stick  with  my  Nokia  C5.  I  want  my   mobile  to  be  something  that’s  mobile,  as  in  I  can   walk  and  use  it  without  having  to  stop. -­‐  Hugh  Huddy,  blind  Nokia  and  Talks  user
  19. 19. Barriers  -­‐  orientation   • Forced  orientation   • Mounted  tablets   • Limited  scrolling   • Content  changes 19
  20. 20. Barriers  -­‐  Zoom  and  text  resize • Pinch  zoom  being  disabled   • Loss  of  context   • Floating  toolbars   • Pop  ups 20
  21. 21. Barriers  -­‐  Zoom 21 • Fixed  position  content
  22. 22. Barriers  -­‐  Zoom 22 • Snap  scrolling
  23. 23. Barriers  –  cognitive  overload • Inconsistent  design   • Excess  clutter   • Ambiguous  labels   • Ambiguous  icons   • Poor  error  handling   • Where  am  I?
  24. 24. Opportunity  -­‐  platform  features • Geolocation   • Camera   • Contacts   • Phone 24
  25. 25. Opportunity  -­‐  Web  of  Things • Home  energy  management   • Healthcare  and  fitness   • Google’s  Physical  Web   • Identity  management  and  authentication   • Casting,  audio  and  video  control 25
  26. 26. Web  and  mobile  standards A  significant  but  not  exact  mapping  between   desktop  and  mobile   • Touchscreen  on  both  desktop  and  mobile   • Mobile  devices  with  external  keyboards   • Responsive  design   • User  interface  patterns  from  desktop  used   on  mobile  (links,  tables,  buttons,  menus   etc) 26
  27. 27. Legal  requirement   21st  Century  Act,  USA.  By  2013  smartphones:   • must  have  an  accessible  browser   • must  be  accessible  at  the  OS  level   • must  have  free  or  of  “nominal  cost”  soluQons   ImplicaQons   • North  American  mobile  market  influenQal  globally     • Apple,  Google,  MicrosoU,  RIM   SecQon  508  Refresh   • ‘informaQon  and  communicaQon  technology’  must  be   WCAG  2.0  compliant 27
  28. 28. Standards  and  guidelines W3C  guidelines:   • Web  Content  Accessibility  Guidelines  (WCAG)   • How  WCAG  and  UAAG  apply  to  mobile  devices   • Shared  experiences:  Barriers  common  to   mobile  device  users  and  people  with   disabilities   • Mobile  Accessibility  Overlap   • Independant  User  Interface  (Indi  UI)  Working   Group 28
  29. 29. Standards  and  guidelines iOS  guidelines:   • Accessibility   Programming  Guide   for  Developers   • Human  Interface   Guidelines  for   Designers 29 Android  guidelines:   • Making   applications   accessible   • Accessibility   Developers   checklist   • Android  design:   accessibility  
  30. 30. BBC  Mobile  Accessibility  Standards  and   Guidelines • Technology  agnostic   • iOS,  Android  and  HTML  techniques     • Test  procedures 30
  31. 31. 31
  32. 32. 32
  33. 33. 33
  34. 34. Platform  and  browser  support Define  the  delivery  context   • Responsive   • Native  app     • Hybrid 34
  35. 35. Platform  and  browser  support Define  supported  devices:   • Reference  pre-­‐existing  platform  and  browser   support  plans   • What  devices  have  sufficient  accessibility   support   • What  devices  have  accessible  native   browsers   • What  devices  are  easy  to  upgrade   • Version  support 35
  36. 36. Platform  and  browser  support Define  supported  devices:   • Analyze  web  stats   • Assess  regional  preferences   • Assess  local  legal  requirements   • Research  user  preferences   Output:  mobile  platform  and  browser  support   matrix  with  version  support  logic 36
  37. 37. Platform  and  browser  support Webaim  screen  reader  surveys   • Surveys  screen  reader  user  preferences  of  web   and  mobile  usage   • Every  year  since  2009   • Open  to  anyone   • 2014  survey  results:   • 1456  respondents   • 61%  from  the  US,  21%  UK  and  EU,  Asia  10%…   • 95%  reported  having  a  disability 37
  38. 38. WebAim  screen  reader  survey 38
  39. 39. WebAim  screen  reader  survey 39
  40. 40. WebAim  screen  reader  survey 40
  41. 41. TPG  2013  MOBILE  SURVEY   41 http://www.paciellogroup.com/mobile/
  42. 42. Breakout  session Write  a  Mobile  Accessibility  Strategy  for  a   product  including   • Product  name  and  purpose   • Target  audience   • Platform,  access  technology  and  browser   support   • HTML,  native  or  hybrid 42
  43. 43. MOBILE  ACCESSIBILITY   FEATURES
  44. 44. Mobile  accessibility  landscape iOS  Accessibility  features  and  API  are  the  most  mature   Android  has  some  good  accessibility  features  Google  are   working  to  improve   Current  market  share  favors  iOS  and  Android  devices  over  other  vendors   BlackBerry   Curve  smartphones  have  free  BlackBerry  Screen  Reader   Windows  Phone  8.1   Text  resizing,  High  Contrast  mode,  Narrator,  screen  magnificaQon,  Zoom 44
  45. 45. iOS  accessibility  features 45 Seang User Voiceover Blind,  low  vision,  learning  and  cogniQon Zoom,  Large  Text Blind,  low  vision,  learning  and  cogniQon Invert  colors,  Grey  scale Low  vision,  color  blindness,  learning,   cogniQon Speak  selection Low  vision,  learning  and  cogniQon Speak  auto-­‐text Blind,  low  vision,  learning  and  cogniQon   Hearing  aid  mode Deaf,  hard  of  hearing,  deaf  blind Customize  closed  captions Deaf,  hard  of  hearing,  everyone Guided  access Everybody  including  children  &educaQon Assistive  touch Mobility Switch  control Mobility,  hands  free
  46. 46. iOS  -­‐  mapping  accessibility  shortcuts 1. Go  to  Settings  >   General   Accessibility  >   Accessibility   Shortcut   2. Select  shortcuts   3. Triple  click  the   Home  key  to   activate 46
  47. 47. iOS  -­‐  switch  support • iOs7+   • Using  an  external  device  or  FaceTime   • Accessed  via  Settings  >  Accessibility  >   Switch  control 47
  48. 48. Switch  control  in  iOS8  -­‐  Luis  Perez 48
  49. 49. iOS  -­‐  VoiceOver • Supports  36  languages   • Gesture  and  explore  by  touch  support   • Supports  braille  output   • Excellent  browsing  support 49
  50. 50. iOS  -­‐  activating  VoiceOver 1. Triple  click  the  Home  key  to  activate   2. Dial  to  open  the  Rotor   3. Swipe  up/down  to  navigate  parts   4. Swipe  right/left  for  next  previous 50
  51. 51. iOS  -­‐  rotor  navigation 1. Dial  gesture  on   screen   2. Select  how  you   want  to  navigate   3. Swipe  up  or  down 51
  52. 52. 52 Gesture FuncGon Switch  VO  on/off Triple  click  the  home  key   Speak  an  element   Single  tap   pActivate  an  element Double  tap Open  the  Rotor Turn  a  dial   Zoom 3  finger  double  tap  -­‐  iOS6+  only Next  section  in  Rotor Swipe  up/down Next/previous  item  in  content  order Swipe  right/left Pass  through  gesture  (drag  &  drop) Double  tap  hold Play/Pause 2  finger  double  tap iOS  -­‐  basic  VoiceOver  gestures
  53. 53. 53 3  finger  triple  tap   Screen  curtain  
  54. 54. 54
  55. 55. Seang User Voice  output Blind,  low  vision,  learning  and  cogniQon HapGc  feedback Blind,  Deaf-­‐Blind,  Low  vision,  deaf Large  text Low  vision,  cogniQon,  learning Speak  passwords Blind,  low  vision,  cogniQon,  learning Enhance  web  accessibility Blind Android  -­‐  accessibility  features
  56. 56. Chrome:   Force  enable  zoom   Text  size   Text  scaling   Zoom  on  double-­‐tap   Minimum  font  size   Inverted  colors   Contrast   A  useful  ‘screen  curtain’  equivalent   Shades  app  can  also  do  this   56 Android  -­‐  browser  settings
  57. 57. Enable  WebScripts  via  Settings > Accessibility > ‘Enable Accessibility’   Download  the  Eyes  Free  Keyboard   Browsing   Less  reliable  than  iOS   ApplicaQons   Talkback  well  supported   Beware  hybrid  content   Maps,  adverts,  Terms  and  CondiQons,   Help  pages    etc   57 Android  -­‐  Talkback
  58. 58. 58 Android  -­‐  Talkback
  59. 59. Zoom OS-­‐level  features   • Set  default  text  size   • Magnifies  entire  screen   •  Magnifying  lens  view   under  user's  finger   • 3  finger  scroll 59
  60. 60. Zoom Browser-­‐level  features   • Set  default  text  size  of   text  in  the  browser   • Reader  mode  (not   universally  supported)   • Pinch  zoom 60
  61. 61. Zoom Browser-­‐level  features   • Magnifying  lens  view   under  user's  finger     • Force  enable  zoom   (Chrome,  Android) 61
  62. 62. Breakout  session Using  iOS  or  Android  try  using  each  of  the   following:   • Screen  reader   • Zoom   • Head  switch   Refer  to  the  handouts  which  have  set  up  and   gesture  instructions. 62
  63. 63. USER  EXPERIENCE
  64. 64. As  a  user  I  want… • WCAG  Level  AA  compliance   • WAI  ARIA   • Validated  code   Said  no  user  ever! 64
  65. 65. Accessibility  and  inclusive  design Standards  and  guidelines  tend  to  focus  more   on:   …code  over  design   …output  over  outcome   …compliance  over  experience   65
  66. 66. – I A N P O U N C E Y, W E B D E V E L O P E R , B B C “It pains me to say this but web developers might not be the most important people when it comes to making accessible websites and web apps.”
  67. 67. Principles  of  accessible  UX 67
  68. 68. People  first • Put  people  before  technology   • Consider  environment  and  context   • Consider  first  time  users  and  repeat  users   • Consider  AT  super  users,  average  users,  or   basic  users 68
  69. 69. 69 iOS  start  up   screens
  70. 70. 70 Android  start   up  screens
  71. 71. Focus Prioritise  key  features  in  the  layout  and   content  order   Remove  unnecessary  elements   Group  elements  logically,  visually  and  in  the   content  order   Progressively  reveal  content  on  user  request 71
  72. 72. “ T h e o b v i o u s i s a a b o u t a l w a y s ”
  73. 73. Focus 74
  74. 74. Choice Provide  multiple  ways  to:   • Access  key  tasks,  screens  or  information   • Complete  key  or  complex  tasks   • Complete  non  standard  interactions 75
  75. 75. Choice 76
  76. 76. Control What  ways  can  user  controls  over  content    be   suppressed? 77
  77. 77. Control What  ways  can  user  controls  over  content    be   suppressed?   • Orientation 78
  78. 78. Control What  ways  can  user  controls  over  content    be   suppressed?   • Orientation   • Pinch  zoom 79
  79. 79. Control What  ways  can  user  controls  over  content    be   suppressed?   • Orientation   • Pinch  zoom   • Right  click  (web) 80
  80. 80. Control What  ways  can  user  controls  over  content    be   suppressed?   • Orientation   • Pinch  zoom   • Right  click  (web)   Support  browser  and  platform  accessibility   features 81
  81. 81. Control 82
  82. 82. Control iOS7+  closed  caption     customization:   • Font   • Size   • Color   • Background  color   • Background  opacity   • Text  edge  style   • Text  highlight 83
  83. 83. Familiarity BBC  Radio  iOS  app’s  custom    ‘dial’.   “Although  the  3  finger  swipe  works  for   exposing  stations,  it’s  not  intuitive…  it   would  be  nice  if  some  alternative  solution   could  be  implemented  as  someone  new   to  the  app  probably  wouldn't  think  of   doing  that,  and  of  course  it  should  be   pointed  out  that  VoiceOver  gives  no   feedback  when  you  do  the  3  finger  swipe”   84
  84. 84. Prioritise  features  that  might  be  of  particular   value  for  everyone   • Platform  features   • A  to  Z,  filters,  sort,  manage,  delete     • Web  of  things Value 85
  85. 85. Value 86 GeolocationPhoneCamera
  86. 86. Value Web  of  Things   • Health   • Home   • Entertainment 87 • Energy   • Education   • Security
  87. 87. Breakout  session What  features  might  you  add  to  your  product   to  provide  a  better  user  experience  for   diverse  users? 88
  88. 88. DESIGN
  89. 89. Color  contrast  -­‐  desktop Based  on  15-­‐inch  monitor  at    1024x768   resolution  with  a  24-­‐inch  viewing  distance     WCAG  2.0  recommends:   • contrast  of  4.5:1,  14pt  text   • contrast  ratio  of  3:1  for  18pt+ 90
  90. 90. Focus  states • Use  distinctive  hover/focus  states   • Ideally  use  the  same  hover  state  on  focus   • Selected  states  must  be  unique 91
  91. 91. Visual  cues • Navigation  must  be            visually  explicit   • Distinguish  interactive     elements 92
  92. 92. Visual  cues What’s  wrong  with  the   visual  cues  on  this  screen? 93
  93. 93. Visual  cues  -­‐  iconography Question  mark,  home,  burger  for  home,  disc   for  save,  back  arrow  etc   94 GridAdd List Menu
  94. 94. Visual  cues  -­‐  conventional  positioning 95
  95. 95. Positioning  -­‐  reach • Optimize  for  use  one   handed   • Important  content   bottom  left  to  right   • Position  important   content  above  page   scroll 96Mobile  First  by  Luke  Wroblewski
  96. 96. Consistent  layout  -­‐  platforms 97 Netflix  on  desktop
  97. 97. Consistent  layout  -­‐  Platforms 98Main  menu  when  open Sign  out  at  the  foot  of  the  page
  98. 98. KEYBOARD  AND  TOUCH
  99. 99. Keyboard  control • Via  on  screen  keyboards  and  via  physical   keyboards   • On  touch,  with  VO  and  Talkback  running   ‘keyboard  access’  includes  static  and  hidden   content  as  well  as  focusable  elements   • Everything  related  to  content  and   functionality  must  be  focusable 100
  100. 100. 101
  101. 101. Touch  events Mouse  or  touched  events  prevent  unintentional   triggers  when  interacting   • Gives  mouse  users  the  opportunity  to  move   the  cursor  outside  the  element  to  prevent  the   event  from  being  triggered   • Only  triggers  elements  on  touch  when  the  user   lifts  the  finger  off  the  screen,  the  last  position   of  the  finger  is  inside  the  actionable  element,   and  the  last  position  of  the  finger  equals  the   position  at  touch  start 102
  102. 102. Touch  target  size 103 “The  fingers  you  have  used  to  dial  are  too  fat.  To  obtain  a  special  dialling  wand,  please  mash  the   keypad  with  your  palm  now.”
  103. 103. Touch  target  size Standard  touch  target  size  of  7-­‐10mm   Jacob  Neilson  recommends  9.2  -­‐  9.6mm   Android   Touch  target  size  of  48dp/9mm   Spacing  between  UI  elements  8dp   iOS   Touch  target  size  of  44px  /  44px  tall   PosiQoning   Provide  1mm  inacQve  space  around  elements   Balance  enough  informaQon  density  and     targetability  of  UI  Elements   PosiQon  content  appropriately 104
  104. 104. Touch  target  size Group  links  to  the  same  resource   • Larger  touch  target   • Removes  repetition  for  screen  reader  users   • Less  swiping  and  physical  overhead  needed   105
  105. 105. Gestures   Easier  /  more  intuitive Tap   Draw  /  Move  finger   Swipe   Drag   Slide   Double  tap Harder  /  least  intuitive Pinch   Device  manipulation  e.g.  tilt  /   shake   Multi-­‐touch   Flick  /  Fling   Reference:  Designing  touch  tablet  experiences  for  preschoolers  –  Sesame  Street
  106. 106. Gestures  -­‐  device  manipulation • Device  manipulation  =   tilting,  shaking  etc   • Challenge  to  people  who   can  not  hold  a  device   • Discoverability  and   accidental  activation  also   an  issue   • Always  provide  touch  and   keyboard  operable   alternative 107
  107. 107. Zoom  /  Magnification • Consider  mobile  first  when  designing  layout   and  content  relevancy   • Minimise  content  in  comparison  to  desktop   • Provide  a  reasonable  default  size  for   content  and  touch  controls   • Adapt  link  text  length  to  adapt  to  the   viewport   • Position  form  fields  above  rather  than   beside  form  labels  (in  portrait  layout) 108
  108. 108. Zoom  /  Magnification  -­‐  HTML Avoid   <meta content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=1;” name=”viewport”>   Use   <meta content=”width=device-width; initial-scale=1.0; maximum-scale=2.0; user-scalable=1;” name=”viewport”>   iOS  bug:  Scale  and  orientaQon  Jeremy  Keith 109
  109. 109. 110
  110. 110. FORMS
  111. 111. Forms  -­‐  labels • Auto  zoom  cuts   off  left  aligned   labels   • Labels  above  the   field  are  always  in   view   • Label  explicitly   (HTML)  for  larger   touch  zones 112
  112. 112. Forms  -­‐  viewport Use  the  correct  viewport:     • Responsive:  <meta name=”viewport” content=”width=d evice-width” />   • Mobile:  make  sure  the   viewport  is  the  width  of   your  layout  (usually   about  320  pixels   • CSS  for  padding  and   large  touch  targets 113
  113. 113. Forms  -­‐  keyboards • Default  keyboard  -­‐  capitals,  numbers,   special  characters,  punctuation  buried  in   sub  menus     • Use  HTML  text  input  types  to  invoke  task   based  keyboards 114
  114. 114. Keyboards 115
  115. 115. Forms  -­‐  sign  up • Minimise  data  entry   • Gradual  engagement   • Third  party  sign  up 116
  116. 116. Forms  -­‐  autofill  and  predictive  text • Support  both  where  logical   • Disable  where  logical  e.g.  for  names,  email   addresses   • iOS5   • autocapitalize=”sentences”   autocapitalize=”words”   autocapitalize=”characters” 117
  117. 117. ALTERNATIVES  
  118. 118. Alternatives  are  used  for… • Images   • Buttons   • Graphs,  charts,  diagrams   • Audio   • Video 119
  119. 119. Editorial  for  alternatives… • Briefly  describe  the  image   • Do  not  describe  the  role  /  Trait   • Begin  with  a  capitalized  word   • Don’t  end  with  a  period  (.)   • Localized 120
  120. 120. Alternative  text  -­‐  HTML Assign  contentDescription  to  all  user   interface  components  e.g.:   • alt=“” • alt=“Home” • alt=“Austin University Campus” 121
  121. 121. Tooltips  -­‐  HTML   • Not  well  supported  on  mobile  and  touch   • Not  always  accessible  on  desktop   • Never  include  primary  information   • If  in  doubt  just  say  no 122
  122. 122. Alternatives  -­‐  Android Assign  contentDescription  to  all  user   interface  components  e.g.:   • imageButton • imageView • checkbox Decorative  images  should  not  have  a   contentDescription 123
  123. 123. Labels  -­‐  iOS accessibilityLabel   must  be  provided     for  all  interacQve  and   informaQonal  elements   including  images,  buoons,   headings,  staQc  text  and  form   fields 124
  124. 124. Hints  -­‐  iOS   accessibilityHints  may  be  used  to  provide     further  informaQon   • Describes  what  an  element  does   • Must  not  include  informaQon  about  the  objects  type   (i.e.  Trait)   • Use  sparingly  and  not  for  key  informaQon   Must  be  a  descripQon  not  a  command  e.g.     ‘Deletes  programme’  not  ‘Delete  programme’ 125
  125. 125. Traits  -­‐  iOS Assign  accessibilityTrait  to  all  user  interface   components   Traits  describe  control  type  or  behavior   Control  types  are  mutually  exclusive  and  describe  the   nature  of  the  item   More  than  one  behavior  trait  can  be  used  to  describe   what  items  do 126
  126. 126. Traits  -­‐  iOS • None   • Button   • Link   • SearchField   • Image   • Selected   • PlaysSound   • KeyboardKey   • StaticText 127 • SummaryElement     • NotEnabled   • UpdatesFrequently   • StartsMediaSession   • Adjustable   • AllowsDirectInteraction   • CausesPageTurn   • Header  
  127. 127. 128
  128. 128. STRUCTURE  
  129. 129. content  a   logical  order   provide 130
  130. 130. provide  a   logical   content  order 131 Don’t  make  your  content  sound  like  Yoda
  131. 131. Headings HTML   • Headings  indicated  using  H1  to  H6   Android   • No  means  to  indicate  headings   iOS   • Use  accessibilityTraitHeader 132
  132. 132. Headings Headings  and  lists   H1  to  H6   OL  and  UL   NavigaQon  to  headings  and  the  start  of  lists  for    screen  readers   Seven  plus  or  minus  2   The  opQmum  number  humans  process  informaQon   In  taxonomy  this  translates  to  5-­‐9  headings   Headings  as  lists   Content  under  a  heading  may  be  removed  on  mobile   Consider  lists  over  headings   Avoid  mixing  both 133
  133. 133. Headings  -­‐  HTML 134
  134. 134. Headings   135
  135. 135. Headings  -­‐  iOS • iOS  6+   • UIAccessibilityTraitHeading • Accessed  via  the  Web  Rotor 136
  136. 136. Landmarks  -­‐  HTML Landmarks  reach  the   parts  of  the  page  other   HTML  can  not  reach     • 1  ‘main’  per  page   • 1  ‘header’     • use  ‘navigation’  for   navigation  between   pages   • ‘complementary’  for   reusable  content   • Use  sparingly 137
  137. 137. Landmarks  -­‐  HTML HTML5  sectioning  elements  map  to  ARIA   Landmarks   • article  maps  to  role=“article”   • aside  maps  to  role=“complementary”   • footer  maps  to  role=“contentinfo”   • header  maps  to  role=“main”   • nav  maps  to  role=“navigation”   • section  maps  to  role=“region” 138
  138. 138. 139
  139. 139. 140
  140. 140. ANNOTATED  UX
  141. 141. Annotated  UX Annotate  UX  refers  to  annotating  wireframes,   style  guides  and  designs  for  accessibility.   The  need  for  Annotated  UX  is  threefold…
  142. 142. Annotated  UX Annotate  UX  refers  to  annotating  wireframes,   style  guides  and  designs  for  accessibility.   The  need  for  Annotated  UX  is  threefold:   1. Expose  accessibility  issues  that  originate  from   the  design
  143. 143. Annotated  UX Annotate  UX  refers  to  annotating  wireframes,   style  guides  and  designs  for  accessibility.   The  need  for  Annotated  UX  is  threefold:   1. Expose  accessibility  issues  that  originate  from   the  design   2. Document  accessibility  requirements  prior  to   coding
  144. 144. Annotated  UX Annotate  UX  refers  to  annotating  wireframes,   style  guides  and  designs  for  accessibility.   The  need  for  Annotated  UX  is  threefold:   1. Expose  accessibility  issues  that  originate  from   the  design   2. Document  accessibility  requirements  prior  to   coding   3. Stop  developers  mucking  up  your  designs!
  145. 145. Risks  of  not  doing  it • Designs  come  back  to  you  once  signed  off   with  questions  and  clarifications   • Designs  are  interpreted  and  coded   incorrectly   • Consistency,  value,  choice  and  familiarity   for  the  user  will  be  compromised
  146. 146. Annotated  UX  –  iPlayer  BBC  One  homepage
  147. 147. Annotated  UX  –  iPlayer  native  Android  app
  148. 148. Breakout  session:  Annotated  UX Refer  to  either  the  response  wires  or  iOS   wires  in  the  handouts:   1. What  should  be  changed  for  accessibility?   2. Annotate  the  wireframes  for  accessibility   3. How  would  you  document  requirements  in   an  accessible  way?
  149. 149. What  else  can  annotated  UX  be  used  for? Wireframes   Visual  design   Style  guides Usability  testing   Accessible  prototypes   Requirements     User  stories   Pattern  libraries     Manual  tests   Automated  tests
  150. 150. TESTING
  151. 151. Testing  -­‐  HTML • W3C  developing  a  mobile  checker   • User  agent  switchers 154
  152. 152. Remote  debugging  iOS • iOS  in  Safari  (also  Android)   • iOS  select  Settings  >  Safari  >
  Advanced  and  switch  Web  Inspector  on   • Mobile  Safari  Preferences  >
 Advanced  and  select  Show  
 Develop  Menu  in  menu  bar 155
  153. 153. Remote  debugging 156
  154. 154. Remote  debugging  Android • Enable  USB  debugging  via  Settings  >   Developer  options   • Note  -­‐  On  Android  4.2  and  later,  the   developer  options  are  hidden  by  default.  To   enable  the  developer  options,  select   Settings  >  About  phone  and  tap  Build   number  seven  times.   • Select  USB  debugging 157
  155. 155. Remote  debugging  Android • In  Chrome  go  to  chrome://inspect   • Select  ‘Discover  USB  devices   • Conform  allow  USB  debugging 158
  156. 156. Remote  debugging  Android The  chrome://inspect  page  displays  every   connected  device,  along  with  its  open  tabs   and  debug-­‐enabled  WebViews 159
  157. 157. Remote  debugging  Android Select  Inspect  on  the  tab  you  want  to  inspect 160
  158. 158. Testing  -­‐  Android Android  emulator   • Virtual  device  in  the  Android  SDK   • Configurable  to  mimic  different  devices   • Contains  a  debug  console 161
  159. 159. Testing  -­‐  Android • Lint   • Finds  missing  contentDescriptions   • Finds  missing  input  types  on  text  fields   • Quick  fix  window   • Write  custom  scripts  to  test 162
  160. 160. xCode  iOS  Simulator 163
  161. 161. 164
  162. 162. Manual  testing • Always  manually  test  websites  and  apps   • Simulators,  automated  tests,  inspecting   code  will  not  spotlight  usability  issues 165
  163. 163. Top  tests  for  voice  output 1. Content  and  focus  order   2. Alternatives  exist  and  make  sense   3. Structure  is  communicated   4. Form  labels  and  instructions   5. Notifications  are  provided 166
  164. 164. Top  tests  for  zoom 1. Context  is  not  lost   2. Labels  for  forms  are  visible  above  form   inputs   3. Screens  are  not  cluttered   4. Primary  information  is  obviously   positioned   5. Notifications  are  visible  on  screen 167
  165. 165. Top  tests  for  greyscale  /  invert  colors 1. Text  is  readable   2. Color  contrast  is  sufficient   3. Color  is  not  relied  upon  to  convey  meaning 168
  166. 166. Breakout  session Using  either  zoom,  switch  or  a  screen  reader  (with  screen   curtain  on  for  iOS)  complete  the  following:   1.  On  the  Airbnb  find  a  place  to  stay  in  Austin  between   September  1st  and  7th,  for  2  people  for  under  $200   2.  Using  both  Twitter  and  Facebook  send  a  Tweet  or  post   a  comment  using  the  #AccessUSummit  hashtag   169
  167. 167. Want  to  suggest  your  site? 170
  168. 168. THANK  YOU
  169. 169. Thank  you • Hand  outs  and  slides  at   • hswan@paciellogroup.com   • @iheni   • www.iheni.com 173
  170. 170. iOS  Design  Principles:  Direct   manipulation 174
  171. 171. iOS  Design  principles:  feedback 175
  172. 172. Android  design  principles Enchant  me   • Delight  me  in  surprising  ways   • Real  objects  are  more  fun  than  buttons  and   menus   • Let  me  make  it  mine   • Get  to  know  me 176
  173. 173. Android  design  principles Simplify  my  life   • Keep  it  brief   • Never  lose  my  stuff   • Pictures  are  faster     than  words   • Decide  for  me  but  let  me  have  the   final  say   • Only  show  what  I  need  when   needed   • I  should  always  know  where  I  am   • If  it  looks  the  same  it  should  act   the  same   • Only  interrupt  me  if  it’s  important 177
  174. 174. Android  design  principles Make  me  amazing   • Give  me  tricks  that  work  everywhere   • It’s  not  my  fault   • Sprinkle  encouragement   • Do  the  heavy  lifting  for  me   • Make  important     things  fast 178
  175. 175. Alternatives  -­‐  testing Test   1. Switch  on  speech  output   2. Navigate  to  images,  elements  and  objects  either  by   • Explore  by  touch  (Android/iOS)     • Swiping  up/down,  leU  and  right   3. Verify  an  alternaQve  is  provided   4. Verify  the  alternaQve  accurately  describes  the  content  or  funcQon   Expected  results   • Each  meaningful  images  element  and  object  has  an  alternaQve   • AlternaQves  describe  either  the     • content  of  a  non-­‐funcQonal  image,  element  or  object   • the  funcQon  of  an  acQonable  image,  element  or  object 179
  176. 176. Color  contrast  -­‐  mobile • Only  use  3:1    when  text  is  roughly   equivalent  to  1.2  times  bold  or  1.5  times   (120%  bold  or  150%)  that  of  the  default   platform  size   • Still  wont  guarantee  access  for  low  vision.   Platform  specific  tools  may  need  to  be   used. 180

×