MATF Minutes 3 November 2016

*MATF Minutes 3 November 2016 link: 
**https://www.w3.org/2016/11/03-mobile-a11y-minutes.html

Text of minutes:*


  Mobile Accessibility Task Force Teleconference


    03 Nov 2016

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


    Attendees

Present
    Detlev, marcjohlic, patrick_h_lauke, Kim, chriscm, Kathy, Jatin, David
Regrets
    Henny
Chair
    Kathleen_Wahlbin
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/11/03-mobile-a11y-minutes.html#agenda>
     1. M14 <https://www.w3.org/2016/11/03-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2016/11/03-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/11/03-mobile-a11y-minutes.html#ResolutionSummary>

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

<Detlev> scribe?

Kathy: status – all success criteria has to be submitted by December 1 
to the working group
... good news is just a few SC left, concentrating on the ones that are 
mobile for now
... want to make sure they are all finalized and go out

<Detlev> scribe??

Kathy: task force will take month of December off – appreciate hard work 
and that's always a busy time. Will reconvene again in January. In 
January the work will consist of writing techniques for existing success 
criteria and also working on the questions and comments from the working 
group on the success criteria that we submitted. In February we're going 
to have the first working draft of...
... 2.1 so a lot of work happening in January
... making sure everyone's aware of the schedule for the next few months

Marc: M-16?

Kathy: yes M-16

<marcjohlic> M14: 
https://github.com/chriscm2006/Mobile-A11y-Extension/blob/d9ecc74431ee5bef084b51256468838b1d9a773a/SCs/m14.md

Kathy: today M14 and M9 if we have time
... after we finish those look at as a whole. If you do see something 
that's missing that you would like in from a mobile perspective you can 
still propose
... feel free to suggest we want to make sure everybody's voice is heard


      M14

<kathy> 
https://github.com/chriscm2006/Mobile-A11y-Extension/blob/d9ecc74431ee5bef084b51256468838b1d9a773a/SCs/m14.md

<kathy> Non-interference of AT: Content does not interfere with default 
functionality of platform level assistive technology

Kathy: this is what was in the last draft
... I think the description that you have might be better, but SC is not 
short

Chris: what's missing from the original SC is circumvent text

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology or a mechanism to override the 
interference is available, unless essential for use of the content.

Kathy: we can add an exception

Chris: replace first sentence of what I have with the original and then 
leave the second sentence

David: trying to make it a bit shorter

<patrick_h_lauke> +1

Chris: don't see a need to specify – can do that in failures

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology or a mechanism is available to 
override the interference, unless the interference is essential for use 
of the content.

Kathy: in the past had said this is primarily for native applications – 
there are examples today in websites – Apple resizing font scenario

Chris: anything that is just available in native API's – it's just a 
matter of time before those APIs become available within web apps or 
websites

Detlev: I wasn't aware of any examples, and was guessing it would relate 
more to native applications at least at the moment

Chris: the quintessential example is trait where entire view passes 
through gestures to the view – UI accessibility– trait that ignores 
pass-through completely breaks everything – I see it all the time in 
native and it's just a matter of time before we see it in web content

Patrick: currently can't see any situation in pure web terms where this 
would be the case – things like an app requesting explicitly that all 
touch is just passed through it circumventing anything else. Having said 
that for desktop-based screen readers fall into this – so do we want to 
write this more generally

Kathy: this one will be combined with cognitive as well so I think we 
can do that

Patrick: in that case I would suggest that in the description we don't 
jump straight about talking about touch. Currently a duplication first 
paragraph second sentence, next sentence both talk about touch. I'd 
remove Touch ATs rely on on the first sentence and keep it as a common 
scenario. So it's not touch specific and also remove duplication

<patrick_h_lauke> "The intent of this success criterion is to prevent 
content from interfering with platform assistive technology."

Patrick: AT misbehaves is a little bit vague, changing first sentence

<patrick_h_lauke> removing "Touch ATs rely..."

Kathy: do we want to say platform assistive technology and settings?
... things in the platform mobile settings are not really assistive 
technology

<patrick_h_lauke> +1 to what Detlev says....i think the font size etc is 
a different topic

<patrick_h_lauke> font size is already covered, in my view, in WCAG 2.0 
text size SC

Kathy: I agree with Patrick, we are talking about preventing content 
from interfering with platform, but what we are finding on mobile is 
there are a lot more settings to allow users to customize their 
experience so they have an experience that works for them which gets 
into personalization, which is where cognitive has been going also low 
vision
... if we look at settings I don't see changing contrast to AT. So do we 
want to say platform AT and settings so we are addressing more than just 
the assistive technology

Detlev: my understanding was the issue here is a certain set of gestures 
– more specifically screenreader gestures or other screenreader things 
on the desktop would not work in certain modes, e.g. pass-through of 
gestures straight to the application. I think that's qualitatively 
different than changing settings. They might also have an effect it it's 
difficult to lump them together in a...
... success criteria. Matching techniques to that – might confuse 
people, wide set of different issues lumped together

Kathy: we have that separate – touch with assistive technology
... noninterference of AT – we already have touch

