Re: Minutes of Mobile Accessibility TF teleconference of 16 May 2014

Late regrets ....Very sorry been delivering training

Kindest Regards,

Gavin Evans
Director of Operations | DAC
Mob: 07936 685804
Twitter: @GavinAEvans @DACcessibility
www.digitalaccessibilitycentre.org<http://www.digitalaccessibilitycentre.org/>
www.accessin.org<http://www.accessin.org/>

On 16 May 2014, at 19:02, "Jeanne Spellman" <jeanne@w3.org<mailto:jeanne@w3.org>> wrote:

HTML minutes:
http://www.w3.org/2014/05/16-mobile-a11y-minutes.html

Text of minutes:
  [1]W3C

     [1] http://www.w3.org/

                              - DRAFT -

            Mobile Accessibility Task Force Teleconference

16 May 2014

  See also: [2]IRC log

     [2] http://www.w3.org/2014/05/16-mobile-a11y-irc

Attendees

  Present
         Kim_Patch, Kathy_Wahlbin, kathleen,
         Jeanne, WuWei, jon
  Regrets
         Alan

  Chair
         Kathy

  Scribe
         jeanne

Contents

    * [3]Topics
        1. [4]Survey Q1
        2. [5]Survey Q2
        3. [6]3. Provide instructions for custom functions and
           gestures
        4. [7]next meeting
    * [8]Summary of Action Items
    __________________________________________________________

  <trackbot> Date: 16 May 2014

  <Kathy>
  [9]http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Te
  chniques

     [9] http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques

  <scribe> scribe: jeanne

  <Kathy>
  [10]https://www.w3.org/2002/09/wbs/66524/20140512_survey/result
  s

    [10] https://www.w3.org/2002/09/wbs/66524/20140512_survey/results

  <Kathy>
  [11]http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Deve
  lopment_Assignments

    [11] http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

  [intro to survey]

  KW: We still need to identify which apply to mobile, mobile
  apps, and hybrid

  <Kathy>
  [12]https://www.w3.org/2002/09/wbs/66524/20140512_survey/result
  s

    [12] https://www.w3.org/2002/09/wbs/66524/20140512_survey/results

  KW: I reviewed the funka nu best practices and did a gap
  analysis which i added to the new techniques page

Survey Q1

  KW: we could break this into multiple techniques and possibly a
  failure technique
  ... there are a lot of ways that someone can control their
  device: bluetooth keyboard, switch, etc.
  ... what would be a path for WCAG for keyboard access?

  JS: Alan had a good point that if the device doesn't support
  bluetooth or any other connection, it seems overboard to
  require the app to do so. I think we need to word the technique
  around this.

  JA: If you have an app on a phone that doesn't support addon
  devices, then WCAG cannot be supported.
  ... you could never meet that

  JS: Isn't that Accessibility Supported Technology?

  JA: That's a part of it.
  ... Example: if you have audio description for a multimedia
  presentation, but didn't have enough room to pause, and you
  made extended audio descriptions, you could meet WCAG AAA, but
  not AA.

  KW: If you could do everything with the keyboard, but you were
  on a device that didn't have a keyboard, could you claim
  compliance?
  ... the default interaction with a desktop is keyboard, so you
  have to meet keyboard access to comply, but on mobile, the
  primary mobile input is touch and gestures, so when we are
  looking at keyboard access and defining what keyboard access
  is, there has to be some way to input.
  ... what do we say for what the minimum, or what should be
  required on a mobile device?

  JA: We could take a functional approach, and say that you have
  to have an input method that doesn't require speech, vision,
  etc.
  ... we could require a method that serves the most people

  <KimPatch> Jeanne: keyboard is the most useful interface – not
  physical keyboard, but the concept of the keyboard was the most
  universal because which could use a keyboard, Bluetooth
  keyboards could be attached, individual tapping of a virtual
  keyboard is very common, so keyboard was the most universal of
  the input types because people can always emulate a keyboard.
  The danger with the functional...

  <KimPatch> ...approach is that it can easily be set up to
  exclude people, especially people with multiple disabilities. I
  would really encourage us to keep looking at this and finding a
  way that we could approach this that would not leave out people
  – particularly people with multiple disabilities

  KW: I think that the keyboard is not the most universal device
  on mobile

  KP: I htink it depends on what you are doing. you could spend
  the whole day on keyboard on a mobile device.

  kW: If you have everything you can access with a bluetooth
  keyboard, does that mean that everything can be accessed with
  switch and keyboard.

  JA: i don't know how to support the iOS problem, where it is
  very accessible, but it doesn't support keyboard access to
  everything.
  ... there is a product that can take advantage of that
  interface.
  ... propose: defining that an alternative would be exposed and
  it would be programmatically supported to that interaction.
  ... the product can take advantage of the input exposed, and
  the application could take advantage of the action that the
  item can performed programmatically in some way.

  <jon_avila> sounds good

  KW: i think we should call this out in the notes and take it to
  the different working groups for more feedback from WcAGWG and
  UAWG
  ... I think it would be a sufficient technique, and could be a
  failure technique if it doesn't support keyboard

  JA: In a programmatic way, if it didn't support keyboard
  emulation
  ... it goes back to Accessibility Supported. It's a broad term.
  It would also have to work with switch control or keyboard. It
  also goes back to the device, if it didn't have the device
  support, it isn't Accessibility Supported.

  KW: the failure would be that it didn't have an input method
  that was accessibility supported.

  kathy: that would be a failure of the device platform and not
  of the app

  JA: If it worked on a platform, and failed on a different
  platform because the platform doesn't support it, then they
  could make an argument for accessibility supported.

  Kathy: we shouldn't penalize the developer because of a failure
  of the platform

  KW: you might define your platform as X and Y and not support Z
  because of a lack of accessibility support.
  ... it is so much more complex on mobile because of all the
  variations of platform

  JS: The app must support the programmatic access to the
  platform
  ... We should take it to UAWG, because they have worked on this
  a lot and have a lot of language already worked out.

  KW: We have it as a sufficient technique and as a failure
  technique

