MATF Minutes 21 January 2016

MATF Minutes 21 January 2016 link: 
https://www.w3.org/2016/01/14-mobile-a11y-minutes.html


Text of minutes:


  Mobile Accessibility Task Force Teleconference


    21 Jan 2016

See also: IRC log <http://www.w3.org/2016/01/21-mobile-a11y-irc>


    Attendees

Present
    jeanne, Kim, agarrison, alistair, David, Detlev, Kathy
Regrets
    Henny, Alan, Marc
Chair
    Kathleen_Wahlbin
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#agenda>
     1. 2.5, 2.1.1 Understanding
        <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#item01>
     2. Assignments
        <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#item02>
     3. 2.5.5 touch clearance
        <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#item03>
  * Summary of Action Items
    <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/01/21-mobile-a11y-minutes.html#ResolutionSummary>

------------------------------------------------------------------------

clear agenda

Kathy: we've been working at getting additional language into new 
proposed guideline -- touch and pointer.
... I've started understanding -- done first couple sections, some of it 
was language from our document
... if you see things that are not clear or we need more detail on. I 
want to keep it concise but don't want to miss information either

<Kathy> https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer 
<https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer>


      2.5, 2.1.1 Understanding

David: add don't step on existing swipes and stuff

Kathy: it's going to be different for each OS

David: can be specific, but be familiar with your technologies platform 
system controls, and can provide a link common swipes and taps for iOS 
and Android
... want to put it in section for related resources

confusion about numbers -- automatic numbering is not yet working properly

<jeanne> Be famililar with your platform's system controls and standards 
for assistive technology. Use the system controls supported by the 
platform first.

<jeanne> Be famililar with your platform's system controls and standards 
for assistive technology. Use the system controls supported by the 
platform first and don't overwrite the standard gestures of the platform.

<jeanne> Don't use a common gesture for a purpose that is not common.

David: advice in iOS and android is that you don't use a common gesture 
for something that's not common -- I'll look for that section

Kathy: in further resources if we are linking to AT gestures do we only 
link to the official ones or for example we have this really nice 
graphical gesture list sheet, would it be okay to link out to those or 
should we just stick to Apple and Android

David: best to go to the manufacturers who are doing it because that 
advice may change over time. We have the ability to do either, but in 
general the consensus has been to point to stuff that's as close to the 
source as possible

Jeanne: and be prepared for link rot -- Apple moves their accessibility 
information regularly, as does Gnu

Alistair: under intent guideline 2.5 second paragraph -- all users can 
use the device -- too hopeful, I would strike

<David> 
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/InteractivityInput.html

David: guidelines for custom gestures

Detlev: equivalent to deleting by swiping for example?

Alistair: Can't use the functionality because it's been used up by voice 
over. That's a slightly different twist to the way this is structured

Detlev: can't disable two finger or three finger swiping

David: add these two examples into the understanding: for instance, if 
the user overrides a double tap, then the voice over user won't get 
access to that.
... as long as we say for example, good language to use in the 
understanding document

Kathy: if developers do a custom gesture with a double tap and there's a 
conflict between screenreader double tap and that defined by the program...

Detlev: I like the language that screenreader takes away -- you have to 
find another way to do it

Kathy: under 2.5.1

<Kathy> 
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/InteractivityInput.html 
https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html 
https://support.google.com/accessibility/android/answer/6151827?hl=en

<Kathy> http://developer.android.com/training/gestures/index.html

<Kathy> 
http://www.windowsphone.com/en-us/how-to/wp7/start/gestures-flick-pan-and-stretch

<David> For example, if a developer assigns a double tap as a custom 
gesture, as the only way to complete an action, a user who is blind 
using VoiceOver will not have access to that action because VoiceOver 
reserves the double tap to select an item. the only

Kathy: any other resources for accessibility/touch

<Kathy> 
https://www.microsoft.com/en/mobile/accessibility/use-narrator-on-my-phone/

Detlev: as all these are built out issue, for example Google talk back 
presumably holds onto the same gestures as talkback, but I presume over 
time this is going to be a very big list to be able to maintain

Kathy: just the manufacturers, Apple, Google, Windows, blackberry, not 
looking at Samsung etc. But it is a good point -- Samsung is a pretty 
big manufacture and is used a lot, so if they have changed gestures and 
added gestures into what talkback does natively...

<Kathy> 
http://downloadcenter.samsung.com/content/UM/201503/20150303094626458/SM-G920F_UM_EU_Lollipop_Eng_Rev.1.0_150302.pdf

David: historically there have only been a few winners and the emerging 
winners, if we stay on top of those, we have to be practical to a 
certain extent. If we see something getting traction, we can add

Alistair: resources on the wiki page

Kathy: this is the manual

Detlev: open question whether resources for Blackberry will be useful -- 
switching to Android

Kathy: we have a good set of resources -- 2 each for Windows, android, 
iOS, and then one for Samsung. Should leave out blackberry since they 
are switching to android