Detlev: different, don't rely because it may be intercepted versus don't 
stop the AT you can intercept touch gestures directly

Patrick: font size is already covered. if cognitive and low vision are 
already working on some aspects not sure we should cram them all in here

<Detlev> That was Patrick speaking

David: we have quite a bit of overlap – I think it's okay to go to the 
working group with this. Better to have more granularity going into the 
working group so they can pick and choose. I'm having trouble seeing how 
– we already have accessibility support. We already have non 
interference. But this point we don't have a lot of time

<patrick_h_lauke> propose: add a note in the description for the working 
group to explain that our other "Touch with AT" talks about "don't rely 
on gestures etc being possible since AT may intercept it", whereas this 
is "don't try and suppress AT so that you can intercept touch directly"

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology or a mechanism is available to 
override the interference, unless the interference is essential for use 
of the content.

Patrick: add a note to the description – put in above – that specifies 
why this is different

Kathy: I agree – this is going to come up over and over again

Chris: making changes in github

Patrick: if we want to cover more than just touch at least on the 
Windows side of the equation how about changes the behavior of screen 
readers for instance to suppress things like reading keys, quick jump 
navigation sue headings etc. Have that as example, somewhere, probably 
description
... I can come up with wording

<patrick_h_lauke> i will send some proposed example text to list

Kathy: anybody else have changes, concerns with the overall content

<chriscm> 
https://github.com/chriscm2006/Mobile-A11y-Extension/blob/m14/SCs/m14.md

Detlev: wording is dense

<patrick_h_lauke> chris: just made a change to the opening part of the 
description, as discussed earlier in call. hope that looks ok? 
https://github.com/chriscm2006/Mobile-A11y-Extension/blob/m14/SCs/m14.md

<patrick_h_lauke> (strangely, was able to edit and commit)

Detlev: example, may be drawing something on the screen without 
noticing. You are talking about mechanism to override interference – 
that's not getting into the situation in the first place. The case that 
Patrick brought in with role application might be different again. It 
sounds very abstract at the moment.

David: what is the dumb thing authors are doing that we want to tell 
them to stop doing

Chris: overwriting the default font so that an iOS it doesn't respond to 
request for font size changes.

Patrick: in a native and/or hybrid application forcing touches to go 
directly to the application bypassing any AT

Detlev: button put your signature in here, view that does not respond to 
AT, can't do anything but draw signature.

Chris: gestures overridden by drawing in text field. Most of your screen 
is taken up by signature field or drawing or whatever

Detlev: criterion may be met iif there are other areas you can get to

Chris: that gesture wouldn't work because it would be passed through to 
the view

Detlev: if you give advance warning in your button leading to that point 
– that would be awkward but with that fulfill success criteria
... could be hidden text

Patrick: could argue that it is essential because the user has to 
scribble signature, but to mitigate we are adding this particular text 
so it's an exception in terms of this SC if the author can make a 
reasoned case that it is essential but it would still be good to provide 
a description of what is going to happen to provide some kind of 
guidance to the user – maybe even warning the user...
... before they go to that screen that that is going to happen

Chris: that was my intent behind the requirements for the exception – 
that a user shouldn't be able to end up on the screen where their 
gestures are going to be passed through to any element on that screen 
unless they are warned of it before hand

<DavidMacDonald> -Content does not interfere with the normal operation 
of the platform assistive technology or a mechanism is available to 
override the interference, unless the interference is essential for use 
of the content and the user is warned beforehand.

Kathy: don't we have something similar in another success criteria

David: warned before hand – I'll find that, we might want to mimic that

Detlev: change of context thing

<DavidMacDonald> unless the user has been advised of the behavior before 
using the component. (Level A)

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology or a mechanism is available to 
override the interference, unless the interference is essential for use 
of the content and the user is warned before using the component

Patrick: it's wordy but I can read through it – last interference can be 
changed to this

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology or a mechanism is available to 
override the interference, unless it is essential for use of the content 
and the user is warned before using the component

<DavidMacDonald> Content does not interfere with the normal operation of 
the platform assistive technology, or a mechanism is available to 
override the interference, unless it is essential for use of the content 
and the user is warned before using the component.

Patrick: example of mechanism – in settings: never allow an app to 
override my AT
... opens it up to different possibilities of fulfilling that. If there 
was an iOS only app could make a case for saying mechanism available in 
the settings
... some SCs have the exception stuff separate, but generally agree

<patrick_h_lauke> i need to shoot off a few minutes early, sorry. i will 
send off proposed extra text for role="application" stuff to somehow be 
integrated later tonight

Kathy: Chris to make changes – we'll continue working on this and get it 
finalized

Chris: request that people put comments on pull requests or not on pull 
request – just consistent

Kathy: I'll monitor list and put anything not on the pole request in the 
pull request

David: how about just filing an issue?

Chris: when I forked it I may not have added issues to my repository – I 
can update that

David: the issues list is probably the easiest way to update and talk 
about stuff

<Detlev> can't hear a thing now

recommended way to comment is in issues


    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.148 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/11/03 16:12:22 $


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

www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________