Re: MATF Minutes 25 April 2019 - notes on instructions for custom gestures

Hi,

I read the minutes (still regretting I missed the MATF telco - I was 
working throguh AG issues at the time and forgot to check the time / set 
an alarm).

Just some thoughts on "Instructions are provided when content requires 
custom gestures or motion actuation" - sticking with the web mail 
swipe-to-reveal-options case brought up by Jake.

The context is that 2.5.1 and 2.5.4 already mandate alternatives for 
such custom gestures so if swiping is the *only* way to reveal 
functionality, the screen would fail (arguably it would not fail if file 
/ delete / forward etc. are available once you select a single message).

So the core of the user problem seems to be that actions that are hard 
to undo are triggered inadvertently. (Note there was a COGA Undo SC for 
2.1 whch did not make it at the time.) 2.5.2 Pointer Cancellation > 
abort or undo should cover (most of) this - if the user does not know 
which message he/she deleted accidentally and there is no easy option to 
undo (such as an accessible popover giving that option), this would 
arguably fail 2.5.2.

The question remains what valid way to instruct users about the 
functionality would be appropriate. An initial primer when downloading / 
first launching the app might help some, annoy others, and be of not 
much help to people with memory issues (or simply to anyone who intently 
or accidentally dismisses any start-up content delaying first use of an 
app - I would count myself a member of that group).

A repeat instruction on *every* use (SR accessible, visible) seems quite 
obnoxious for what is a utility app that is used daily, many times.

Visual indications via icons migh do the trick for sighted users but the 
more innocuous they are, the more likely they are to be ignored in which 
case they will not prevent accidental input errors. They would arguably 
need to be focusable / have a meaningful accName for non-visual users, 
adding many extra focus stops and probably annoying the heck out of 
repeat users. OK, there may be options to hide instructions but who 
likes delving into your apps settings? How many will do that? There may 
be options to disable app-side motion actuation and complex swipe 
gestures altogether, and these would likely be the preferred by users 
prone to accidentally performing gestures in a way that leads to 
unintended results.

So this would point to a once-shown-after-first-launch type of message 
saying something like "you can use swipe on messages to reveal options 
OR disable this in the app settings". Apart from that, 2.5.1 and 2.5.2 
should take care that there are alternative ways for activating stuff 
and undoing accidental things happening after down-event (start of 
swiping). Having explicit / visible and SR-accessible instructions 
around each time you use an app seems to me a bit of a non-starter.

Best,
Detlev

