Re: some questions: : working on re-authentication

Depending on jurisdictions, a bank is likely covered by regulations that 
make it fall under the exception.
I do not recommend you focus primarily on something like a bank when 
trying to QA this SC, as banking is by nature an environment where 
heightened security is a requirement.

Michael Gower
IBM Accessibility
Research

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



From:   "lisa.seeman" <lisa.seeman@zoho.com>
To:     Alastair Campbell <acampbell@nomensa.com>
Cc:     "WCAG" <w3c-wai-gl@w3.org>, "John Foliot" <john.foliot@deque.com>
Date:   2017-12-21 04:31 AM
Subject:        Re: some questions: : working on re-authentication



Hi Alastair

I do not think it is  supported in 1.3.1. (info & relationships) or well 
supported in 4.1.2 or even "purpose of common controls". 
My bank (the example from hell) gives you different login number/card 
number where a "user id"  needs to match a password. 

The password card id number is not part of the list of purpose of common 
controls. The role and name may be accessible, but auto complete is not 
"on" and I suspect they often change the name attribute about once every 
two months  because once the password auto fill thing works and then it 
stops. What is more it needs to match the card number ID and password, and 
they give me a new card each time I go to the back (because I am locked 
out again...). three mistakes and you are blocked again. Basically they 
may conform to the other SC's but I still can not use it.

(Yes I think of changing banks but I do not know that another one is 
better until I have an account there)

All the best

Lisa Seeman

LinkedIn, Twitter




---- On Thu, 21 Dec 2017 14:13:34 +0200 Alastair 
Campbell<acampbell@nomensa.com> wrote ---- 
Hi Lisa,
 
(John – question for you below.)
 
For this:
- authentication process can rely on the user or user-agent entering 
personal identification information such as name, username, password, and 
email address if the web content consistently supports automatic entry.
 
> Automatic entry of user information can not work because autocomplete 
and the name is not set . It is not quite blocking the user agent rather 
they are not supported. 
 
 
If the username/password (or other) inputs pass 1.3.1. (info & 
relationships) and 4.1.2 (role/name/value) then user-agents currently 
support automatic entry unless the site actively blocks it. 
 
Also, there would also be overlap with the new SC that requires the 
autofill attributes, which I think includes username and current-password? 
(JF – have they been kept in the list?)

Therefore, I would like to revert that change to avoid overlap with other 
SCs.
 
 
> Also if transcribe follows the dictionary definition we can just clarify 
what we mean in the understanding section. Is that Ok?
 
I think that would be best.
 
Cheers,
 
-Alastair