See also: IRC log
<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
<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
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...
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) Found Scribe: Detlev Inferring ScribeNick: Detlev Default Present: Alistair, jeanne, Detlev, Kim, chriscm, marcjohlic, JF Present: Alistair jeanne Detlev Kim chriscm marcjohlic JF Patrick Regrets: John Jan Alan Henny Found Date: 25 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/25-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]