• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction to mobile accessibility - AccessU 2013
 

Introduction to mobile accessibility - AccessU 2013

on

  • 11,256 views

Where do you start when making your content mobile? ...

Where do you start when making your content mobile?

This presentation tackles how people with disabilities use the mobile web and applications, putting together a mobile support strategy, responsive web design, iOS and Android development covering design, development and testing.

Statistics

Views

Total Views
11,256
Views on SlideShare
6,754
Embed Views
4,502

Actions

Likes
28
Downloads
91
Comments
7

13 Embeds 4,502

http://www.iheni.com 3870
http://webeyedea.info 518
https://twitter.com 78
http://www.webeyedea.info 17
http://69.89.26.57 4
https://www.google.com 4
http://translate.googleusercontent.com 3
http://www.365dailyjournal.com 2
http://www.iheni.com. 2
http://feeds.feedburner.com 1
http://webcache.googleusercontent.com 1
http://tweetedtimes.com 1
http://www.google.co.uk 1
More...

Accessibility

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

17 of 7 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thank you Henny! Your presentation is so useful! Keep sharing your fantastic work!
    Are you sure you want to
    Your message goes here
    Processing…
  • Incredible presentation - thanks for sharing!
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for your reply Henny. You know I've been a PE advocate for a couple of years, but my faith is shaken when I examine it in various lights:
    - The most recent stats we can find for JS-free users are for 2010. That's a generation ago in online terms.
    - A user who chooses to browse JS-free excludes themselves from so much of the modern web that their behaviour simply isn't realistic any more.
    - If screen readers (some or all) handle some JS interactions poorly, I want information and insight into what tends to work well or poorly. I need this anyway, once I start enhancing my page.
    - Screen readers are browsers. Users choosing to use old screen readers are like users choosing to use IE6. In many commercial environments the cost of supporting that choice out-weighs the benefits. And like other browser vendors, the screen reader vendors need to keep up with how the web is being developed (with the understanding that they will always lag the major visual browsers, and that some JS content may be too inherently visual to render aloud).

    I still see two benefits:
    - An instinct, that I can't currently support, that PE supports content destined to be consumed on both desktop and mobile well (ie everything).
    - A relatively intangible belief that focusing on the capabilities of HTML leads to more useable page design.

    A prominent architect in my current company strongly disagrees with me on this last point. I think it's because I tend to think in terms of web *content* (coming from the BBC until recently) while he tends to think in terms of *applications* with sophisticated behaviour.

    Your thoughts on the above will be extremely welcome!
    Guy
    Are you sure you want to
    Your message goes here
    Processing…
  • @GuyStrelitz I don't think progressive enhancement as a development approach will be going anywhere for a while.

    While JS is well supported across desktop and mobile browsers it's not well supported in all older versions. There are also users who, for one reason or another, may have JS switched off. While this represents a small percentage on desktop it is still a percentage. See Yahoo's 2010 stats for info: http://developer.yahoo.com/blogs/ydn/many-users-javascript-disabled-14121.html for an idea of numbers.

    The other issue with JS is how it gets on with assistive tech such as screen readers and voice input. Screen readers can handle most instances of JS but not all. We have WAI ARIA to bridge that gap but even there we have varying levels of support across desktop and mobile browsers. I only recommend WAI ARIA fixes for the parts that good old HTML can't reach rather than use it as a default.

    The idea of progressive enhancement is also applicable for native apps. On iOS, with the update to iOS6 we saw lots of new accessibility traits and coding techniques introduced (see http://www.iheni.com/new-accessibility-techniques-in-ios6/). They're all great but until all users have upgraded to iOS6 these should be considered an enhancement rather than a fail safe way to make something accessible.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hi Henny. I see you recommend progressive enhancement with a JS-free first implementation. Given the prevalence of JS on both desktop and mobile, why is this still a valuable approach?

    Guy
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduction to mobile accessibility - AccessU 2013 Introduction to mobile accessibility - AccessU 2013 Presentation Transcript

    • Henny  Swan  @iheni  |  www.iheni.com  |  henny@iheni.comIntroduc)on  to  Mobile  AccessibilityTuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • Me2Tuesday, 21 May 13
    • You3Tuesday, 21 May 13
    • 4Discovery  Design  &  Build  Deploy  Tuesday, 21 May 13
    • 5Discovery  Design  &  Build  Test  Tuesday, 21 May 13
    • WhoDisabled,  ageing,  young,  legacy  techYouWhatMobile  web,  RWD,  Apps,  HybridsPla@ormsDevicesHowGuidelinesTechnology  and  device  supportTest  plans6DiscoveryDiscoveryTuesday, 21 May 13
    • Who7Tuesday, 21 May 13
    • People  first,  disability  secondPeople  not  defined  by  disabilityPeople  are  not  defined  by  assisEve  techMay  have  mulEple  or  changing  impairmentsBeware  disability  silosDesign  for  different  acEvity  flows:I  am  a  first  Eme  user  /  I  am  a  repeat  userI  am  on  the  moveI  am  task  focusedI  am  on  the  sofaChallenge  your  assumpEons  about  disabled  users8WhoDiscoveryTuesday, 21 May 13
    • Design  for  disability,  not  in  spite  of  it9WhoDiscoveryTuesday, 21 May 13
    • 10The  mul)faceted  userRepeat  userTask  based  userFirst  )me  userAA‘Lean  back’  userDesign  for  the  MulEfaceted  User  by  Stephanie  TroethTuesday, 21 May 13
    • 11The  mul)faceted  userRepeat  userTask  based  userLow  visionFirst  )me  userOldAALimited  dataHard  of  hearingScreen  reader  userMobilityTravellingOn  the  sofa‘Lean  back’  userDexterityChildrenTuesday, 21 May 13
    • 12The  mul)faceted  userRepeat  userTask  based  userAspergersLow  visionFirst  )me  userSecond  languageOldAALimited  dataHard  of  hearingDeafPoor  connec)onScreen  reader  userZoom  userBlindVoice  input  userMobilityTravellingOn  the  sofaDepressedYoung‘Lean  back’  userCap)ons  ScrollingDexterityChildrenCogni)onTuesday, 21 May 13
    • 13The  mul)faceted  userRepeat  userTask  based  userAspergersLow  visionFirst  )me  userSecond  languageOldAALimited  dataHard  of  hearingDeafPoor  connec)onScreen  reader  userZoom  userBlindVoice  input  userMobilityTravellingOn  the  sofaDepressedYoung‘Lean  back’  userCap)ons  ScrollingTouchKeyboardD  PadDexterityChildrenCogni)onApps,HybridWebMobileTabletTVWindowsAndroidiOS...Tuesday, 21 May 13
    • I’m  going  to  s=ck  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,  Nokia  and  Talks  user14Tuesday, 21 May 13
    • Flip  phoneA  phone  that  flips  open  and  answers  automaEcally  may  be  useful  for  blind,  low  vision  or  users  with  mobility  impaired  usersMonoblock  /  sEckFor  people  with  arthriEs  or  poor  dexterity  useful  to  avoid  the  need  for  added  movements  like  sliding  or  flipping  open  the  phone  to  use  it.15WhoDiscoverySource:  www.MobileAccessibility.infoTuesday, 21 May 13
    • Slide  or  slipUseful for people with limited or low visionor who are blind, as they will answerautomatically upon sliding openTouch  and  SmartphoneMay  be  useful  to  people  who  are  deaf  or  hard  of  hearing  and  who  use  larger  screen  sizes  for  texEng  or  video  calling.16WhoDiscoveryTuesday, 21 May 13
    • What17Tuesday, 21 May 13
    • Mobile  is  by  defini)on  is  disabling  18Tuesday, 21 May 13
    • Screen  sizeiPhone  is  1/12  a  typical  desktop  screen  size40  pixel  finger  is  big  on  small  targetsReachFonts  and  colourPoor  support  on  older  phonesSmall  textFixed  textInputDexterity  and  touchEnvironment  and  voiceSingle  handedBarriers  mulEplied  x  10  for  diverse  users 19Restric=ons  on  mobileDiscoveryTuesday, 21 May 13
    • Mobile  is  by  defini)on  is  enabling  20Tuesday, 21 May 13
    • Mobile  over  desktopFaster  innovaEonPortabilityLocaEon  servicesMapsTailored  contentDevice  integraEonContactsCameraMapsAccessibility  supportBuilt  in  &  third  partySe[ngsSecond  screen21Opportuni=es  on  mobileDiscoveryTuesday, 21 May 13
    • While  engaging  with  content  on  ne  device,  e.g.  TV,  addiEonal  contextual  informaEon  is  displayed  on  a  companion  device  e.e.  mobile  or  tabletEPG  The  app  synchronises  content  via  listening  to  the  TVSelect  camera  angles  for  awards  shows  /  sportAudio  descripEon  /  Enriched  commentary  at  The  Olympic  Opening  CeremonyMassive  opportuniEes  for  people  with  disabiliEesDelivery  of  access  services  -­‐  signing,  AD,  capEoningUsing  a  device  as  a  remoteShared  but  tailored  experiences  22Second  screening  &  accessibilityDiscoveryTuesday, 21 May 13
    • While  engaging  with  content  on  one  device,  e.g.  TV,  addiEonal  contextual  informaEon  is  displayed  on  a  companion  device  such  as  a  mobile  or  tabletEPG  The  app  synchronises  content  via  listening  to  the  TVSelect  camera  angles  for  awards  shows  /  sportAudio  descripEon  /  Enriched  commentary  at  The  Olympic  Opening  CeremonyMassive  opportuniEes  for  people  with  disabiliEesDelivery  of  access  services  -­‐  signing,  AD,  capEoningUsing  a  device  as  a  remoteShared  but  tailored  experiences  23Second  screen  &  accessibilityDiscoveryTuesday, 21 May 13
    • ¥Ho24PlaSorm  accessibility  support  /  seUngs User  profilesVoice  output Blind,  low  vision,  cogniEveZoom Low  vision,  cogniEon,  mobilityBlack  &  White,  Inverse  colors,  brightness Low  vision,  cogniEonHeadphone Hearing,  cogniEonSpeak  text Low  vision,  cogniEonVoice  input Blind,  low  vision,  cogniEon,  mobilityExternal  &  virtual  keyboards Blind,  mobilityCapEoning Deaf,  cogniEonAudio  descripEon Blind,  low  visionAccessibility  sePngs  &  supportDiscoveryTuesday, 21 May 13
    • iOS  Accessibility  features  and  API  are  the  most  matureAndroid  has  some  good  accessibility  features  Google  are  working  to  improveCurrent  market  share  favours  iOS  and  Android  devices  over  other  vendorsBlackBerryCurve  smartphones  have  free  BlackBerry  Screen  ReaderSymbian  Phones  have  accessibility  features,  including  text-­‐to-­‐speech,  but  pla@orm  currently  has  no  accessibility  API.Windows  Phone  8Phones  appears  to  have  accessibility  features  but  no  accessibility  API25Mobile  accessibility  landscapeDiscoveryTuesday, 21 May 13
    • Se[ng UserVoiceover Blind,  low  vision,  learning  and  cogniEonZoom,  Large  Text Blind,  low  vision,  learning  and  cogniEonInvert  colours Low  vision,  colour  blindness,  learning,  cogniEonSpeak  selecEon Low  vision,  learning  and  cogniEonSpeak  auto-­‐text Blind,  low  vision,  learning  and  cogniEon  Hearing  aid  mode Deaf,  hard  of  hearing,  deaf  blindGuided  access Everybody  including  children  &educaEonAssisEve  touch MobilityiOS  accessibility  sePngs  DiscoveryTuesday, 21 May 13
    • Speech  output  Available  in  36  languagesSupports  zoom  and  VoiceOveriOS6  +Gesture  and  explore  by  touchSupports  Braille  output27iOS  VoiceOverDiscoveryTuesday, 21 May 13
    • 1. Triple  click  the  Home  key  to  acEvate2. Dial  to  open  the  Web  Rotor3. Swipe  up/down  to  navigate  parts4. Swipe  right/led  for  next/previous  content28iOS  VoiceOverDiscoveryTuesday, 21 May 13
    • Explore  by  touchDrag  finger  across  screenItems  read  by  VODouble  tap  to  acEvateGesturesSwipe  up/down  to  jump  secEonsSwipe  right/led  for  next/previous  contentRotorWeb  and  Apps:  Lines,  Links,  Form  Controls,  Tables,  Lists,  Landmarks,  Non-­‐Visited  Links,  Bugons,  Text  Fields,  Images,  StaEc  Text,  Zoom,  In-­‐page  links,  Search  Fields,  Same  Item,  Headings,  Speech  Rate,  Volume,  Hints  (on/off),    Characters,  Words,  VerEcal  NavigaEon,  PunctuaEonApps:  Headings,  Speech  Rate,  Volume,  Hints  (on/off),    Characters,  Words,  VerEcal  NavigaEon,  PunctuaEon29Naviga=ng  with  iOS  VoiceOverDiscoveryTuesday, 21 May 13
    • 30iOS  VoiceOver  gesturesGesture Func)onSwitch  VO  on/off Triple  click  the  home  keySpeak  an  element Single  tappAcEvate  an  element Double  tapOpen  the  Rotor Turn  a  dialZoom 3  finger  double  tap  -­‐  iOS6+  onlyNext  secEon  in  Rotor Swipe  up/downNext/previous  item  in  content  order Swipe  right/ledPass  through  gesture  (drag  &  drop) Double  tap  holdPlay/Pause 2  finger  double  tapDiscoveryTuesday, 21 May 13
    • 313  finger  triple  tapScreen  curtainTuesday, 21 May 13
    • 32iOS  clipDiscoveryTuesday, 21 May 13
    • Se[ng UserVoice  output Blind,  low  vision,  learning  and  cogniEonHapEc  feedback Blind,  Deaf-­‐Blind,  Low  vision,  deafLarge  text Low  vision,  cogniEon,  learningSpeak  passwords Blind,  low  vision,  cogniEon,  learningEnhance  web  accessibility BlindAndroid  accessibility  sePngsDiscoveryTuesday, 21 May 13
    • Force  enable  zoomText  sizeText  scalingZoom  on  double-­‐tapMinimum  font  sizeInverted  coloursContrastA  useful  ‘screen  curtain’  equivalentShades  app  can  also  do  this34Android  na=ve  browser  sePngsDiscoveryTuesday, 21 May 13
    • NaEve  browser  (Webkit)Poor  support  for  screen  readersIdeal  Web  ReaderSelf  voicing  thin  clientBrowser,  text  messages,  contacts,  phoneChrome  (4+)Zoom  on  linksForce  enable  zoomFirefoxQuick  navigaEon  keysFind  in  page35Browsers  on  AndroidDiscoveryTuesday, 21 May 13
    • Quick  navigaEon  keysRequires  a  physical  keyboard,  bluetooth  connected  or  Eyes-­‐free  keyboardArrow  around  browser  contentDon’t  work  with  the  browser  UIDon’t  work  when  focus  is  on  entry  or  password  field  in  a  formExplore  by  touch  also  supported36Firefox  on  AndroidDiscoveryTuesday, 21 May 13
    • SupportGingerbread  2.3-­‐    very  basicIce  Cream  Sandwich  4.0  a  bit  beYerJelly  Bean  4.1+  much  beYerScreen  readersTalkBackSpielMobile  SpeakMobile  ReaderAll  available  from  the  Play  Store37Speech  output  on  AndroidDiscoveryTuesday, 21 May 13
    • Pre  Ice  Cream  Sandwich  Download  TalksEnable  WebScripts  via  Settings >Accessibility > ‘Enable Accessibility’Download  the  Eyes  Free  KeyboardBrowsingVoice  output  sEll  not  well  supportedCan  use  Firefox  for  tesEngApplicaEonsTalkback  well  supportedBeware  hybrid  contentMaps,  adverts,  Terms  and  CondiEons,Help  pages    etc38Naviga=ng  with  Android  TalkbackDiscoveryTuesday, 21 May 13
    • 39Android  clipDiscoveryTuesday, 21 May 13
    • Play)me!40iOSTriple  click  the  Home  KeySe[ngs  >  General  Accessibility  >VoiceOver  ONAndroidSe[ngs  >  Accessibility  >  Talkback  onTuesday, 21 May 13
    • How41Tuesday, 21 May 13
    • Mobile  websiteA  separate  mobile  WebsiteDifferent  user  experience  -­‐  good  or  bad  thing?Responsive  websiteA  site  that  adapts  screen  size  and  contentWidest  potenEal  reachNaEve  appPla@orm  specific  applicaEonsBenefits  from  device  capabiliEesMay  contain  Web  contentBeger  accessibility  supportHybridNaEve  and  WebEasier  to  maintain 42DeliveryDiscoveryTuesday, 21 May 13
    • Stand-­‐alone  mobile  apps  will  only  be  considered  once  the  core  web  service  works  well  on  mobile  devices,  and  if  specifically  agreed  with  the  Cabinet  Office.UK  Government  Digital  StrategyWe  are  not  ‘appy,  not  ‘appy  at  all43Tuesday, 21 May 13
    • No  internaEonally  accepted,  independent  set  of  guidelines(a  la  WCAG)  for  mobileFragmentaEon  within  mobileNo  ‘Baseline  browser’  support  for  mobileMobile  Web  Best  PracEces  agempted  it  with  the  Default  Delivery  ContextUsable screen width - 120 pixels, minimum.Markup language support - XHTML Basic 1.1Character encoding - UTF-8Image format support - JPEG GIF 89a.Maximum total page weight - 20 kilobytes.Colours - 256 colours, minimum.Style Sheet Support - CSS Level 1 and CSS Level 2 @mediaScripts - No support for client side scripting.44Guidelines  and  resourcesDiscoveryTuesday, 21 May 13
    • W3C  WAIMobile  Web  Best  PracEces  (MWBP)Web  Content  Accessibility  Guidlines  (WCAGShared  experiences:  Barriers  common  to  mobile  device  users  and  people  with  disabiliEesMobile  Accessibility  OverlapMapping  between  MWBP  and  WCAGIndependant  User  Interface  (Indi  UI)  Working  Group-­‐  Indie  Events  1.0-­‐  Indie  UI  User  Context  1.0AndroidAndroid  UI  accessibilityAndroid  Design  Pagerns  AccessibilityAndroid  Training:  ImplemenEng  AccessibilityAndroid:  Developing  Accessible  ApplicaEonsGoogle  Eyes  Free  Project45Guidelines  and  resourcesDiscoveryTuesday, 21 May 13
    • iOSiOS  Human  Interface  GuidelinesAccessibility  for  iPhone  and  iPad  apps  by  Mag  GemmalNokiaNokia  user  experience  for  touch  checklist  (PDF)Nokia  user  experience  checklist  for  keyboardWindows  MobileDesign  Guidelines  for  Windows  MobileTouch  InteracEon  DesignOrganisaEonalFunka.nuBBC  Mobile  Accessibility  Guidelines46Guidelines  and  resourcesDiscoveryTuesday, 21 May 13
    • Challenges2010  Products  developing  in  silosNo  globally  accepted  guidelinesBBC  Accessibility  Standards  and  Guidelines  didn’t  cover  mobile  or  appsMobile  more  divers  and  faster  changing  than  desktopNo  graded  mobile  browser  support  (Yahoo!  and  BBC)EvoluEonTechnology  specific  guidelines  vs  technology  agnosEc  guidelinesBuilt  around  how  teams  workBuilt  to  cross  reference  BBC  Global  Experience  guidelines  and  Editorial  GuidelinesBenefitsConsistency  across  productsConsistency  across  Web,  Hybrid  and  NaEve  appsBeger  labelling47BBC  Mobile  Accessibility  GuidelinesDiscoveryTuesday, 21 May 13
    • 71  technology  agnosEc  standards  and  guidelinesStandard  =  testableGuidelines  =  not  easily  tested,  aspiraEonalTechnology  specific  techniques  and  examplesHTMLAndroidiOSEvaluaEon  criteriaStepsVerificaEon  criteria48BBC  Mobile  Accessibility  GuidelinesDiscoveryTuesday, 21 May 13
    • Define  a  delivery  contextMobile  site,  responsive,  app,  hybridDefine  supported  devicesReference  pre-­‐exisEng  test  plansWhat  devices  have  accessibility  support?What  devices  have  accessible  naEve  browsers?What  devices  are  easy  to  upgrade/free  assisEve  supportAre  any  accessible  devices  missing?Establish  version  support  matrixAnalyse  web  stats%  users  <  than  1%Assess  regional  preferencesAssess  lawsLocallyGloballyResearch  user  preferences 49Device  support  planDiscoveryTuesday, 21 May 13
    • BBDecision  Tree  for  Degrada=on  of  Browser  Versions,  BBC  Browser  support  Guidelines  50Browser  supportTuesday, 21 May 13
    • 51Webaim  Screen  Reader  Survey  2012DiscoveryTuesday, 21 May 13
    • 52Webaim  Screen  Reader  Survey  2012DiscoveryiOS  device  usage  is  significantly  increasing  and  well  abovethe  standard  populaEonScreen  reader  users  represent  a  notable  porEon  of  the  iOS  device  user  marketUsage  of  Android  devices  is  well  below  that  of  non-­‐disabled  userIn  the  past  17  months:iOS  devices  increased  from  32.6%  to  58.5%Android  usage  increased  slightly  from  4%  to  7.9%Nokia  device  usage  fell  drasEcally  from  42.4%  to  20.3%Tuesday, 21 May 13
    • 53LawDiscovery21st  Century  Act,  USA.  By  2013  smartphones:must  have  an  accessible  browsermust  be  accessible  at  the  OS  levelmust  have  free  or  of  “nominal  cost”  soluEonsImplicaEonsNorth  American  mobile  market  influenEal  globally  Apple,  Google,  Microsod,  RIMSecEon  508  Refresh‘informaEon  and  communicaEon  technology’  must  be  WCAG  2.0  compliantTuesday, 21 May 13
    • Breakout  session:Put  together  a  Mobile  Accessibility  Strategy1.  What  mobile  devices,  plaEorms  and  access  tech  would  you  support?2.  How  would  you  maintain  and  keep  this  up  to  date?54Tuesday, 21 May 13
    • 55Discovery  Design  &  Build  Deploy  Tuesday, 21 May 13
    • 56Responsive  design  and  accessibility‘Responsive’ means design and development shouldrespond to the person’s behaviour and environment based onscreen size, platform and orientation.By  definiEon  accessibility  should  be  complemented  by  responsive  design.  What  do  you  think  the  benefits  of  responsive  design  are  on  desktop?  Design  &  BuildTuesday, 21 May 13
    • 57Responsive  design  overviewResponsive  designCreates  a  core  experienceAllows  content  and  funcEonality  to  adapt  to  screen  size  and  device  capabilityUses  CSS3  media  queries  to  enhance  fluid  layoutsOne  code  baseEasier  to  maintainBeger  consistency,  familiarity  and  ease  of  useGenerally  more  task  based  =  geared  towards  diverse  usersProgressive  enhancementMobile  firstData  driven  designCore  content  is  HTML,  HTML5Design  &  BuildTuesday, 21 May 13
    • 58Responsive  design  overviewUse  Web  Standards  as  intendedSupports  accessibilitySupports  interoperabilityFor  example  code  a  bugon  as  a  bugon  not  a  styled  linkScreen  readers  announce  traits  i.e.  bugons,  link,  image  etcUser  expectaEon  is  a  link  opens  a  resource,  a  bugon  triggers  an  acEonOn  Desktop  ENTER  is  used  for  links,  SPACEBAR  for  bugonsUse  standard  controls  over  custom  implementaEonsVulnerable  to  accessibility  failures  e.g.  incorrect  traitsMay  require  non  standard  user  input  which  leads  to  usability  fails  for  diverse  usersDetect  features,  not  devicesDesign  &  BuildTuesday, 21 May 13
    • 59www.caniuse.com/waiariaTuesday, 21 May 13
    • 60www.caniuse.com/#cats=HTML5Tuesday, 21 May 13
    • 61Responsive  design  overview“Cu[ng  the  mustard”  (BBC  Responsive  news)Impossible  to  test  across  all  browsers  on  desktop  and  devicesHard  to  keep  up  -­‐  mobile  contracts  update  every  12-­‐18  monthsNew  browsers  come  in  to  play  every  dayWebsites  accessed  globallyDesign  &  BuildHTML5  browsersIE9+Firefox  3.5+Opera  9+Safari  4+Chrome  1+(?)iPhone  and  iPad  iOS1+Android  phones  and  tablets  2.1+Blackberry  OS6+Windows  7.5+Mobile  Firefox  (all  versions?)Opera  Mobile  (most  versions?)HTML4  browsersIE8-­‐Blackberry  OS5-­‐Nokia  S60  v6-­‐Nokia  S40  (all  versions)All  other  Symbian  variantsWindows  7  phone  (pre-­‐Mango)…and  many  more  that  are  too  numerous  to  men=onTuesday, 21 May 13
    • 62iOS  development  overviewUse  standard  UIKit  componentsAutomaEcally  accessible  to  VoiceOverTraits  pre-­‐assignedHints,  where  necessary,  pre-­‐assignedOnly  need  to  customise  the  labelUIKit  components  offer  roughly  80%  accessibility.  The  other  20%  is  very  much  around  making  what  is  accessible  usableProgressively  enhance  with  new  accessibility  features  in  later  versions  Design  &  BuildTuesday, 21 May 13
    • 63iOS  development  overviewInterface  Builder,  accessibility  panelAllows  you  to  enable  accessibilityAdd  labels,  traits  and  hints  Design  &  BuildTuesday, 21 May 13
    • 64Android  development  overviewUse  standard  library  componentsAutomaEcally  accessible  to  TalkBackCorrectly  idenEfiedOnly  need  to  customise  the  label  Design  &  BuildTuesday, 21 May 13
    • 65Principles  of  mobile  accessibility  (BBC)Provide  core  content  in  an  accessible  websiteUse  apps  on  top  of  thisUse  web  and  pla@orm  standards  as  intendede.g.  code  links  as  links,  not  bugonsUse  standard  components  NaEvely  accessibleUse  progressive  enhancementSupport  lower  end  devicesEnhance  apps  with  accessibility  improvements  in  device  version  updatesBe  consistent  and  conEnuosWithin  reason,  respect  the  delivery  contextLabelsDesign  &  BuildTuesday, 21 May 13
    • 66Android  design  principles Design  &  BuildEnchant  meDelight  me  in  surprising  waysReal  objects  are  more  fun  than  buYons  and  menusLet  me  make  it  mineGet  to  know  meSimplify  my  lifeKeep  it  briefPictures  are  faster  than  wordsDecide  for  me  but  let  me  have  the  final  sayOnly  show  what  I  need  when  I  need  itI  should  always  know  where  I  amNever  lose  my  stuffIf  it  looks  the  same  it  should  act  the  sameOnly  interrupt  me  if  it’s  importantMake  me  amazingGive  me  tricks  that  work  everywhereIt’s  not  my  faultSprinkle  encouragementDo  the  heavy  liiing  for  meMake  important  things  fastTuesday, 21 May 13
    • 67iOS  Human  Interface  Principles Design  &  BuildAesthe=c  IntegrityAesthe=c  integrity  is  not  a  measure  of  how  beau=ful  an  app  is.  It’s  a  measure  of  how  well  the  appearance  of  the  app  integrates  with  its  func=on.ConsistencyConsistency  in  the  interface  allows  people  to  transfer  their  knowledge  and  skills  from  one  app  to  another.  A  consistent  app  is  not  a  slavish  copy  of  other  apps.Direct  manipulaEonWhen  people  directly  manipulate  onscreen  objects  instead  of  using  separate  controls  to  manipulate  them,  theyre  more  engaged  with  the  task  and  they  more  readily  understand  the  results  of  their  ac=ons  (mul=touch)hYp://developer.apple.com/library/ios/#documenta=on/userexperience/conceptual/mobilehig/Principles/Principles.htmlTuesday, 21 May 13
    • 68iOS  Human  Interface  Principles Design  &  BuildFeedbackFeedback  acknowledges  people’s  ac=ons  and  assures  them  that  processing  is  occurring.  People  expect  immediate  feedback  when  they  operate  a  control,  and  they  appreciate  status  updates  during  lengthy  opera=ons.MetaphorsWhen  virtual  objects  and  ac=ons  in  an  app  are  metaphors  for  objects  and  ac=ons  in  the  real  world,  users  quickly  grasp  how  to  use  the  appUser  controlPeople,  not  apps,  should  ini=ate  and  control  ac=ons.  Although  an  app  can  suggest  a  course  of  ac=on  or  warn  about  dangerous  consequences,  it’s  usually  a  mistake  for  the  app  to  take  decision-­‐making  away  from  the  user.Tuesday, 21 May 13
    • 69Alterna=vesNeeded  forImages,  objects,  elementsMedia  e.g.  capEons,  audio  descripEon,  transcriptsEditorialShort,  concise,  descripEveImportant  informaEon  firstAvoid  similar  alternaEves  for  different  funcEonality  e.g.  ‘Play’  and  ‘Playlist’FuncEon  over  content  e.g.  ‘Contact  us’  not  ‘Picture  of  a  mobile  phone’Describe  image  type  if  appropriate  ‘Portrait  of...’  ‘Cartoon  of...’OwnershipEditorialMarkeEng  -­‐  this  is  branding  ader  allDesign  &  BuildTuesday, 21 May 13
    • 70Alterna=ves  &  HTMLAlways  provide  an  alt  agributealt=”Super useful alt text provided by marketing noless!”alt=”” ensures  image  is  ignored  by  assisEve  techtitle  and  abbrDesktop  Unavailable  to  some  screen  readers  on  desktopUnavailable  to  keyboard  only  usersMobileUnavailable  visually  on  touchNot  recognised  by  speech  output  on  mobileDesign  &  BuildTuesday, 21 May 13
    • 71Alterna=ves  &  AndroidAssign  contentDescription  to  all  user  interface  components  e.g.  ImageButtonImageViewCheckBoxDecoraEve  images  should  not  have  contentDescriptionDesign  &  BuildTuesday, 21 May 13
    • 72Alterna=ves  &  iOSImplement  basic  accessibilityOn  all  meaningful  content  and  funcEonalityEnables  VoiceOver  to  voice  and  interact  with  the  elementvia  xCodea.  Call  the  view’s  setter  method  setIsAccessibilityElement:YESb.  Override  the  view’s  isAccessibilityElement  method  and  return  YESvia  Interface  Builder,  Accessibility  Panela.  Select  the  objectb.  Check  “Accessibility  –  Enabled”  c.  Assign  a  LabelDesign  &  BuildTuesday, 21 May 13
    • 73Alterna=ves  &  iOSAssign  accessibilityLabel  to  all  user  interface  components  Must  start  with  a  capitalMust  not  end  with  a  period  (.)Must  not  include  informaEon  about  the  type  of  object  i.e.  ‘Play’  not  ‘Play  bugon’Design  &  BuildTuesday, 21 May 13
    • 74Alterna=ves  &  iOSAssign  accessibilityTrait  to  all  user  interface  componentsTraits  describe  control  type  or  behaviourControl  types  are  mutually  exclusive  and  describe  the  nature  of  the  itemMore  than  one  behaviour  trait  can  be  used  to  describe  what  items  doDesign  &  BuildTuesday, 21 May 13
    • Trait DescripEonBugon Used  for  acEons  i.e.  Play,  Add,  Download,  FavouriteLink Use  to  open  views,  pages  resourcesSearch  field SearchKeyboard  key Used  on  controls  which  insert  predefined  text  for  exampleiOS  traits  for  Type Design  &  BuildTuesday, 21 May 13
    • 76BuYons  or  links? Design  &  BuildTuesday, 21 May 13
    • Trait DescripEonStaEc  text Text  that  is  readable  but  not  selectableImage If  image  is  interacEve  combine  with  Bugon  or  LinkPlays  sound Used  with  bugon  traits,  mutes  of  reduces  VO  volume  Selected Used  on  checkboxes,  status  read  by  VOSummary  element Describes  situaEon  or  state  when  an  app  starts,  use  sparinglyUpdates  frequently Download  progress  bars,  bufferingNot  enabled Indicates  item  is  not  currently  interacEveStarts  media  session Silences  Voiceover,  used  when  recordingAdjustable Sliders  e.g.  volume  and  Emeline,  hint  includediOS  traits  for  BehaviourTuesday, 21 May 13
    • Item DescripEon UsageMagic  tap  accessibilityPerformMagicTapTwo  finger  double  tap  to  perform  a  key  acEon  i.e.  Pause/PlayTrigger  play  from  programme  views,  answer  a  callHeaderaccessibilityTraitHeaderTurn  text  into  headings.  Previously  only  view  headings  idenEfied  as  headingsAdd  headings  throughout  ALL  pagesFocusaccessibilityLayoutChangedNoEficaEon  (or  Screen)Set  focus  on  anything  other  than  first  item  in  content  orderSet  focus  on  the  heading  and  NOT  the  Back/Done  bugonsAnnouncementaccessibilityAnnouncmentForce  VO  to  say  something  when  an  acEon  is  completeVisual  cue  also  needed  as  an  alternaEve  for  non  VO  usersGroupingshouldGroupAccessibilityChildrenGroping  related  items   Parent  child  relaEonshipsiOS  traits  for  BehaviourTuesday, 21 May 13
    • 79Alterna=ves  &  HintsaccessibilityHints  may  be  used  to  provide  further  informaEonDescribes  what  an  element  doesMust  not  include  informaEon  about  the  objects  type  (i.e.  Trait)Use  sparingly  and  not  for  key  informaEonMust  be  a  descripEon  not  a  command  e.g.  ‘Deletes  programme’  not  ‘Delete  programme’Design  &  BuildTuesday, 21 May 13
    • 80Label:"Done,"back"to…."Trait:"Bu1on"Label:"[Program"name,"Episode"number]"Trait:"Sta>c"text"Label:"Sub>tles"On/Off"Trait:"Bu1on"Label:"Enter/Exit"Full"screen"Trait:"Bu1on"Label:"Play"/Pause"Trait:"Bu1on"Label:"["00.07"of"59.37"]"swipe"up"or"down"to"adjust"Trait:"Adjustable"Label:"Show/Hide"more"Trait:"Bu1on"iOS  Labels,  Hints  &  Traits Design  &  BuildTuesday, 21 May 13
    • 81Tests  -­‐  alterna=vesTest01  Switch  on  speech  output02  Navigate  to  images,  elements  and  objects  either  by02.1  Explore  by  touch  (Android/iOS)  *02.2  SelecEng  Images/bugons  from  the  Web  Rotor  and  swiping  up/down  (iOS)*03  Verify  an  alternaEve  is  provided04  Verify  the  alternaEve  accurately  describes  the  content  or  funcEonExpected  resultsEach  meaningful  images  element  and  object  has  an  alternaEveAlternaEves  describe  either  the  content  of  a  non-­‐funcEonal  image,  element  or  objectthe  funcEon  of  an  acEonable  image,  element  or  objectDesign  &  BuildTuesday, 21 May 13
    • 82Colour  &  ContrastWhat  is  an  appropriate  contrast  raEo  for  mobile?WCAG  AA    contrast  of  4.5:1MWBP  Default  Delivery  Context  -­‐  256  colour  minimumNokia  design  guidelines  5:1BBC  Mobile  Accessibility  Guidelines  exceed  WCAG  AA,  close  to  AAA,  7.1Challenge  for  RWDContrast  raEo  of  7.1  v’s  brand  and  markeEngWorks  beger  on  devices  than  desktop  -­‐  considered  too  restricEveIndicaEng  links  with  colour  Design  &  BuildTuesday, 21 May 13
    • 83Tests  -­‐  colour  contrastTest  01  Select  samples  of  text  and  links  by01.1  Checking  contrast  during  UX  (see  0.3)01.2  Taking  a  screenshot  (Home+power  bugon  on  iOS/  Power  and  volume  bugon  on  Android)  and  email  or  syncing  the  picture  to  a  desktop  Analyser.03  Verify  the  luminosity  and  contrast  requirements  are  met  via  the  Colour  Contrast  Analyser*Expected  results01  Contrast  between  text  and  background  meet  minimum  colour  contrast  (luminosity)  raEo  requirements  indicated  by  the  requirements*  Any  colour  contrast  checker  can  be  used  but  only  one  used  as  a  benchmarkDesign  &  BuildTuesday, 21 May 13
    • 84Colour  &  MeaningProvide  alternaEves  for  colour  and  meaningVisuallyFont  weightLine  weightBordersGradientsArt  styleColour  intensitySubtle  animaEonsAudiblyAnnounce  changes  of  state  Design  &  Build“Selected,  TV,  tab,  one  of  5”Tuesday, 21 May 13
    • FirefoxMobile  SafariColour  &  Meaning Design  &  BuildTuesday, 21 May 13
    • FirefoxMobile  SafariColour  &  Meaning Design  &  BuildTEST  ON  REAL  DEVICES!Tuesday, 21 May 13
    • 87Tests  -­‐  colour  &  meaningTest  01  AcEvate  speech  output  /  invert  colours02  Locate  images,  objects  and  elements  that  use  colour03  Determine  if  colour  is  the  sole  means  of  communicaEng  informaEon04  Verify  speech  output  announces  the  meaning  conveyed  with  colourthere  is  an  alternaEve  visual  means  of  indicaEng  meaningExpected  resultsColour  used  to  convey  meaning  is  announced  by  screen  readersColour  used  to  convey  meaning  is  indicated  visually  without  colour  Design  &  BuildTuesday, 21 May 13
    • 88TouchStandard  touch  target  size  of  7-­‐10mmJacob  Neilson  recommends  9.2  -­‐  9.6mmAndroidTouch  target  size  of  48dp/9mmSpacing  between  UI  elements  8dpiOSTouch  target  size  of  44px  /  44px  tallPosiEoningProvide  1mm  inacEve  space  around  elementsBalance  enough  informaEon  density  and  targetability  of  UI  ElementsPosiEon  content  appropriatelyDesign  &  BuildAndroidTuesday, 21 May 13
    • 89Tests  -­‐  touch  target  sizeTest01  IdenEfy  touch  targets02  Measure  size03  Verify  the  size  meets  the  requirementsExpected  resultsAll  touch  targets  meet  or  exceed  the  minimum  requirementWhen  should  this  test  be  carried  out?Design  &  BuildTuesday, 21 May 13
    • 90TouchSpacing  and  read-­‐tap  symmetryBalance  informaEon  density  and  targetability  of  UI  ElementsSpacing  between  groups  of  linkse.g.  www.bbc.co.uk/tvDesign  &  BuildMobileDesktopTuesday, 21 May 13
    • 91TouchGroup  links  to  the  same  resourceLarger  touch  zoneLess  audible  repeEEon  for  screen  reader  usersLess  swiping  needed  =  less  physical  overheadDesign  &  BuildTuesday, 21 May 13
    • 92TouchGrouped  links  with  HTMLTreated  inconsistently  by  screen  readersSome  only  announce  the  first  elementSome  only  announce  the  headingDepends  on  reading  mode  (tabbing,  read  all,  arrowing)Main  concern  is  VoiceOver  repeats  the  link  Basic  rule:  place  key  informaEon  firstAccessibility  and  HTML5  block  level  links  -­‐  Simply  AccessibleDesign  &  Build<a href="http://feathermelbourne.eventbrite.com/"><h3 class="summary">Melbourne</h3>! <span><em>Supported by WIPA</em></span>! <span>July 25, 2011</span>! <span class="button">Purchase Tickets</span>! <img src="star.png" title="Melbourne" alt="" /></a>Tuesday, 21 May 13
    • 93Tests  -­‐  Grouped  linksTest01  AcEvate  the  screen  reader02  Navigate  to  acEve  screen  objects,  elements,  and  controls  that  have  textual  and  image  components03  Verify  that  the  text  is  not  announced  twice04  Verify  that  there  are  not  two  equivalent  acEonable  items  announced  for  each  itemExpected  resultsObject,  elements,  and  controls  with  images  and  text  labels  are  announced  only  togetherDesign  &  BuildTuesday, 21 May 13
    • 94TouchConsider  reachOne  handedImportant  content  bogom  led  to  rightDesign  &  BuildLuke  Wroblewski’s  book  Mobile  FirstTuesday, 21 May 13
    • 95Best  PracLces:  Designing  Touch  Tablet  Experiences  for  Pre  SchoolersSource:  hYp://www.sesameworkshop.org/assets/1191/src/Best%20Prac=ces%20Document%2011-­‐26-­‐12.pdfTuesday, 21 May 13
    • 96Touch  -­‐  most  intui=ve  gesturesTapUniversally  familiarDraw  /  Move  fingerSomeEmes  hard  not  to  lid  a  fingerCan  also  support  parEal  compleEonSwipeProvide  visual  indicaEons  of  where  to  swipeConsider  using  swipe  and  tap  on  an  arrow  Design  &  BuildxxxxTuesday, 21 May 13
    • 97Touch  -­‐  most  intui=ve  gesturesDragPossible  difficulEes  with  on-­‐screen-­‐finger-­‐conEnuityCan  support  parEal  compleEonSlideLess  familiar  than  draggingNeeds  explicit  instrucEons  e.g.,  VO,  strong  visual  indicaEon  of  end  point,  a  large  hotspot,  supporEve/explicit  highlighEngDesign  &  Build“Familiar  faces  to  take  you  new  places”Tuesday, 21 May 13
    • 98Touch  -­‐  least  intui=ve  gesturesPinchNeeds  good  dexterityUse  it  on  non-­‐essenEal  acEonsTilt/ShakeTablet  size  and  weight  make  it  hard  to  controlLimit  it  to  smaller  devicesMulE-­‐Touch  MulEple  fingers  on  screen  at  onceOden  used  unintenEonally,  limited  dexterityFlick/FlingUse  interchangeably  with  tap/and  or  dragDouble  TapChildren  expect  immediate  responseUse  it  to  prevent  accidental  navigaEon  e.g.  leaving  an  acEvityDesign  &  BuildTuesday, 21 May 13
    • 99ZoomSupport  pinch  zoomAvoid<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  orienta=on  Jeremy  KeithDesign  &  BuildTuesday, 21 May 13
    • 100Structure  and  content  orderAndroidNo  means  (that  I  am  aware  of)  to  indicate  headings,  lists  etcContent  order  needs  to  be  hard  codediOSiOS  3  -­‐  5  only  the  screen  Etle  was  announced  as  a  headingiOS  6  accessibilityTraitHeaderContent  order  handled  naturally  but  can  be  hard  codedHTMLStructure  and  content  order  are  a  core  component  accessibility  Same  rules  as  desktopDesign  &  BuildTuesday, 21 May 13
    • 101Structure  and  content  orderHeadings  and  listsH1  to  H6OL  and  ULNavigaEon  to  headings  and  the  start  of  lists  for  screen  readersSeven  plus  or  minus  2The  opEmum  number  humans  process  informaEonIn  taxonomy  this  translates  to  5-­‐9  headingsHeadings  as  listsContent  under  a  heading  may  be  removed  on  mobileConsider  lists  over  headingsAvoid  mixing  bothDesign  &  BuildTuesday, 21 May 13
    • 102Structure  and  content  orderWAI  ARIA  Landmarksapplication, banner, complementary,contentinfo, form, main, navigation,searchNavigaEon  to  parts  of  a  page,  for  screen  readerHTML5  secEoning  elementsbody, section, nav, article, aside,hgroup, header, footer, address,mainNot  well  supported  by  desktop  or  mobile  screen  readersDesign  &  BuildTuesday, 21 May 13
    • 103Structure  and  content  orderScreen  readers  announce  Landmarks  differentlyJaws“NavigaEon  region  start”  /  “NavigaEon  region  end”NVDA  2012.3“NavigaEon  region  start”  nothing  at  the  endiOS  VoiceOver“Landmark  start”  /  “Landmark  end”  but  announces  next  item  in  the  content  orderTalkBack“NavigaEon”  but  nothing  at  the  endDesign  &  BuildTuesday, 21 May 13
    • content  a  logical  order  provide104Tuesday, 21 May 13
    • provide  a  logical  content  order105Don’t  make  your  content  sound  like  YodaTuesday, 21 May 13
    • 106Iden=fy  LandmarksContent  orderPlace  Landmarks  before  the  relevant  headingHeading  can  be  visible  or  hiddenaria-­‐label  <role="navigation" aria-label="Channels">Design  &  BuildTuesday, 21 May 13
    • 107Responsive  landmarksTuesday, 21 May 13
    • 108Responsive  landmarksTuesday, 21 May 13
    • 109Landmarks  &  collapsed  naviga=onClosed                                                                          OpenDesign  &  BuildVoiceOver  /  TalkBack  says:  “Landmark  start,  Channels  navigaFon,  Open  Menu,  BBC  One,  BBC  Two,  BBC  Three,  BBC  Four,  TV  Guide,  A-­‐Z,  Categories,  Arts,  CBBC...”Tuesday, 21 May 13
    • 110Landmarks  &  collapsed  naviga=onClosed                                                                          OpenDesign  &  Buildleft: -999em;position: absoluteVoiceOver  /  TalkBack  says:  “Landmark  start,  Channels  navigaEon,  Open  Menu”  or  “Open  Menu”Tuesday, 21 May 13
    • 111Structure  and  content  orderConsideraEons  for  responsiveStructure  originates  with  UX  (or  we  might  as  well  all  go  home...)Mobile  first  -­‐  adding  in  is  easier  than  subtracEngBalance  informaEon  and  verbosityAnnotate  UX  Headings,  lists,  landmarksContent  and  focus  orderKeyboard  /  swipe  interacEonFocus  statesSummaryAn  H1  follows  role=“main”  and  the  main  content  follows  an  H1An  H2/3/4 follows  role=“complementary”An  H2 (3/4) follows  role=“navigation”Duplicated  links  grouped  in  one  <a href>Design  &  BuildTuesday, 21 May 13
    • 112Responsive  naviga=onOne  Responsive  BarlesqueBBC  Framework  including  the  header  and  footerDesign  &  BuildTuesday, 21 May 13
    • 113Responsive  naviga=on  -­‐  case  study  StructureLandmarks  -­‐  Banner,  NavigaEon  and  SearchHidden  headings  -­‐  H2  Accessibility  links,  H2  BBC.co.uk  navigaEonVisible  focusStrong,  branded  visible  focusDesign  &  BuildTuesday, 21 May 13
    • 114Responsive  naviga=onIssuesSearch  repeated  3  times  -­‐  landmark,  label,  placement  text“BBC.co.uk  navigation”  makes  no  senseDesign  &  BuildTuesday, 21 May 13
    • 115Responsive  naviga=onMore  panelAdded  hidden  span  to  “More”  i.e.    “Open  More  BBC  sites”  /  “Close  More  BBC  sites”Set  focus  to  first  item  in  the  list  “TV”Panel  remains  open  until  closedMore  is  an  H2  inside  the  panelDesign  &  BuildTuesday, 21 May 13
    • 116Responsive  skip  linksDo  they  have  a  place  on  mobile?On  touch  screens  they  feel  redundantNot  necessary  for  collapsable  navigationPossibly  necessary  on  keypad  devicesDesign  &  BuildTuesday, 21 May 13
    • 117Clear  naviga=onPage  Etles  content  or  purpose  of  the  screenAct  as  a  reverse  breadcrumbAvoid  Done/BackDesign  &  Build231YouTube  iOS  AppTuesday, 21 May 13
    • 118FormsUse  programmaEcally  readable  instrucEonsAdd  ‘required’  to  the  <label><label for="name">Your Name (required)</label>Progressively  enhance  with  HTML  <input type=“text required>(iOS5+)Using  both  techniques  do  not  result  in  ‘required’  being  read  twiceDesign  &  BuildTuesday, 21 May 13
    • 119Keyboard  focusDon’t  forget  keyboard  users,  D-­‐Pad  users  and    external  keyboard  usersHTMLProvide  a  logical  code  orderPosiEve  and  negaEve  tab  order  not  well  supported  on  iOS  and  AndroidBe  aware  of  this  for  responsive  sitesDesign  &  BuildTuesday, 21 May 13
    • 120Keyboard  focus  -­‐  AndroidEnable  focus-­‐based  navigaEon  on  components:android:focusable="true”setFocusableisFocusableRequestFocusForce  focus  order  if  it  is  not  logical:nextFocusDownnextFocusLeftnextFocusRightnextFocusUpDesign  &  BuildTuesday, 21 May 13
    • 121Keyboard  focus  -­‐  visibleiOSNo  means  of  providing  a  focus  (that  I’m  aware  of)AndroidProvided  by  default  for  standard  controlsMust  be  added  to  custom  controls  using  style  sheetsstate_focused=“true”HTML,  think  ‘focus’  firsta:hover, a:focus, a:active {   background-color: #ff9;}Design  &  BuildTuesday, 21 May 13
    • 122No=fica=onsNoEficaEon  may  be  necessary  due  toLayout  changesContent  removal  due  to  orientaEon  changes  i.e.  a  menu  opens  in  LayoutList  of  links  may  change  to  drop  downsUse  standard  platform  notificationsFamiliar  behaviour  across  appsBaked  in  accessibilityEnsure  there  are  both  visual  and  audible  notificationsHowOnly  notify  the  user  if  changes  are  not  self  evidentARIA  announcementsSystem  alertsiOS  -­‐  UIAccessibilityLayoutChangedNotificationAndroid  -­‐  update  the  contentDescriptionDesign  &  BuildTuesday, 21 May 13
    • 123Screen  reader  detec=onDetect  if  a  screen  reader  is  runningHide  content  specifically  for  sighted  users  i.e.  splash  screen  instrucEonsServe  alternaEves  i.e.  a  video  player  that  doesn’t  autoplayUse  rarelyHTMLNot  possibleiOSUIAccessibilityIsVoiceoverRunnerAndroidisScreenReaderActiveDesign  &  BuildTuesday, 21 May 13
    • Breakout  session:How  accessible  is  Facebook  and  how  would  you  fix  it?1.  HTML2.  Android3.  iOS124Tuesday, 21 May 13
    • 125Discovery  Design  &  Build  Deploy  Tuesday, 21 May 13
    • 126WorkflowDiscoveryRWD,  hybrid,  naEve  app  etcDevice  support  planTest  planIn  house,  technical,  user,  automatedSecure  and  allocate  budget  early  onDefiniEonRequirementsGuidelines:  pre-­‐exisEng,  internal,  customisedWho  owns  what  (originates  with,  implemented  by)User  storiesSign  off  processTraining  requirementsEditorial,  UX,  Development,  QA  teamsDeployTuesday, 21 May 13
    • 127WorkflowDefiniEon  conEnuedWireframesAnnotate  for  structure,  content  order,  keyboard  interacEonDone  by  UX  collaboraEng  with  developmentUXReview  and  documentDeployDefiniEon  of  Done  -­‐  ensure  accessibility  is  one  aspectMinimal  Viable  ProductMaintenance  planeDeployTuesday, 21 May 13
    • 128Defini=on  of  DoneCode  adheres  to  internal  code  standardsCore  content  adheres  to  accessibility  requirementsContent  passesAutomated  testsUser  testsManual  testsUser  Acceptance  CriteriaCore  content  is  available  toAvailable  to  screen  readersAvailable  with  colours  invertedUsable  with  zoomUsable  with  screen  readers  and  zoomUsable  without  JavaScriptDeployTuesday, 21 May 13
    • 129Minimal  Viable  ProductAll  core  content  and  funcEonality  isAvailable  to  screen  readersAvailable  with  colours  invertedUsable  with  zoomUsable  with  screen  readers  and  zoomNot  reliant  on  JavaScriptExempEonsPixel  perfecEonFuncEonality  the  offers  an  alternaEve  route  to  already  accessible  core  contentEffects,  animaEons,  transiEonsAddiEonal  features  can  be  added  later  i.e.  font  switchers  if  content  is  already  flexible“Beauty  is  only  skin  deep”  -­‐  MeDeployTuesday, 21 May 13
    • 130My  rule  of  thumbAny  relaunch  exceeds  exisEng  levels  of  accessibilityVersion  one  has  no  Showstopper/Blocker  issues  and  all  other  issues  prioriEsed  in  the  BacklogShowstopper  =  affects  producEon  so  adversely  that  it  must  be  fixed  or  addressed  immediatelyBlocker  =  This  issue  blocks  further  progress  or  another  issue.  It  may  be  blocking  ReleaseDeployTuesday, 21 May 13
    • 131Tes=ng  -­‐  HTMLResponsive  designHard  to  test  for  all  devicesOpEmise  then  test  on  the  most  common  devicesToolsFireEyes,  includes  a  responsive  tesEng  featuresDefault  user  agent  switchingValidaEng  HTMLWebAim  ToolbarDeployTuesday, 21 May 13
    • 132Tes=ng  -­‐  AndroidAndroid  EmulatorVirtual  device  in  Android  SDKConfigurable  to  mimic  different  devicesContains  a  debug  consoleDeployTuesday, 21 May 13
    • 133Tes=ng  -­‐  AndroidAndroid  Lint  Tool  Finds  missing  ContentDescriptionFinds  missing  input  types  on  text  fieldsQuick  fix  windowWrite  custom  testsDeployTuesday, 21 May 13
    • Tes=ng  -­‐  Android DeployTuesday, 21 May 13
    • Tes=ng  -­‐  iOSiOS  Accessibility  InspectorDisplays  accessibility  informaEon  of  accessible  elementsSimulates  Voiceover  interacEonRuns  in  the  iOS  SimulatorWhen  running  the  AI  hijacks  single  click  to  focus,  double  click  to  acEvateA  good  development  tool  but  not  suitable  for  final  tesEngDeployTuesday, 21 May 13
    • Tes=ng  -­‐  scenariosComplete  keys  tasks:with  voice  outputwith  zoomwith  voice  output  and  zoom  with  inverse  colours  onMobile  Accessibility  testsDeployTuesday, 21 May 13
    • Switch  off  the  screeniOS  -­‐  Screen  CurtainAndroid    -­‐  browser  se[ngs  >  Brightness  or  use  ShadesVoice  output  testsAre  images  labelled?Is  content  order  logical?Are  changes  of  state  announced?Are  bugons  used  for  acEons?Are  links  used  to  open  pages?Are  form  elements  labelled?Are  appropriate  keyboards  used?Tes=ng  screen  reader  support DeployTuesday, 21 May 13
    • Text  is  readable?Large  areas  of  empty  space  are  not  present?Labels  and  form  inputs  are  not  separated  by  large  areas  of  empty  space?Pop  ups  do  not  obscure  the  whole  screen?Tes=ng  low  vision DeployTuesday, 21 May 13
    • Visible  text  matches  audible  labels?Bugons,  images  of  text  etcIs  visible  and  voice  output  focus  are  in  sync?Tes=ng  zoom  and  voice  output DeployTuesday, 21 May 13
    • Is  text  readable?There  is  sufficient  contrast?Visible  navigaEon  cues  are  clear?Meaning  is  clear?Tes=ng  inverse  colours DeployTuesday, 21 May 13
    • 01  Establish  a  mobile  accessibility  strategy02  Define  requirements  (Guideline,  MVP,  DOD)03  Establish  test  plans04  Establish  training  needs05  Map  requirements  to  wireframes  and  UXWrap  up DeployTuesday, 21 May 13
    • To  be  con(nued...henny@iheni.com142Tuesday, 21 May 13