Kathy: word document sent on
Saturday
... at 5:16 AM Eastern time
<Kathy> https://www.w3.org/TR/WCAG21/#concurrent-input-mechanisms
Jake: I focused on the text already present – reshaped to make sentences a little simpler. Everything that was in there is still in there Except import agnostic we already explained in formal definition and making assumptions
Kathy: I would add clarification about what we meant by exception. Security exception example will help, do we need more text in the understanding as well
Detlev: what are the scenarios
where the security concerns prevent certain input – I agree
with Kathy that we should add something on that. Maybe Patrick
has ideas
... first example worded differently than the others – Maybe
not an example or could be rephrased to make it a clear example
of a particular mobile phone user
... second example "users" rather than singular user as in
other examples
Kathy: a lot of it is originally
Patrick's text, definitely resources and techniques
... for security – the whole notion around requiring signatures
on a computer – requiring that to be on a device that has a
touchscreen or a touchpad so you can draw signature – That
might be an area where you have to have a touchscreen or
something to draw on in order to meet security or requirements
for something. I don't know whether that's a good example but
that's the only thing I can think of that's come up for
that.
Detlev: I wonder whether hardware limitations would come in – may be no USB ports for security reasons so can't attach a mouse – could this be relevant here
Kathy: yes, and I think that's where essential comes in. Another scenario is restricted for testing purposes
Detlev: this is user agent stuff – would it affect authors in some way
Kathy: I recommended changing the
language to the web content doesn't restrict. I felt that was
easier to write techniques for. But we wanted to keep in
exceptions for that. The restrictions in my mind with the
exception of doing an actual exception in the web content – I
don't see that the others apply given the fact that we've
changed the language upfront to be the web content doesn't
restrict.
... Given this discussion it might be good to add clarity
around the actual web content restricting input modalities
rather than talking about devices, and maybe put a comment or
question back to the working group into the understanding
document – exceptions need to be clarified and we need to have
information in understanding for them but because of the way
That we've changed the beginning part of this the task force is
questioning whether or not these are
actually still relevant exceptions
Jake: we didn't do the proper research to find where this exception applies – we will probably discover it after some research.
Kathy: I think we could put a
question in to see if we need these examples because the
exception may not apply. Testing and signature are the two
things that I can think of that has impacted my clients that
I've worked with
... as far as why we wouldn't want to have a particular input
mechanism
Jake: a little bit of the same when you have packages delivered in front of your door and you have to sign – example of hardware limitations
Detlev: might be other ways to authenticate a transaction that would require you to move a pointer – doesn't do any harm, except might allow authors to justify
Jake: will ask Steve if he has clear examples
Kathy: any other feedback for
Jake?
... restriction would be that signature is essential
... within device can turn on and off certain input mechanisms,
but that does not apply anymore
Detlev: needs clarification
<Kathy> https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html
Detlev: I was more specific on
multipoint and path gestures
... just to make sure people have a clear understanding of what
is path based
... emphasize that this applies to author-created
gestures
... added a few examples – two slider control examples
... related that I've found some examples in the wild – dots
underneath or buttons to the left orr the right of the
slider
... I put these on the implementations page.
... I put a call out on twitter for examples of shaking and
alternative means to do that
Kathy: Patrick responded to that – the technology is quite new
Detlev: he also said tilting in games – if anybody knows of tilting in browser-based games, add those examples
Kathy: Andrews comments on that is we can have a site that doesn't do it but we want to have at least one where they are doing something different – having a fallback so we are showing there are scenarios where This is being done in their doing something different to show one by omission and one that's actually there
Detlev: shake to undo you media
by virtue of the operating system, kind of pointless to list
those because it's a general behavior. But I haven't found
anything in content where you would be able to replicate
gesture input in some other way – so I think it's a theoretical
thing at the moment
... I haven't done work on techniques yet
... planning on doing techniques this week
Kathy: I like the examples and thought the text read well
Marc: no changes or corrections – read well
Kathy: The idea is just to get this done – Kickstarting process in the task force – when we are okay with it it will go to the larger group
<Kathy> https://www.w3.org/TR/WCAG21/#additional-sensor-inputs
Detlev: Hard to combine
... delineates focus from other sensors. This is making clear
that this is on sensors triggered by moving the device or to
the special case of the devices static and you move your hands
or maybe face to communicate with the device
... I hope that is clear enough
... pointer actuation I found difficult – most common way easy
but less common way, one example isn't a good example because
it's a technical showcase for drag-and-drop, prevent the action
by releasing it outside the target. Third way with dialog do
you really want to do this – haven't found. If it exists
somewhere in the wild that would be worth adding.
Kathy: also looking for examples in the wild for touch target size. Also looking for more mobile specific – other ideas – sites with large touch targets?
Detlev: maybe sites that focus on people with cognitive impairments – large targets
Marc: American Association for the blind site
https://github.com/w3c/wcag21/blob/label-in-name/understanding/21/label-in-name.html
<marcjohlic> https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html
<Kathy> https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html
<Kathy> https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html
<Kathy> Descriptive labels help users identify specific components within the content.
<marcjohlic> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Main_Page
Assignments is first link on the main wiki page, next section is templates. If you want to start something in the wiki, use the next section, proposals.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Detlef/Detlev/ Succeeded: s/Detlev/Kathy/ Succeeded: s/ppointer/Pointer/ Default Present: (no_one) Present: (no_one) Detlev Kathy Marc kim Jake No ScribeNick specified. Guessing ScribeNick: kim Inferring Scribes: kim Found Date: 15 Feb 2018 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]