Failure technique for 2.5.6 Concurrent Input Mechanisms

[patrickhlauke]

No description provided.

[detlevhfischer]

Can you perhaps add a link to a rendered version?

[patrickhlauke]

[edit: outdated link, see latest comment for new link]

[jake-abma]

nice one @patrickhlauke , will also fit a new SC I'm working on for hidden functionality via gestures (touch)

[jake-abma]

Think the procedure needs some attention. An introduction may be possible but the steps should be concise and clear on their own.

1. Open the content on a device ...
2. Controls are still visible for...
3. The controls can be operated using not only...

Cheers

[patrickhlauke]

thanks for looking, and good point @jake-abma - made an update, new githack rendered version [outdated link - see latest comment for correct up-to-date one]

[DavidMacDonald]

Seems like we'd need another device open that is not a touch screen, otherwise it will be hard to do a check to see if all the interactive controls are present and usable... to compare

I also have a bit of concern about the length of time of this check... but at AAA its OK. If we move it (or an SC like it) to AA we'd want to think about ways for this to be tested faster.

[awkawk]

@patrickhlauke this is a great start. I think just a couple of minor edits and it is ready.

[mbgower]

By constructing it this way, it's a little hard to add the whole failure technique to Pointer Gestures, since not all of it applies (it seems fine to add to Keyboard, since all your examples apply).
I'm wondering if you've encountered real world examples of your last example ("Hiding/omitting controls for mouse users when a touchscreen is detected"). It seems like an outlandish thing to do.

Getting back to a few of the questions you raised in the latest debate on Reflow...
I don't think we need to protect from what I'll regard as really crappy but possible design (here, removing all controls from a page based on detecting touch). Philosophically I think that the best approach is to write a failure technique that has fine enough netting that we create something that is beneficial. We want to give thought to ensuring it's not easy to game the system, but I think we also don't need to get into contortions to prevent it. If there is an easier path to meeting the intent, I'm content to put some stock in people understanding the advantages of keeping things mult-modal; I don't think we need try to cover every possible loophole.

With that in mind, I'd suggest stripping out the last example, thus leaving the more likely failure examples and allowing a failure technique that can consistently apply to both Keyboard and Concurrent Input Mechanism.

[patrickhlauke]

I'm wondering if you've encountered real world examples of your last example ("Hiding/omitting controls for mouse users when a touchscreen is detected"). It seems like an outlandish thing to do

I've seen it done (admittedly a while ago, and it has since been amended) for carousels - where on the presence of touch, the site hides the left/right chevron controls (under the assumption that hey, it's a touchscreen-only device, so user will want to just swipe left/right and won't need those controls...as such, also a failure of pointer gestures - and the preceding examples of listening to just touch probably (?) also fail gestures as they block/omit mouse, which is a pointer?). Happy to perhaps single that particular failure out into its own mini failure?

[mraccess77]

@mbgower I see folks hide the visual indication of focus when the mouse is used -- so it's not that unrealistic to expect some designer or developer to think it's a wonderful idea.

[mbgower]

@mraccess77

I see folks hide the visual indication of focus when the mouse is used -- so it's not that unrealistic to expect some designer or developer to think it's a wonderful idea.

I'm just questioning whether we need to cover every base. If folks do think this is a necessary hole to close, I think Patrick's suggestion that he isolate the mouse example into its own separate failure is best. It then allows us to properly assign it to this and to Concurrent Input Mechanisms. It's tidier.

[patrickhlauke]

It then allows us to properly assign it to this and to Concurrent Input Mechanisms. It's tidier.

just to note that this IS for concurrent input mechanisms, primarily. and that the hiding thing will also affect keyboard users, not just mouse users. but yeah, let me know either way, happy to split it as a separate failure technique (as i'm lazy, i'll likely copy/repurpose some of the structure from this for the new one too)

[alastc]

Hi @patrickhlauke, could you separate those out please? We'll come back to it as soon as that's done.

The other aspect that came up was Jake's comment that the second example doesn't necessarily fail unless it also relies on touch events. https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results#xq4

An idea to address Rachael's comment is to extend the first paragraph in the Description:

"input modalities. There are many possible input devices but most fall into a category of either mouse or keyboard and can be tested as such."

[patrickhlauke]

just to be clear then, the idea is still that the failure relates to 2.5.6, right? (thinking specifically about the "If checks #2 or #3 are false, the content fails the Success Criterion." part here. Or is this technique going to be referenced from various SCs?

As for Rachel's comment, I'm a tad confused - it says the description should mention that users may need other input mechanisms, but currently I thought the description does this already. Alastair your suggestion is for the "When to Use" part? Or are you suggesting changing the ending of "are unable to use other input modalities available to them (such as an additional/external mouse or keyboard)"?

Also just to pick up on @mbgower's comment in the questionnaire about whether the second example also fails Pointer Gestures: this probably goes back to our other discussion about swipes/gestures, what is a swipe (a quick flick rather than a slow dragging of a slide), and whether the carousel just reacts to flicks versus slow drags, but yes that can be updated/clarified in line with the other discussion as well.

[patrickhlauke]

@alastc also, meta point about filenaming: on the mailing list i see it was mentioned that techniques should not be numbered at this stage to avoid clashes...so what/how should this file (and the split out second example/failure) be named?

[alastc]

Hi @patrickhlauke,

Yes, still intended to be a failure of 2.5.6, on the basis that you could test the same interface with a non-touch screen and a keyboard and it would pass 2.1.1, there's a gap.

So in terms of separating it (keyboard first), I'd suggest:

• tweaking the title (Failure due to keyboard interactions being removed touch on touchscreen devices?),
• remove second example,
• update procedure (remove 'mouse' from the 1st step, remove second step?, adjust third).

On Rachael's point, it is covered somewhat in the understanding doc and she can live with it as-is, it just seemed like a gap if you come to it here. My suggestion was to replace the end of the paragraph starting from "input modalities", with that text.

With the separation, the whole paragraph could be:

The objective of this Failure is to describe situations where users on devices that have a touchscreen are unable to use other input modalities. There are many possible input devices but most fall into a category of either mouse or keyboard and can be tested as such. This failure technique focuses on keyboard testing.

File naming: In the failures folder, just something like concurrent-keyboard-input.html. Especially as your branch is not in the repo, we can't merge in without clashes.

Thank you :-)

