MATF Minutes October 3, 2019

*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 <https://www.w3.org/2019/10/03-mobile-a11y-minutes.html#agenda>
  * Summary of Action Items
    <https://www.w3.org/2019/10/03-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/10/03-mobile-a11y-minutes.html#ResolutionSummary>


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

<Kim_Patch> https://www.w3.org/2019/07/16-ag-minutes.html#item03 
https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results#xq7 
<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 <http://www.redstartsystems.com>
- making speech fly

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