- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Fri, 26 Apr 2019 11:30:17 +0200
- To: public-mobile-a11y-tf@w3.org
- Message-ID: <87a2635f-989f-39ec-a0fa-cf0d356399ce@testkreis.de>
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
Received on Friday, 26 April 2019 09:30:45 UTC