[patrickhlauke]

So in terms of separating it (keyboard first), I'd suggest

but not allowing mouse interactions when touch is detected is also a failure of 2.5.6 ... or is that supposed to then go in yet another failure?

[alastc]

That is what spliting would mean, isn't it? (As per Mike & your comments above.)

Logically if it fails on one or the other, it fails the SC.

Between @mbgower and @jake-abma at least I think there was a feeling that the mouse one wasn't necessarily a failure (without some JS code making it specifially touch events), and it would be easier to have separately.

Not a problem to leave the mouse one for now.

[patrickhlauke]

i thought the splitting was the first example and then the second example. this seems to want to split aspects of the first example as well, so three overall?

[patrickhlauke]

to idea is that when touch is detected (in both examples), some authors may choose to suppress everything non-touch, so both keyboard and mouse. both examples are failures of 2.5.6, and on top of that, if keyboard was indeed also suppressed, then the're also for that situation a failure of 2.1.1. and in the carousel example, depending on how we treat "gestures" in that other discussion, if the touch-only carousel then ALSO only works with flicks/gestures, then it's also on top of that a failure of 2.5.1.

[edit] and if it's not clear enough: the carousel example would fail 2.1.1 IF the controls that are now hidden were the only way in which keyboard users could move the carousel - the only controls that they could TAB to and activate. of course, if the author somehow added alternatives like being able to focus the entire carousel and use cursor keys, then no it won't fail 2.1.1. [/edit]

when there was talk of splitting, i thought the idea was to split example 1 from example 2. but both examples also have mouse aspects. so to test the failure, you'd not want to just check if keyboard was blocked, but also check if mouse still works or not.

if the site did something funky like ignore mouse, but NOT keyboard, when a touchscreen is detected, there can be situations where it would pass 2.1.1, but still fail 2.5.6 because it stopped mouse from working.

for this reason, i originally set out to make the failure purely aimed at 2.5.6, but just mention 2.1.1 and 2.5.1 in passing, as there are ways for things to fail 2.5.6 but NOT the others.

[jake-abma]

Hi @patrickhlauke wondering what your view is on the following:

You mentioned:

"just to be clear then, the idea is still that the failure relates to 2.5.6, right? (thinking specifically about the "If checks #2 or #3 are false, the content fails the Success Criterion." part here."

I don't think it is correct to do the "or" in combination with the title, as this is:

Failure due to interactions being limited to touch only on touchscreen devices

Nr: 2 is:

Check that all interactive controls (such as links, form inputs, or complex custom widgets) are still visible/present (compared to the same content when viewed on a device without a touchscreen)

That has nothing to do with "limited to touch"right?

Example: I have a touch enabled laptop / tablet and use a (Wacom tablet with a) pen. The "@media (pointer: coarse) { #widget .controls { display: none; } }" hides previous/next buttons. But with my pen I can still (kind of) swipe left/right and the next carousel slide will be activated.

In this case according to Nr.2 I fail but it's NOT being limited to touch only on touchscreen devices.

[patrickhlauke]

@jake-abma i think you're looking at outdated raw githack views. the most current one is [removed now outdated link, again...] [the various githack links don't automatically update ... going to remove the outdated ones from the previous comments]

[jake-abma]

thanks @patrickhlauke a big +1 for the rewording

[mbgower]

thanks for the changes, @patrickhlauke. I think it can go forward.

[Ryladog]

+1

…

On Tue, May 21, 2019, 3:29 PM Mike Gower ***@***.***> wrote: thanks for the changes, @patrickhlauke <https://github.com/patrickhlauke>. I think it can go forward. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#690?email_source=notifications&email_token=ABL6VSQDKUY7CSTV3IANBWDPWREPZA5CNFSM4HEAS422YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV452EQ#issuecomment-494525714>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL6VSWELDPTDTEZFRNVQZ3PWREPZANCNFSM4HEAS42Q> .

[patrickhlauke]

very latest githack version of this is https://raw.githack.com/w3c/wcag/174147778be2992c2375dbfb143c9343eac31d91/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html

made a few changes:

• turned the if (!( ... )) clause around and removed the negation at the start to hopefully make it more readable (i'm sure i saw a comment from alastair to that effect, but maybe i dreamt it?)
• expanded the title and explanation of the second example to make it clear it's also applicable to mouse and keyboard

Not sure why i'm now getting travis-CI failures...but assume it's to do with the renamed file. not sure how to fix this...

[patrickhlauke]

so, just to clarify: do you (e.g. @mbgower et al) still want me to somehow split this into separate things? or is it clearer now that there wasn't a clean/natural split between an example that applies to keyboard and one that doesn't? and @jake-abma does this also clarify the issue about carousels etc that allow mouse?

[jake-abma]

yes again, Nr.2 does the trick, +1