MATF Minutes 25 April 2019

*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>
___________________________________________________