- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 25 Feb 2016 12:33:57 -0500
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <56CF3B05.20702@redstartsystems.com>
MATF Minutes 25 February 2016 link:
https://www.w3.org/2016/02/25-mobile-a11y-minutes.html
Mobile Accessibility Task Force Teleconference
25 Feb 2016
See also: IRC log <http://www.w3.org/2016/02/25-mobile-a11y-irc>
Attendees
Present
Alistair, jeanne, Detlev, Kim, chriscm, marcjohlic, JF, Patrick
Regrets
John, Jan, Alan, Henny
Chair
Kimberly_Patch
Scribe
Detlev
Contents
* Topics <https://www.w3.org/2016/02/25-mobile-a11y-minutes.html#agenda>
1. Review assignments
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
<https://www.w3.org/2016/02/25-mobile-a11y-minutes.html#item01>
* Summary of Action Items
<https://www.w3.org/2016/02/25-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/02/25-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
<patrick_h_lauke> random q: whenever i follow the webex password, the
login form includes a "meeting password" field. i tried the meeting
number, but that doesn't seem to be correct. am i missing something?
<patrick_h_lauke> "whenver i follow the webex LINK" i mean
<patrick_h_lauke> ah thank you
<scribe> scribe: Detlev
Review assignments
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
<Kim>
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
Kim: Looking at assignments page
... Any Questions?
Mark: had no time to work on it
Chris: started draft of M029 - problem of link between Github and Wiki
Kim: might be easier to change stuff on the wiki
Chris: When following the links to github, most page are not touched
Kim: If you use Wiki make a note on assignmwents page
... The code is in Github already - so the link is needed
Detlev: explains link between github and readonly view
Kim: if you want on the wiki rather than on github, put a link to the
wiki page at the end of the respective cell and eventually stuff can be
moved to Github and that link can then be removed
<patrick_h_lauke> (i believe M029 was the reason why i offered to join
the call today...so if you have a link to the wiki version that was
updated...)
Alistair: comment to M025
... a technique for small screen has not been copied back into master
table - the toic was error msg
Kim: looking at M029
Jeanne: lets also work on 2.5.3 they belong together
<Kim> https://w3c.github.io/Mobile-A11y-Extension/#touch-and-
<patrick_h_lauke>
https://w3c.github.io/Mobile-A11y-Extension/#tap-press-revocable
<patrick_h_lauke> and my email comment
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/0038.html
<jeanne>
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3
<jeanne> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029
Kim: Patrick - any thoughts on 2.5.3 as it stands?
<patrick_h_lauke>
http://patrickhlauke.github.io/touch/tests/pointercapture.html
<http://patrickhlauke.github.io/touch/tests/pointercapture.html>
Concern was when finger inside elements / buttons in mobile browsers may
implement some automatic capture of touchso button will be triggered
even if finger is moved outside the button
Patrick: As long as finger is pressed while you move it ouside, the
event will be fired
Patricks: makes use more fault-tolerant also benefits people with motor
impairment
<Kim>
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3
Patrick: remove part that says fingerhas to stay inside control to
activate - in the wording?
<jeanne> 2.5.3 Single Taps and Long Presses Revocable: When the
device-based assistive technology (e.g screenreader) is being used, then
the selection gesture must be separate from the activation gesture, have
confirmation, or be easily reversible. (Level A)
<jeanne> Understanding: People with various disabilities can
inadvertently initiate a touch event with unwanted results. Authors can
reduce this problem by making the behavior more intentional, such as
providing a confirmation alert when the event is destructive or causes
significant changes, or allowing the user to slide away from the button
or touch object before lifting their finger, thereby
<jeanne> canceling the event.
Alistair: If behaviour implemented now?
Patrick: We are discussing the behaviour with AT (VO, TalkBack)
Chris: The click event is implemented as double-tap
In some cases this is overwritten so actons are triggered immeadiately
Chris: In a browser you can't overwrite the AT, but in native apps you can
<patrick_h_lauke> (got kicked out of the irc channel for some reason)
<patrick_h_lauke> so basically the new proposed SC "2.5.3 Single Taps
and Long Presses Revocable: When the device-based assistive technology
(e.g screenreader) is being used, then the selection gesture must be
separate from the activation gesture, have confirmation, or be easily
reversible. (Level A)" is actually quite substantially different from
the one i commented on originally
<patrick_h_lauke> "2.5.3 [Proposed New MOBILE Success Criteria] 2.5.3
Single Taps and Long Presses Revocable: Interface elements that require
a single tap or a long press as input will only trigger the
corresponding event when the finger is lifted inside that element.
(Level A)" (as in that older one, what i was commenting on - proposing
that it would be removed - was the "lifted inside that element" part)
Alistair: Should thisbe wider: "Dont overwrite AT"?
Chris; difficult because there are valid cases (as in drawing app)
Patrick: Current wording has nothing that mandates the finge should stay
inside element
... The behaviour in touch ATs is to separate selection and activation
... The revocable aspect is not in there now - just prevention of
accidental actions
Chris: Issu in wording M029 is requiring confirmation - is there another
failure that will require confrmation for important events (like bookign
something)?
Patrick: WOuld that not be covered under WCAG error prevention
Chris: yes probably
<patrick_h_lauke> https://www.w3.org/TR/WCAG20/#minimize-error
<patrick_h_lauke> 3.3.4
Kim: So no further failue for that is needed
<patrick_h_lauke> so i'd propose: remove the wording relating to
"revocable" from the proposed SC 2.5.3
Chris: so this is talking about the differnence between navigation and
activation on touch devices
Patrick: also to mobile without touch
Chris: the SC is the On focus one from WCAG
patrick; Even wonderign if an explicit SC is needed or just an
additional failure of 3.2.1 On focus
<patrick_h_lauke>
https://www.w3.org/TR/WCAG20/#consistent-behavior-receive-focus
Chris: Relating it too muich to 3.2.1 is that it may not be obvious to
non-experts
... the conclusion is that it may be better to keep it separate as a
mobile issue
<patrick_h_lauke> the missing parts of what devs may not know is: a)
using touch devices + touch AT, users navigate in a similar way to
keyboard navigation, and elements receive focus (and depending on
platform, MAY fire JS focus() events), therefore b) make sure things
don't fire on focus
Marc: Better to keep 2.2.1 separate from 2.5.3
corretion 3.2.1 not 2.2.1
Patrick: Developers need to know that on touc devices with AT the
navigation is similar o keyboard navigation
<marcjohlic> I withdraw my comment - that's what I get for multi-tasking :)
Patrick: an additon in 3.2.1 for mobile or a separate SC - both
possible, political issue
Chris: Reason for keeping separate: many developers don't rwealize that
focus and accessibility focus are a separate thing - 3.2.1 talks about
kb focus, on the AT focus that includes also items that are not kb-focusable
Patrick: How is that different from tabbinf and arrow focus on the desktop?
Chris: Finite set of cmds on desktop, tab, arrows - more diverse on mobile
Patrick: Only a finite set is recognised by touch with AT on
Chris: can be overridden at least in native apps
Kim: think o fspeech input as well
Patrick: Question on focus of TF: is native also included?
<JF> -1 to that
Jeanne: We want to, but it is not decided on WG level
Alistair: Bette rmove out native stuff, it's different
Marc: Many poeple will want to follow WCAG also for native stuff
Chris: Capabilities of native may increasingly become available in browsers
Alistair: now there is confusion for developers
JF: Separating tracks would be a cop-out
... Keep it together and notice the differences
Chris: on the level of SC there should be no difference
<patrick_h_lauke> if you want to include native, AND cases where native
overrides actual AT behavior...then you'll need SCs that effectively
reimplement any AT interaction, IMO
JF: "as technology allows" may be a good phrase to use to accommodate
changes
Alistair: So we need techniques for native, too
<jeanne> +1 to making the difference in the Techniques
JF: when it's a native only thing you pass by default asweb dev
JF; if we split things it creates confusion as well
<chriscm> +1 to keeping it separate.
Kim: we opened up the native can of worms
... is everyone good with keeping 3.2.1 and 2.5.3 separate?
<jeanne> Detlev: a major difference between mobile and desktop, is that
desktop has specific navigation keys, like arrows and tab. It's a
different experience.
<jeanne> ... there may be advantages to putting it together.
<patrick_h_lauke> my view would be: 2.5.3 is the same as WCAG 2.0 3.2.1
if it's clear that we're talking about the fact that touch + touch AT
behaves very similarly to "desktop" + keyboard, meaning that users will
move (reading) focus around the content, so the same issue of not firing
things on focus apply to touch + touch AT
Patrick: Can join again to discuss failure
Kim: If you prefer you can work on the Wiki, but add link
<patrick_h_lauke> the fact that on desktop+keyboard there's a "finite"
set of keystrokes vs on touchscreen + touch AT there are just swipe
gestures is, in my mind, a red herring
<patrick_h_lauke> no matter HOW users move their focus to things, the
point is still the same: once something DOES receive focus, don't fire
actions, but wait for explicit activation
<patrick_h_lauke> so the very high-level point that 3.2.1 in WCAG 2.0
(and the proposed 2.5.3 if you want it separate) is making is: there is
a difference between moving your
cursor/focus/whatever-you-want-to-call-it to an element and actually
activating it, so ensure that you have this distinction
<patrick_h_lauke> </rant>
<chriscm> Right, but the activating function isn't onFocus, it's on end
hover. Which is completely different...
<chriscm> Conceptually similar, but not the same.
Well the equivalent of moving the mouse outside a button before museUp
would be, on tocu with AT on, to dicover after the second tap of a doble
tap that you actually donÄt want to activat that element and then move
the finger to pürevent hat from happening - right?
Ok we do that on the list...
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/02/25 17:12:35 $
--
___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 25 February 2016 17:34:23 UTC