<David> Continue on example 1: The developer can avoid this problem by 
avoiding to chose a common gesture to do an unexpected action or by 
providing an additional way to complete the action with touch in a way 
that doesn't interfere with VoiceOver gestures.

Detlev: blackberry for blind user not a nice experience at all the last 
time I checked, also crashed easily

Kathy: any other changes 2.5.1 section
... I'll continue going through the success criteria that we have and 
write up the other understanding ssections for the sections that we've 
been completed -- to 2.5.4. Also need to add 2.5.4 new wording from last 
meeting
... might be a good test to see what happens on android if you try to do 
something with a double tap, wondering if Patrick has examples

<David> Example 2: If a developer assigns a swipe right as the only way 
to open a menu, the VoiceOver user will not be able to do that action, 
because VoiceOver overtakes the right swipe as a way to move from 
element to element. In order to avoid this problem, the developer could 
ensure there is a mobile menu button which works with touch as another 
way to bring up the menu.

<agarrison> Just change overtakes to takes over

If a developer assigns a swipe right as the only way to open a menu, the 
VoiceOver user will not be able to do that action, because VoiceOver 
takes over the right swipe as a way to move from element to element. To 
avoid this problem, the developer could ensure there is a mobile menu 
button that works with touch as another way to bring up the menu.


      Assignments

Kathy: still techniques and failures that need to be assigned
... we don't need everything done but I'd like to have some examples so 
when the working group is looking at this they have a technique to see 
where were going with this
... David, you have 2.5.3 techniques -- single tap long presses revocable
... Marc technique under 2.5.1
... look for headings, issues with numbering

Detlev: was meant to be assigned one about user knows position with an 
application but can't find it in technique development assignments

Kathy: most recent ones are not in technique development assignments, 
don't have numbers for them
... these are just in meeting agendas for now
... the one specifically for touch and pointer
... if you wanted to do another one or you had time you could modify -- 
there are two already partially written to reflect the change that we 
did to pixels rather than
... any of the ones that are in the touch proposal that you like to do 
you can pick up, I'll try to get this in the wiki as well

<Detlev> Detlev we could review M016 and M27 which I have drafted

Kathy: will update techniques assignments and wiki and send to list


      2.5.5 touch clearance

Kathy: so for touch target clearance I think the change we need to do 
here is simply change 9 mm to 48 pixels

<Kathy> 2.5.5 Touch Target Clearance: The center of each touch target 
has a distance of at least 9 mm from the center of any other touch 
target, except when the user has reduced the default scale of content. 
(Level AA)

Kathy: this is what we currently have

<Kathy> 2.5.5 Touch Target Clearance: The center of each touch target 
has a distance of at least 48px from the center of any other touch 
target, except when the user has reduced the default scale of content. 
(Level AA)

<Kathy> 2.5.5 Touch Target Clearance: The center of each touch target 
has a distance of at least 48px from the center of any other touch 
target. (Level AA)

Detlev: does it still make sense to have another technique that they 
shouldn't overlap

Kathy: if the touch targets overlap with that be a failure or technique
... you see it sometimes an responsive design

Detlev: is it mobile specific -- you could have the same problem on the 
desktop, don't know which interactive element is on top of each other, 
same issue

Kathy: 48 pixels by 48 pixels -- if 50 pixels and one pixel overlap, is 
that an issue?
... right now were saying touch target clearance needs to be 48 pixels 
by 48 pixels. The center from one element to another active element 
needs to be 48 pixels from the center to the center. But if we have 
elements that are 50 pixels each than we overlap by one pixel on either 
side. Is that an issue? They essentially meet the success criteria -- 
touch target clearance has a distance of 48...
... pixels, but if it's greater than that it's overlapping

Detlev: that's not such an issue if your finger is in the middle of the 
button you should be able to detect which one
... menu -- flow into one another, do you want clearance between them

Kathy: BBC one pixel between? Why are we saying from the center of one 
touch target to the center of the other?

Detlev: even if your finger is just marginally inside

<Detlev> That was Alisair speaking...

Alistair: you could get rid of that one
... as Detlev pointed out that something that we may need to raise at a 
general level in WCAG -- issue with overlapping buttons

David: overlapping buttons not siteing problem, but seeing problem
... seems like we are starting to overlap into usability -- worse for 
accessibility?

Alistair: probably the 48 pixels to the center of each one is probably 
redundant, could be removed
... we would have to think of one that was overlapping instead
... 48 pixels means they're large enough, maybe 48 x 48 visible pixels, 
that would solve the problem all around

Detlev: if the menu had enough space on a button wouldn't matter if 
there are 48 vertically, if there are 48 horizontally

David: better center to center because we don't want to prescribe how 
big the button is

Alistair: has to be visible on the screen. The other problem is you have 
a button 48 x 48 on top of another button

David: I'm wondering if her going to get pushback on 48 horizontal

Alistair: will modify and send email this week -- using the 48 pixel 
language


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/01/21 17:11:48 $