Survey Q2

  2. Provide visual/audio indication for all functions

  KW: on the desktop, you have focus indicator, but how do you
  alert people to the functional areas of the screen on mobile?/

  ack {G

  ack [GV

  JA: Two things - I'm not sure everything has to have an audio
  -- if you have the programmatic correct, it could be announced
  by a screenreader. Are we aiming it so it is available to
  assistive technology? i don't think we need to have it read
  aloud.

  KW: Let's considr this a duplicate of #28, that seems like
  better wording.

3. Provide instructions for custom functions and gestures

  JA: Is advising the user different from providing instructions
  ... we have to be more clear about where it needs to be. Are we
  advising the user or providing instructions
  ... 3.3.2 is about instructions for input. This appears to be
  more about keyboard access -- maybe the keyboard trap technique
  may be helpful. It says if it requires more than one keystroke,
  the user must be advised of the method for moving away.
  ... we could use that language, this is not a keyboard trap
  ... if you have a custom gesture, then you have to advise the
  user.
  ... I'm not sure it should be connected to 2.2.1 keyboard
  input, maybe it maps to 3.3.2

  kW: I'm not sure how it maps to WCAG, but I think i agree

  JS: i'm not sure it is an accessibility issue, it seems more
  like a usability issue.

  KW: Example: there is a gesture to expand an area by swiping up
  and down that people are using in apps. You need to perform the
  gesture to perform that action.

  JA: And there is no instructions for how it would be executed
  with a keyboard.

  jS: So it seems that the alternative input instruction is more
  of an issue than the custom gesture instruction.
  ... provide instructions for alternative input for custom
  gestures and functions

  JA: I would prefer advise rather than instructions

  <Kathy> Provide advisement on custom gesture and functions for
  alternative input

  WCAG: The user is advised of the behavior before using the
  component

  <Kathy> The user has been advised on custom gestures and
  functions for alternative input

  The user is advised of the alternative input of custom gestures
  and functions

  JA: Qualify it with "when alternative is not available with
  standard input method"

  The user is advised of the alternative input of custom gestures
  and functions when alternative is not available with standard
  input methods.

  kW: This would be a sufficient and also a failure.

next meeting

  no meeting next week because of holiday

  <Kathy>
  [13]http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Deve
  lopment_Assignments

    [13] http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

  Go through the techniques and identify which are applicable to
  mobile web, mobile apps or both.

Summary of Action Items

  [End of minutes]