Re: Objection to password role

Hi,

I've pretty much stayed out of this discussion this time around, but I
think Jason has asked what I consider to be one of the fundamental
questions, albeit not explicitly.

> *What I don’t understand in this entire discussion is why some people
seem to think that adding a password role would make the situation
described in the above quote by Rich worse than it is now.*

The problem with "password" is that for over 20+ years of the internet, the
idea of a password field has earned some presumed security and privacy
features that you often don't think about - certainly not actively. For
example, if you type a character string into an input type="password", you
cannot then highlight and copy what is rendered on screen, and paste it
into a text editor to see the string - it will copy and paste as "stars".
That's just one example, there are others (for example "...browsers are
likely to save the value for autocomplete  unless they explicitly recognise
the role as defining a real password  field.” - Chaals McCathieNevile
(Yandex) -
https://lists.w3.org/Archives/Public/public-aria/2016Apr/0054.html.)

This, I believe, is also what Virginie Galindo (WSIG) was referencing when
she wrote:

“My concern is more aligning a user context, and the behavior of the
browser/tool  : aka taking special care of the data. It seems to me that in
terms of security, the creation of the role, password, is valuable if you
have a secure expected usage associated. By secure, I mean, making sure the
content is protected from direct reading on the screen, special protection
against (including unexpected cloning or storage) *and* that the user is
getting a sense of the sensitive situation he/she is dealing with, while
entering the password (as mentioned by Chaals and others).”
​ -
https://lists.w3.org/Archives/Public/public-aria/2016Apr/0160.html


Now you likely all already know this, but you also probably don't actively
think about that when presented with a password input. So my overarching
concern has always been not just what the screen reader software speaks
aloud when you are interacting with the input, but also what you
*understand* - that for a non-sighted user, they must *trust* that it is,
indeed, a real password input in all of it's presentation (and not just
playing one on TV). This is why I pushed hard for the warning language I
presented.

Joanie pointed out the minute difference between a native password input
and a custom password input, by noting that the screen readers will read
out either "slightly" differently (or, at least, that is her assertion):

> For instance, given:


​​
<input type="text" aria-label="password" />

 When the input gets focus, a screen reader will say something like
"password edit" or "password entry". In contrast, given:

     <input type="password" aria-label="password" />

 Those same screen readers would say something like: "password edit
protected" or "password password text". So if the user refrains from typing
until the screen reader has completed its output, that user should be able
to distinguish a real password input from a fake one.

 (Most users I know hear "passwo" and immediately start typing, cutting off
the screen reader's output in the process. Such a user would then likely be
unhappy to hear his/her password being announced via key echo.
​
But if we do live in a world with author-created fake password fields, that
might be a habit users who are blind should get out of.)
​- https://lists.w3.org/Archives/Public/public-aria/2016Jun/0117.html ​

Finally, I will note that both Birkir and Jason​ - both are self-identified
SR users - have recently
​entertained
a rename to something like role="masked", and honestly I would support that
in a heart-beat, as it makes clearer what exactly is happening (the
characters are supposed to be masked on-screen), and the proposed
functionality of the screen readers would remain the same as for the
proposed role="password". So then it just becomes a nomenclature issue, but
one that doesn't suggest properties on the faux input that don't exist,
which I assert the term "Password" does suggest today.

​JF​


On Tue, Jun 21, 2016 at 11:57 AM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:richschwer@gmail.com]
> *Sent:* Tuesday, June 21, 2016 12:38 PM
>
> People are doing this already. One example is what if you want the user to
> see the password they are typing based on their request? You are not going
> to do that with the HTML password unless you write it elsewhere. Our
> argument is that people are doing this already. CSS does things that
> encourages people to break accessibility too. That does not stop them from
> putting it out the door. JavaScript encouraged people to create custom
> controls that were not accessible. We invented ARIA. We did not say Don’t
> do that. Also, it is much more work to do something other than use an HTML
> password so why would they do it unless they needed to provide additional
> functionality? I challenge you to tell developers not to use JavaScript
> because it encourages them to create things that are inaccessible.
>
>
>
> I would also argue that putting role=“password” on an element does nothing
> advance the work of someone trying to create a custom password. So, it
> encourages nothing. In fact, John Foliot placed some excellent warning text
> about this to address that point which was passed as a decision.
>
>
>
> *[Jason] What I don’t understand in this entire discussion is why some
> people seem to think that adding a password role would make the situation
> described in the above quote by Rich worse than it is now. Adding the role
> would make the custom password widgets more accessible, which can only be
> desirable. We’ve already addressed the question of how assistive
> technologies should implement it, and I haven’t noticed any attempt to
> reopen that issue.*
>
>
>
> To be clear, I don’t want to see the progress of ARIA 1.1 toward Candidate
> Recommendation delayed by continued controversy over this feature. I do not
> object to the inclusion of the password role, but I don’t mind if it’s
> deferred to ARIA 2.0 (not, as should be clear, that I’m advocating such
> deferral).
>
>
>
> ------------------------------
>
> 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.
> ------------------------------
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion