See also: IRC log
<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
<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
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Detlev/Patrick/ Succeeded: s/Detlev/Patrick/ Succeeded: s/Detlev/Patrick/ No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: Detlev marcjohlic patrick_h_lauke Kim chriscm Kathy Jatin David Regrets: Henny Found Date: 03 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/03-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]