W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

03 Oct 2019

Attendees

Present
Jennifer, Kim_Patch, JakeAbma, MarcJohlic
Regrets
Chair
Kimberly_Patch
Scribe
MarcJohlic

Contents


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

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/10/03 15:58:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Jennifer, Kim_Patch, JakeAbma, MarcJohlic
Present: Jennifer Kim_Patch JakeAbma MarcJohlic
No ScribeNick specified.  Guessing ScribeNick: MarcJohlic
Inferring Scribes: MarcJohlic

WARNING: No "Topic:" lines found.

Found Date: 03 Oct 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]