See also: IRC log
Target Size
Change of Content
Character Key Shortcuts
Orientation
Kathy: 4 outstanding Scs
... pointer gestures 61 will go out with note
... device sensors, pointer gestures with additional,
concurrent input mechanisms
<Kathy> https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results
Kathy: I thought it would be good
on this call to get thoughts around what people's comments
were
... concurrent input mechanisms – 11 comments
... I think what's going to come up on the call – do we see
this problem in real websites
... I'm not sure people are looking at github comments
<Kathy> https://github.com/w3c/wcag21/issues/64
Kathy: Patrick's point is very
valid and I ran into that client site recently where only
touch. But will fail 2.1.1 if have only done touch
... this is saying the user should be able to switch what input
method that they are using. So if I start using mouse I can
switch over to keyboard, I can go to touch, I can go back to
keyboard. I can do certain things with certain types of input
mechanisms. I don't have to stay using the keyboard or only the
keyboard but I should be able to go between the different input
mechanisms that...
... are currently available for the site.
... we are not saying that if the site doesn't allow for touch
use it all that they have to have touch. We are saying that for
the input device or mortality that is not restricted by the
content, to allow the user to switch to those modalities at any
point
... I think it's important to note that we did change the
success criteria language
... we are basically saying that if a user has started to use
something – if they start to use keyboard it shouldn't restrict
what they may do with other input devices
... some of survey comments are old. Greg's comment was the
changes we had. People were saying it was hard to test so we
restricted that – we've changed the language completely.
Jason's comment, changed Andrews comment about who is impacted
– it can be an issue for everybody but there are use cases.
Michael's comment – we changed. David is saying we have
significant problems with...
... testability – that's new
Marc: John's comment about security – same thing comes up on a lot of SCs
Kathy: as far as testability goes
I think David's point is that he's worried about how can we
test every function by switching to a different input method.
this means that we would need to – if the system allowed you to
use a keyboard and a mouse and touch we would need to test all
of those different combinations to make sure that it still
worked. So I'd have to go from keyboard to touch...
... I'd have to go from keyboard to mouse I'd have to go from
mouse to keyboard and mouse to touch. So we have three that
means we have nine different combinations.
Chris: that becomes a disaster
very quickly
... the number of input mechanisms factorial would be the
combination that you have to test
Kathy: it is testable – it's not that it's not testable. It's that there are a lot of combinations
Chris: can we go over one of the standard use cases again? I'm thinking of testability for a standard use case. Motivation being with testability if you can transition from one to the other do you then assume you can transition to the rest – just testing one would be reasonable. I don't know if we can conclude that or not but if we can it would make testability much more reasonable
Kathy: it's no different– shifting backward using keyboard you may hit a keyboard trap, just that one thing. If you have it across all the platforms in all the browsers you're going to have different results on different browsers
Chris: can we pick a combination that they support anyway
Kathy: that's part of the report – we don't tell people in 2.1 that they have to testing all the different browsers. Here, same thing given the input modalities that they're using they should be able to switch between them. We don't tell people that no matter what keyboard interface there using they have to test for all the keyboard interfaces either
Kathy we are not talking about user agents or specifying which input mechanisms they are using or not using
Shadi: how do we test for whether it supports mouse or not
Kathy: that's where we get into accessibility support – certain browsers, assistive technologies – kind of the same
Shadi: implicitly we are requiring mouse support here and WcAG doesn't support that
Kathy: we are just saying that
not restricted
... another thing we could do is with this is a AAA requirement
instead of a AA
Chris: that makes sense – the line of thinking if this works, then most should work. That seems like a user agent problem. If you support a, B, C individually and a scenario were combining them breaks I believe that is a failure of the user agent and not the developer of the given application
Kathy: but you can do a touch only event and not have it work with the other input – it is also developer
Chris: yes, but there's an aspect
of this – make sure it works with touch, mouse, keyboard.
That's fine that's the developer's responsibility. There's the
other aspect of this that is I'm using my mouse for a while and
then suddenly I switch to touch. What I'm suggesting is the
combinations don't need to be tested because if a combination
breaks it's the user agent's fault it's the...
... developer only needs to individually test each individual
input and if they're using conjunction and combination that is
a user agent failure
Kathy: exactly, that's why we put
in the language that it's not restricted. That's what we put
into address that exact point. That also came up on the
call.
... your point is interesting – we are not saying you have to
test for every combination, we just want assurance that you're
not doing it restricted. So the test case is just to make sure
you're not using things for touch only or keyboard only. 4
Chris: that exists already
Kathy: keyboard only, but this is
expanding it further – yes we agree that keyboard is important
but it is not the only and primary that everybody is
interacting today – for mobile were not assuming everybody has
a keyboard.. If we were restricting it to only keyboard we've
got a problem. The users may want to go between using keyboard
and touch
... if we get through this one we've only got one outstanding
left – pointer inputs with additional sensors
Shadi: I think it's just a matter of the wording
Kathy: the key is not that it has to, just were not restricting it
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) Present: shadi Kathy chriscm Marc No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Found Date: 03 Aug 2017 Guessing minutes URL: http://www.w3.org/2017/08/03-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]