Am 25.04.2019 um 18:16 schrieb Kim Patch:
> *MATF Minutes 25 April 2019 link: 
> https://www.w3.org/2019/04/25-mobile-a11y-minutes.html
>
> * *Full text of minutes: *
>
>
>   Mobile Accessibility Task Force Teleconference
>
>
>     25 Apr 2019
>
>
>     Attendees
>
> Present
>     Kim_Patch, MarcJohlic, Kathy, Jennifer, Jake, JakeAbma
> Regrets
>
> Chair
>     SV_MEETING_CHAIR
> Scribe
>     Kim_Patch
>
>
>     Contents
>
>   * Topics
>     <https://www.w3.org/2019/04/25-mobile-a11y-minutes.html#agenda>
>      1. indication of gestures
>         <https://www.w3.org/2019/04/25-mobile-a11y-minutes.html#item01>
>   * Summary of Action Items
>     <https://www.w3.org/2019/04/25-mobile-a11y-minutes.html#ActionSummary>
>
>   * Summary of Resolutions
>     <https://www.w3.org/2019/04/25-mobile-a11y-minutes.html#ResolutionSummary>
>
>
> ------------------------------------------------------------------------
>
> Trackbot, start meeting
>
> <trackbot> Meeting: Mobile Accessibility Task Force Teleconference
>
> <trackbot> Date: 25 April 2019
>
> https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit#gid=124994642
>
> <Kathy> 
> https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6
>
> https://docs.google.com/document/d/1ouVFq4w-i0rchNHtTAG_JoRwHfYm9mN2MkxFBct1JSI/edit#heading=h.vpayye3hz4fm
>
>
>       indication of gestures
>
> Jake: might have some overlap with other success criteria
> ... operated by a user interface component the alternative ways – that 
> part
>
> Kathy: might need to be reworked my recollection – purpose of this one 
> when we had custom gestures or functionality available through motion 
> actuation if we had done some custom thing that wasn't standard 
> gestures or standard motion actuation command – if we did custom ones 
> users are informed of these instructions were available on how to use 
> them so that they could potentially alert the end-user
> ... I think that was the primary purpose. I think the second half was 
> just saying how it could be done. to prevent accidental actuation. The 
> fact that you can operate the user interface in alternative ways is 
> part of other success criteria
>
> Jake: when you open an application and you swipe halfway it reveals 
> options but if you swipe all the way in I think it's Gmail they will 
> be archived – swipe a little bit too much deleted or archived and you 
> can never get them back. But also need to be available in different 
> ways because not everyone can swipe. So it gets multiple ones at once.
>
> Kathy: I agree I think it needs to be narrowed down to inform the user 
> when there can be gestures or motion actuation so the users are 
> informed of that. There are standard gestures motion actuation that 
> are part of the device. Users will know what the standard ones are. 
> The Gmail example is getting into the custom gestures and how they 
> decided they wanted their functions to be exposed to the end-user
> ... so that's where we need to draw the line – within the custom 
> gestures not with the actual standards on the current platform
> ... logistics – we need to narrow and make some tweaks to the language 
> and agreement amongst people on the call today and then send it to the 
> full task force
>
> Marc: having the instructions for any functionality that's handled by 
> gestures and/or movement. I like the and/or movement, thinking about 
> the shake to undo kind of stuff
> ... Trying to simplify – functionality that's available via gestures 
> and/or movement
>
> Kathy: you think it should be all of them or standard ones available 
> via a platform – it could be a never-ending list
>
> Marc: what's standard
>
> Kathy: double tap to operate a button
>
> Jennifer: long hold to get more options for android
>
> Kathy: to me I think we need to narrow it – just from a testing 
> perspective as far as the test procedure goes and then what were doing 
> I think we need to have it narrowed. Otherwise were getting into the 
> infinite testing again
>
> Marc: wouldn't Google and Apple be responsible for providing 
> instruction at that level – They're responsible for that
>
> <Kathy> Instructions: Users are informed or instructions are provided 
> when content requires custom gesture or motion actuation.
>
> Kim: lots of functionality people don't know about of the platform 
> level – somehow would be good for Google and Apple etc. to be held to 
> this too at some point
>
> Kathy: may be in silver. Have to keep to the web authors at this point
> ... users are informed or instructions are provided when content 
> requires a custom gesture or custom motion actuation
> ... the whole purpose of this one is to prevent a user from 
> accidentally activating something
> ... the other option here is that the user could turn off all gestures 
> of custom actuation or motion. If they did that and there was still 
> another way to do that
> ... if we had a custom gesture or motion actuation the thing that we 
> are trying to accomplish here – instructions are provided so a user is 
> aware of it, but if a user were able to turn it off then we may not 
> need to have instructions. Trying to play devils advocate, think 
> outside a little bit about what all the different scenarios could be
>
> Marc: another angle – many of those custom just rumors of they knew 
> about them could make the task easier for them
>
> Kim: I like the idea of allowing the user to turn off, and having 
> alternatives. But you need instructions – they're going to need to 
> know what's returning often with the alternatives are.
>
> Kathy: you're right, we need to provide instructions. it would be a 
> good point in the understanding language to point out that being able 
> to turn off the custom gestures could be beneficial to some users, 
> example people with mobility impairments
> ... to that extent we could even put a comment into the understanding 
> language – everybody's point before about the fact that many people 
> don't know a lot of the standard gestures so would be best practice to 
> provide instructions to users to let them know gestures or motion that 
> would be beneficial to users. This success criteria is focused on the 
> custom gestures but that doesn't mean it would be good to provide 
> instructions to users on
>
> standard gestures etc. Kim's point about spacebar on iOS keyboard – 
> that might be a good one to include on– that might be useful
>
> Marc: useful to inform users beyond quick little tutorial that doesn't 
> come back
> ... maybe say they are available rather than just informed
>
> Kathy: I think we need to think carefully about what the implications 
> are going to be and whether or not we are comfortable with that 
> requirement overall
>
> Marc: maybe just instructions are provided when…
>
> Kathy: I'd be fine with that
>
> <MarcJohlic> From: " Instructions: Users are informed or instructions 
> are provided when content requires custom gesture or motion actuation.
>
> <MarcJohlic> To: " Instructions: Instructions are provided when 
> content requires custom gesture or motion actuation."
>
> <MarcJohlic> " Instructions: Instructions are provided when content 
> requires custom gestures or motion actuation."
>
> Kathy: any objections to that language?
>
> No objections
>
> Adding it to the Google doc
>
> Kathy: we are not saying anything about gestures are going to be or 
> not required – just saying that when there are custom gestures or 
> motion actuation that instructions are provided. We're also not saying 
> how those instructions are provided, just that they be provided
>
> <MarcJohlic> Simplify even further and make Silver-ready?: 
> "Instructions are provided for custom gestures or motion actuation.
>
> Kathy: in the plain language summary we may want to simply say that a 
> lot of the affording's is that are usually provided are known on the 
> desktop. When you get to a mobile website or application those are not 
> necessarily known in all and the really hidden overall. I think there 
> is a big difference on a mobile device because a lot of those gestures 
> and things are fully hidden. You don't know they exist until you 
> happen to do something.
>
> No affordaanc
>
> Kathy: include something so you know that it's a custom gesture or not
>
> Marc: instructions are provided for custom gestures or motion activation
> ... even simpler and more silver ready
>
> Kathy: I think once we get to the plain language and going to the full 
> working group we need to define what we mean by instructions. What are 
> we actually asking people to do? If they have some sort of affordance 
> like an icon that's indicating the Gesture that can be done is that 
> okay or do we need text – to what level and what are we actually 
> wanting for those instructions. The word instructions is ambiguous – 
> test procedures need to know
> ... We consider instructions to be
>
> Jennifer: what I think of as instructions are when you open something 
> up and it says swipe left to do this – that's the first thing I think of
>
> Kathy: that's what most people think of but we do have other ways to 
> provide instructions – a picture type thing, a hover over that is now 
> showing them they can do it. It could be that you see that kind of 
> action happening – there's lots of different things that I've seen as 
> far as people alerting users to something that exists that they can do
>
> Jennifer: we would want to make sure that those instructions are also 
> accessible
>
> Kathy: that's under other success criteria
>
> Kim: what I'd like to see is a map – seeing everything at once. that's 
> great in addition to an icon affordancBut that's probably beyond what 
> were trying to do here
>
> Kathy: you could have a technique like that
>
> Marc: custom gestures or motion actuation are documented – that way it 
> could be a map, text
> ... I think documentation is better than instructions in this case
>
> Kathy: do we have a definition in WCAG for instructions already – we 
> have one SC that talks about instructions
>
> <JakeAbma> context-sensitive help help text that provides information 
> related to the function currently being performed NOTE Clear labels 
> can act as context-sensitive help.
>
> Jake: and context-sensitive help
>
> Kathy: we don't have a definition of instructions under 3.3.2
>
> Marc: the context-sensitive help seems to do what we're trying to do 
> here – does that end up encompassing this
>
> Kathy: that's a AAA, were trying to get something in at AA
>
> Mark: that also lets you just write down instructions and store them 
> in a help menu
>
> Kathy: labels and instructions is single A – context is AAA
> ... in the success criteria we could provide a list of different ways 
> that instructions could be provided
>
> Marc: it's almost like 3.3.5 should be context-sensitive help in this 
> one should be just help – help is available
>
> Jake: we also just talked about I can do at least show that there is 
> some functionality belief it, not only providing instructions
> ... if we look at the Excel file where we started, indication of 
> gestures with icons and/or device movement. Also the idea of providing 
> those clues
>
> Kathy: my preference would be to keep what we have is instructions and 
> to define instructions as more broad – just list what could be 
> provided with examples and leave it open for the authors to determine 
> how they're providing those instructions
> ... right now there are certain ways to do things tomorrow there might 
> be new technologies. Also so different things that could come up later 
> as far as providing instruction. If we start saying it has to be in 
> text or context-sensitive help we might end up cornering this is a 
> place where we don't want to be
>
> Kim: I definitely agree it's a good way to do it and have a have a 
> good solid list of examples
>
> Kathy: other thoughts?
>
> Marc: that sounds good
> ... in a perfect world I wish we could rename 3.3.5, but were not in a 
> perfect world. I think this is good
>
> Kathy: Jake – enough information to update the plan language summary?
> ... adding comments to Google Doc
>
> summarizing what we want to do here
>
> Kathy comments in doc: Add examples of what instructions would include 
> (e.g. icons, text, tutorials) Call out that all gestures and motion 
> that is not custom is also important to help users but that this SC is 
> limited to custom gestures and motion actuatio
>
> Kathy: input assistance
>
> Jake: I was thinking the title should be changed to orientation, but 
> we already have orientation. Can we place this new scenario under 
> orientation?
>
> Kathy: I think the problem was when we were doing this success 
> criteria 2.1 originally we had this in there and it got removed. The 
> intent of that success criteria well I agree with you was change to be 
> very specific – make sure that the content wasn't restricteddue to the 
> orientation – language very specific to that. That's why I think a new 
> one is needed to handle this
>
> Jake: this is a strange specific case – link – only in landscape mode 
> but it's not really landscape mode it's just if the length is greater 
> than the height. It doesn't fit in reflow, so it's something else. 
> That's exactly what almost could fit under orientation
> ... so before we have another success criteria I thought it would be 
> better to place if possible under an existing one so we don't end up 
> with so many success criteria
> ... is it worth at least looking at again, add small tweaks, another 
> example of what also fails
>
> Kathy: we could go back to the working group and see. I think that the 
> pushback will be the SC text was very specific in how it was written – 
> we're not even saying you need to have a display in portrait and 
> landscape. Only thing we're requiring is that you're not restricting 
> the view, nothing to do with the actual content of the page
>
> Jake: I would like to call this one orientation 2.0
>
> Kathy: orientation did have this one originally, it got taken out
> ... if you look at what's originally proposed under 2.1 it went 
> through a lot of iterations.
>
>
>     Summary of Action Items
>
>
>     Summary of Resolutions
>
> [End of minutes]
> ------------------------------------------------------------------------
> Minutes manually created (not a transcript), formatted by David 
> Booth's scribe.perl 
> <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> 
> version 1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
> $Date: 2019/04/25 16:13:23 $
>
> **
> ___________________________________________________
>
> 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>
> ___________________________________________________

-- 
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites