Mobile Accessibility Task Force Teleconference -- 03 Nov 2016

<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"

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)

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

- DRAFT -

Mobile Accessibility Task Force Teleconference

03 Nov 2016

Attendees

Contents

M14

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output