Wcag: Moving phone camera over QR code a case for 2.5.4 Motion Actuation?

[detlevhfischer]

Just wondering whether people agree that the need to move a phone camera over a printed or on-screen QR code to instantiate an app and start using the instance is a case covered by 2.5.4 Motion Actuation? I would argue that an alternative (such as a text field for the onput of the numeric equivalent) would be required to pass 2.5.4. (This is an native app case, but arguably the same could apply to a web app.) Any thoughts?

[patrickhlauke]

i'm not so sure i'd agree here, as the motion here is more incidental. you could also say that no motion is necessary if the QR code was moved into shot. or that this somehow connects to orientation (if for instance a tablet is in a fixed position, it won't be possible to move it to the required orientation), but even there it's not quite the right fit either.

my gut feeling would be this is something that falls between SCs at the moment. and while it touches on some concepts from various existing SCs, the aspects are more incidental.

at a very high level, i would flag this as a usability issue, rather than a failure against a particular SC.

[detlevhfischer]

i'm not so sure i'd agree here, as the motion here is more incidental. you could also say that no motion is necessary if the QR code was moved into shot.

Motion Actuation also covers motioning to a static device (e.g. if it was picking up hand gestures). So you might move the phone/tablet or alternatively pick up the page and move it until the QR code is recognised. In both cases I would not consider such motion 'incidental' since it is required to get the process started. And I think it is more than a general usabililty issue as it clearly affects motion-impaired users a lot more than anyone else (blind users might play around with the phone or sheet until QR is recognised, so less of a barrier at any rate).

[patrickhlauke]

but the motioning of the static device is, in essence, the page/app checking the motion sensor and only responding if movement actually happens. i.e, per the normative wording, it's "responding to the motion".

in this case, the camera on a phone/tablet may not even need to be moved if the camera is pointing the right way. it's not a necessity that the device be moved, but having to move it (or not) is more a byproduct of where the camera is currently pointing. the app/page is not responding to the motion, as it were ... it's responding to whether or not the camera is picking up a particular pattern/QR code. splitting hairs, perhaps...but this is my current read on the normative wording

when i say it's a usability issue i mean more in the sense of "it's not covered by a WCAG SC specifically". not disputing that this is a real accessibility problem, but rather that it's not covered (in my view) by any particular SC.

[detlevhfischer]

I don't think the device's motion sensor necessarily needs to be involved - normatively it says "Functionality that can be operated by device motion or user motion" so in our case, the user triggers the QR recognition by moving the sheet within the field of view of the camera - that is the motion bit. User motion towards a static device is covered in the understanding text (user gestures towards the device).
I admit it is not clear-cut but I still think an argument that the case falls under 2.5.4 can be made.

[patrickhlauke]

again, it's not the motion itself here that's the trigger though. motion (of the device and/or of the user) may or may not be involved or necessary. but it's not what actually triggers the action. and no, it's not user motion towards a static device (i.e. making a gesture AT the camera or similar) here either, not by any interpretation of the language.

This criterion concerns input through sensors which respond directly to motions such as gesturing towards, tilting or shaking a device. It does not cover the movement of users through space as registered by geolocation sensors or beacons, or events observed by the device other than intentional gesturing by the user. It also does not cover incidental motion associated with operating a keyboard, pointer, or assistive technology.

to be clear, i'd flag this in an audit as a best practice, and advise that an alternative (such as a way to manually enter a code/number/etc instead) should be present. but i don't think there's a strong enough case to handwave this (hah) as a 2.5.4 actual failure.

[mraccess77]

In my opinion scanning a QR code would not be covered by this SC. This is based on conversations we had the mobile task force years ago about what would be covered and what would not be such as a person moving around physically to change geolocation, etc.

[detlevhfischer]

Ok, point taken. Maybe we have the nucleus of a future "Input Alternatives" SC here.

[patrickhlauke]

off-the-wall idea: does the concept itself (that actually using a camera to scan a code to trigger a function/process is the only way to do it) maybe fall under 2.1.1 keyboard? (though we could of course argue over whether or not the actual act of scanning the code is the trigger itself, or whether the SC's remit only stops at making sure the "Scan now" or whatever button can be activated)

[patrickhlauke]

adding to the "input alternatives" idea - would another similar situation that currently falls between SCs be "the user activates a microphone and needs to do voice input"? this can be a real blocker for various users groups, but i don't believe (just like the camera/QR scenario) it's directly addressed anywhere. (or again, is this a very stretchy 2.1.1 failure?)

[mrazzari]

Here's another scenario for "input alternatives": an app requires the user to take a selfie to verify identity. (This is then compared against an 'official' photo such as ID card or driver license).

The selfie needs the person to: face at the camera, fiddle with the distance for focus, keep the head straight and center it in the frame, take eyeglasses off.

This is similar to the QR code scenario, because the user's motion doesn't get directly interpreted by the camera, or triggers app behavior.

Screenshot from my local gov't app:

Yet another twist is when the app requires "proof of life" in the selfie. It might instruct the user to blink an eye, smile, do a "thumbs up", tilt your head to the left, etc.

Mockup extracted from a concept video (haven't seen it in the wild):

Would this second scenario be a more clear-cut case of the user's actual gesturing triggering app behavior? (ie. advancing in the app's onboarding flow)

[patrickhlauke]

yup, this sounds like a good scenario to explore for a future SC (as this would definitely stretch the intent of the existing 2.5.4 into areas it was never intended to cover). i also don't think the proof of life part covers what 2.5.4 intended.

in fact, i'm becoming more and more convinced that that "gesturing towards the sensor" part of 2.5.4 was perhaps not the best idea to include in the original wording of the SC, as it's very vaguely defined.