Target Size

Change of Content

Character Key Shortcuts

Orientation

Update

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: