RE: Mikes request that we identify an upper limit on the number of digits

In addition to these significant and salient concerns, it has been suggested (in a contribution by Gregg Vanderheiden, if I remember correctly - my apologies are due if I'm misattributing) that there remains the question of whether people who cannot recall or transcribe information can successfully use the alternative authentication methods that are available to implement this proposed SC. Those alternatives also have associated cognitive demands. For this proposal to be of benefit, the cognitive demands of the alternatives have to be such as to make them usable by people with learning/cognitive disabilities who cannot use the authentication schemes that the proposal is designed to exclude.

Again, we need a solid basis for resolving these questions (either way), that goes beyond anecdotal evidence.

From: Michael Gower [mailto:michael.gower@ca.ibm.com]
Sent: Tuesday, November 28, 2017 9:53 AM
To: lisa.seeman <lisa.seeman@zoho.com>
Cc: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: Re: Mikes request that we identify an upper limit on the number of digits

> For example a code with five digits is both too high  for accessibility

One of the issues IBM opened against this SC is that to date you have supplied no data to support this statement, or to support the notion that transcription represents an impediment significant enough that an SC is warranted to entirely prevent its use to satisfy authentication. As mentioned in Issue #442<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F442&data=02%7C01%7Cjjwhite%40ets.org%7C28d43826857a4f274ecf08d53670d583%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636474780603183539&sdata=q5H4iss%2Fgx7dyaRBDa2fP7vNq1kh0NMcmTGTLhTPTyw%3D&reserved=0> the only study cited so far was a study that showed that every participant was able to transfer 5 digits. So why keep repeating that 5 is too high?

I identified the concern to you last November and the concern about prohibiting copying was flagged and discussed back in April<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F23%23issuecomment-295271211&data=02%7C01%7Cjjwhite%40ets.org%7C28d43826857a4f274ecf08d53670d583%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636474780603183539&sdata=tjY2yQv%2BGJHN0L6QcSxYSwWYcHccHWUGg%2BEVyVkRZnc%3D&reserved=0>. Issue 442 has been open since October 8 with no response. This concern is not coming out of the blue, nor am I the only person to voice it.

Other considerations include identifying thresholds and relying on assistive technologies to augment experience to satisfy individual users needs. As an example, look at the thresholds for Contrast (Minimum). The SC demands a certain level of contrast for content. That is not going to satisfy the needs of all users, but based on a bunch of analysis and data, a threshold was established, with the assumption that a user who requires more contrast is going to call on an AT to augment.

My expectation would be that based on data, we would be looking at something similar for guidance on allowable transcription. If we don't have that data, then we are basing this SC on anecdotal evidence -- and as others have identified, it's an SC with far-reaching ramifications.

The new Animation from Interaction SC, designed to address vestibular disorders, had its timing parameters removed and its designation as a double AA moved to a triple A category because there was insufficient data to establish enforceable thresholds.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com>
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        "lisa.seeman" <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
To:        "W3c-Wai-Gl-Request@W3. Org<mailto:W3c-Wai-Gl-Request@W3.%20Org>" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Date:        2017-11-28 12:45 AM
Subject:        Mikes request that we identify an upper limit on the number of  digits
________________________________



Hi Folks

Mike had requested empirical evidence for what is the maximum number of digits that can be reliable copied form a device for multi factor authentication.

I am looking into it, but I actually think we should not enforce a  limit in the number of digits. Enforcing a limit on the number of digits in a security code will definitely jeopardize security. For example a code with five digits is both too high  for accessibility and lower then most secure applications would require.  It is much better to give the user an option of sending the code to the computer via Bluetooth/ token or even QR code.

Please let me know if we want to go this rout. If not it is a lot of research for nothing.

in the mean time Neil found some more research on sequencing problems that is useful in case we decide we would want to go in Mike's direction.

All the best

Lisa Seeman

LinkedIn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__il.linkedin.com_in_lisaseeman_%26d%3DDwMFaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DtcZJERjAATEfWh8o3Quzj5utQjhTc616ftI-pq0PQ14%26s%3DRGFbNF5-vOg9zvILYyAN-w4_ahdJUxUMlyGb42Entjs%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7C28d43826857a4f274ecf08d53670d583%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636474780603183539&sdata=ucpqhOeLh5ULTH5ZkW9jzkkdtLvRgAXm0UIyvm3WjHA%3D&reserved=0>, Twitter<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__twitter.com_SeemanLisa%26d%3DDwMFaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DtcZJERjAATEfWh8o3Quzj5utQjhTc616ftI-pq0PQ14%26s%3DkX63euaZtgBEAbnCKIQIWsjf886TzFbHmO_HcVfF6RI%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7C28d43826857a4f274ecf08d53670d583%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636474780603183539&sdata=m%2FJfrE2GediWEE0yh4oHbmg7gHKavieO7N1g0swXVzM%3D&reserved=0>




________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Tuesday, 28 November 2017 16:05:01 UTC