Re: MATF Minutes October 3, 2019

Belated regrets for not attending - it was a public holiday here yesterday.
Detlev

Sent from phone

> Am 03.10.2019 um 18:05 schrieb Kim Patch <kim@redstartsystems.com>:
> 
>  MATF Minutes October 3, 2019
> 
> Link: https://www.w3.org/2019/10/03-mobile-a11y-minutes.html
> 
> Text:
> Mobile Accessibility Task Force Teleconference
> 
> 03 Oct 2019
> 
> Attendees
> 
> Present
> Jennifer, Kim_Patch, JakeAbma, MarcJohlic
> Regrets
> 
> Chair
> Kimberly_Patch
> Scribe
> MarcJohlic
> Contents
> 
> Topics
> Summary of Action Items
> Summary of Resolutions
> <Kim_Patch> https://www.w3.org/2019/07/16-ag-minutes.html#item03 https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results#xq7
> 
> <Kim_Patch> https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6?usp=sharing
> 
> <Kim_Patch> https://docs.google.com/document/d/1ouVFq4w-i0rchNHtTAG_JoRwHfYm9mN2MkxFBct1JSI/edit
> 
> Link to doc from survey: https://docs.google.com/document/d/1ouVFq4w-i0rchNHtTAG_JoRwHfYm9mN2MkxFBct1JSI/edit#heading=h.vpayye3hz4fm
> 
> Comment from survey: "I appreciate and support the intent of this proposal, but there are significant complications to be addressed. It seems to me that the “instructions” would need to be different depending on what assistive technology is being used – but the presence of an assistive technology isn’t disclosed to the Web application for legitimate privacy reasons. We don’t even have an “opt-in” mechanism for disclosing it.
> 
> What action the user needs to perform can vary greatly depending on what device they’re using and what AT is operating. For example, the presence of a screen reader affects the keyboard or touch interface significantly. Various alternative input devices have their own means of interaction (e.g., speech recognition, single switch).
> 
> So I’m not sure how we can give accurate and useful instructions to the user which take into account the AT that is being used. Developing a web standard for this would be a useful project.
> 
> I suppose my ultimate comment is that I’m not sure this can be solved in WCAG without some underlying new or enhanced technologies developed elsewhere in W3C. "
> 
> <Kim_Patch> Mark: somewhat misses the purpose of the SC – says documents actions, not necessarily with various AT
> 
> <Kim_Patch> Jake: I think there might've been a small misunderstanding – it's not about how AT is used
> 
> <Kim_Patch> Jake: the only thing about AT is if At is running make sure you don't block the general AT gestures
> 
> <Kim_Patch> Jake: so this is not about those comments
> 
> <Kim_Patch> Mark: so we can agree to dismiss that comment – it's not applicable
> 
> Comments around concerns
> 
> <Kim_Patch> Mark: here are the comments where people just had concerns
> 
> From Jon Avila: "I like the SC -- but the ways to meet it don't always solve the issue. For example, adding help text in some help document isn't likely enough. Turning off the gesture may prevent it from not being activated but doesn't help the user discover it. We need to be more clear on what is actually required -- an on-screen indicator or tutorial AND a way to turn it off, etc."
> 
> TPAC 1: https://www.w3.org/2019/09/18-ag-minutes.html
> 
> TPAC 2: https://www.w3.org/2019/09/19-ag-minutes.html
> 
> <Kim_Patch> Techniques include a way to turn instructions on/off
> 
> Comment from Rachael: Please be aware of how this potentially works with the proposed SC to make Help easier to find help. Also, do we need an exception to cover games where discovering custom interactions is required as part of the experience?
> 
> From Mike Gower: The WCAG standards are basically void of instruction requirements. I believe this could be more broadly written to include a requirement to document any custom interaction that does not align with an established pattern, whether for keyboard, pointer or others. Deciding what yardstick to measure against is a bit of a challenge, but the aria authoring practices are one candidate for the keyboard. I wouldn't underplay how
> 
> difficult it is going to be agreeing on that yardstick; without it, the process of determining what constitutes '"custom" is going to be a real challenge.
> 
> <Kim_Patch> Marc: keep as is, add something for silver? What would be a custom interaction with the keyboard?
> 
> <Kim_Patch> Jennifer: keyboard shortcut only available on that one site. That would be a custom interaction – we've broadened it to be about more custom and ration rather than just gesture
> 
> <Kim_Patch> Jennifer: the title of the document still says instructions for movement – should be changed?
> 
> <Kim_Patch> Marc: definition of custom interaction at the bottom of the document – it does cover everything
> 
> Comment from Alastair: "The SC text doesn't allow for supplimentary gestures. For example, there is a menu button at the top left, but swiping in from the left also activates the menu.
> 
> It appears by the SC text that you would still need to have instructions for that gesture, even though it is not needed to use the menu.
> 
> Suggest re-forming to something like: All functionality that requires the use of custom gestures or motion actuation has instructions to indicate how to operate the functionality.
> 
> Perhaps defining custom gestures as a path-based gesture supplied by the content rather than the user-agent.
> 
> I'm sure someone will also bring up 'where do these instuctions have to be?', for which I think a little ambiguity is best. Obviously it is best if it is with the gesture location, but it could be dismissed, or part of an introduction.
> 
> I'm a little confused by Jon's comment about the turn-off aspect, I didn't see that in the doc?"
> 
> <Kim_Patch> Jennifer: I think Alistair's comment is already addressed– it does cover motion actuation now. Anything that's required needs to have instructions, not just supplementary – we've covered that all functionality that requires the use of custom interactions yeah I agree
> 
> From Bruce: "The phrasing of the SC seems very straightforward. OTOH I agree with the concerns raised in comments. But I think those are just about the non-normative Understanding doc.
> 
> Good catch by@Rachael that we need exception phrasing for situations like games when the gestures are ambiguous (by design) for all users!"
> 
> Brooks: "I like the SC "Instructions for Custom Interactions" better than I like the more narrow title "Gesture Instructions"."
> 
> <Kim_Patch> Marc: agreeing with comments we've already addressed
> 
> TPAC minutes: https://www.w3.org/2019/09/19-ag-minutes.html#item01
> 
> <Kim_Patch> Last thing is to see if there are more implementation and techniques for this beyond what we have.
> 
> Summary of Action Items
> 
> Summary of Resolutions
> 
> [End of minutes]
> ___________________________________________________ 
> 
> Kimberly Patch
> 
> www.redstartsystems.com
> - making speech fly
> 
> PatchonTech.com
> @PatchonTech 
> www.linkedin.com/in/kimpatch
> ___________________________________________________