WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: qr code and guidelines

for

From: Joe Humbert (A11y)
Date: Sep 12, 2020 8:22AM


I disagree that 2.4.5 could not apply.

The SC says " Functionality that can be operated by device motion or user
motion can also be operated"

The Understanding says " The intent of this success criterion is to ensure
that functions triggered by moving a device (for example, shaking or
tilting) or by gesturing towards the device (so that sensors like a camera
can pick up and interpret the gesturing), can also be operated by more
conventional user interface components. "

I would think moving a camera into position to have the QR code may fall
under that intent. Generally, when you move a device into the correct
position and it detects a QR code something happens.

Thankx,
Joe Humbert
Accessibility Champion
Android & iOS Accessibility Novice

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
Patrick H. Lauke
Sent: Saturday, September 12, 2020 9:45 AM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] qr code and guidelines

On 12/09/2020 14:28, Joe Humbert (A11y) wrote:

> While, I don't think any WCAG SC completely covers this, it could fail
> against 2.4.5 Motion Actuation, since a user has to move the camera
> into a position to read the QR code,

That's not what 2.4.5 mandates though. It's not the motion itself that the
app is detecting, but the feed from the camera. The motion is coincidental.
The camera may be static and a user has to move the QR code in front of it
as well, meaning no motion at all may be required on the app's side. This
(just like "the user has to move their hand to move the mouse / the user has
to move their hand to tap things on a touchscreen / etc) is all exempt from
the SC.

Having a QR code reader per se does not currently directly contravene any
particular WCAG SC - assuming everything else (the button to take the
picture/start the process etc) is accessible. The one aspect that possibly
could fall under 1.1.1 is if the camera view itself is shown on the screen,
together with a targeting reticule / border / similar that gives an
indication - visually - how the QR code needs to be centered.
If this is not conveyed in an alternative/non-visual way, that could be
failure. How that's achieved may be tricky ... some sort of sonar/sound cue
that gives you aural feedback of how close/far you are from having the QR
code properly centered/in view. Also, of course it would then - as a best
practice - be good if the app kept polling the view for anything that looks
like a QR code, rather than expecting the user to press a "take picture now"
type button ... that would at least allow a low vision/blind user to just
point the camera in the general direction of the QR code, move it around a
bit, and rely on the app to grab it whenever it's sufficiently in view.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
http://webaim.org/discussion/archives