Trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 25 April 2019
<Kathy> https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6
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.
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: Kim_Patch, MarcJohlic, Kathy, Jennifer, Jake Present: Kim_Patch MarcJohlic Kathy Jennifer Jake JakeAbma No ScribeNick specified. Guessing ScribeNick: Kim_Patch Inferring Scribes: Kim_Patch WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 25 Apr 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]