E-mail List Archives
Thread: qr code and guidelines
Number of posts in this thread: 6 (In chronological order)
From: Bo Nilsson
Date: Fri, Sep 11 2020 2:42PM
Subject: qr code and guidelines
No previous message | Next message →
Hi!
How do the accessibility guidelines apply to the use of qr code?
More precisely, the use of a two device login to a computer application
which requires a mobile to detect a qr code from the computer screen?
Must there be an alternative for those who not have a visual screen or cant
handle it?
Or for those not have a mobile?
Best regards
Bo nilsson, list member from Sweden
From: Joe Humbert (A11y)
Date: Sat, Sep 12 2020 7:28AM
Subject: Re: qr code and guidelines
← Previous message | Next message →
Hi Bo,
In my opinion, its always good to have an alternative way for 2-form factor
authentication (2FA) (e.g., Authenticator app, phone call, text message,
email, etc.). For example, any users camera could be scratched or an update
to the camera app could be screwing things up.
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, the (2FA) motion could be deemed essential
(probably would be for security reasons). But an alternative would fulfill
this SC.
I have seen scanning functionality implemented fairly accessibly for users
with vision impairments when real-time auditory feedback is provided (e.g.,
no code detected, camera to close, move back to focus, Code successfully
scanned, etc.). If this auditory (and hopefully Braille compatible)
feedback is implemented, it will go a long way to making it accessible.
However, users with mobility impairments, particularly those who mount their
phones in a fixed position (e.g., to a wheelchair) may still find scanning
the QR code difficult.
Hope this helps.
Thankx,
Joe Humbert
Accessibility Champion
Android & iOS Accessibility Novice
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Bo
Nilsson
Sent: Friday, September 11, 2020 4:42 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] qr code and guidelines
Hi!
How do the accessibility guidelines apply to the use of qr code?
More precisely, the use of a two device login to a computer application
which requires a mobile to detect a qr code from the computer screen?
Must there be an alternative for those who not have a visual screen or cant
handle it?
Or for those not have a mobile?
Best regards
Bo nilsson, list member from Sweden
http://webaim.org/discussion/archives
From: Patrick H. Lauke
Date: Sat, Sep 12 2020 7:44AM
Subject: Re: qr code and guidelines
← Previous message | Next message →
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
From: Joe Humbert (A11y)
Date: Sat, Sep 12 2020 8:22AM
Subject: Re: qr code and guidelines
← Previous message | Next message →
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 ADDRESS REMOVED = > On Behalf Of
Patrick H. Lauke
Sent: Saturday, September 12, 2020 9:45 AM
To: = EMAIL ADDRESS 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
From: Patrick H. Lauke
Date: Sat, Sep 12 2020 8:55AM
Subject: Re: qr code and guidelines
← Previous message | Next message →
On 12/09/2020 15:22, Joe Humbert (A11y) wrote:
> 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.
That's where we'll disagree then. And in the example with the camera,
it's the actual gesturing that is key (just expressed quite awkwardly
and confusingly). Read through the rest of the understanding doc (and
see the various techniques/references, concerned with things like
functionality triggered by polling the gyroscope sensors etc) and it's
hopefully clearer what the idea here is.
https://www.w3.org/WAI/WCAG21/Understanding/motion-actuation.html
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
From: Patrick H. Lauke
Date: Sat, Sep 12 2020 11:55AM
Subject: Re: qr code and guidelines
← Previous message | No next message
Related, this was mentioned before here but don't think there's been a
definitive answer https://github.com/w3c/wcag/issues/1120
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