MATF Minutes 18 February 2016

MATF Minutes 18 February 2016 link:
https://www.w3.org/2016/02/18-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
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:31:55 UTC