See also: IRC log
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
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: 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…
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.
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
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Default Present: jeanne, Kim, agarrison, alistair, David, Detlev, Kathy Present: jeanne Kim agarrison alistair David Detlev Kathy Regrets: Henny Alan Marc Found Date: 21 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/21-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]