Slicing and dicing password role discussion

There's a thread on the ARIA admin list about the password role:

https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/thread.html#msg18

(Note I think once the discussion got past objecting to the proposed 
consensus, it should have moved to the main working list since it became 
substantive rather than administrative, which is why I'm posting here 
out-of-thread. I'll work separately on mechanisms to ensure that happens.)

I think there's been an emerging consensus about what should happen in 
an ideal world, but a lot of concern about what might happen in the real 
world if the password role is deployed. Some of those concerns seem to 
me to boil down to, it's great if the right thing happens in response to 
the password role, but disastrous if your tool happens not to support 
it. Almost nobody wants to rely on the author to work around those 
situations, so it really comes down to tool support.

The problem is, there's a bit of a "can't get there from here" 
situation. If the password role is something authors can use, it will 
probably be in use in the wild before all user agents have started 
supporting it. Therefore authors' use of it could be highly problematic. 
Yet if it isn't something authors use, tools will probably not support 
it. We also have to consider the situation in which we do not provide 
the password role, but authors don't want to use input type=password, so 
they use something completely unsecured - which I think some in the 
thread believe is likely to happen.

Given that there's no absolutely clear path, I tried to break down the 
different options so we could see least-bad choices. The attached table 
considers 1) what would happen if mainstream user agents support the 
password role (including passing information about it to the AT), 2) 
what would happen if AT support password without relying on features of 
the UA, and 3) what would happen if neither support the role. This is 
explored for input type=password (i.e., what happens now on passwords 
and is broadly implemented), password role on another field, and author 
feature that has no password semantic of any kind. I put emphasis tags 
around aspects that are "bad". I assumed "good" is, from the discussion: 
1) user knows it's a password field, 2) input is masked on screen, 3) 
input is masked in auditory output, 4) key echo is off so the password 
does not leak to listeners as it's being typed.

If I got the data right, there's almost no perfect situation. But there 
are some really bad situations - when there is no password semantic, or 
when neither the mainstream UA nor the AT recognize the password 
semantic. Yet if either the UA or the AT recognize the password role, 
things get a lot better (best if both do). There were proposals in the 
thread both for UA requirements (which is normal for ARIA, except some 
of them are for UI requirements which would be exceptional), and for AT 
requirements (which is not normal for ARIA).

Looking at all this, I think the decision about what to do first comes 
down to whether we believe authors will deploy non semantic password 
inputs if we do nothing, but would mark them with the password role if 
it existed. If we think authors won't try to do this much, it seems best 
to rely on the existing input type=password as that has some of the 
least scary effects. I haven't seen a lot of solid data about that in 
the thread, some believe one way, others the other. Until we get 
consensus on the answer to that question, I think the other discussion 
is peripheral.

If we do think authors will create their own password inputs in spite of 
a lack of available semantic, then we need the password role. From 
there, the question becomes what can we do to make it most effective in 
the shortest time and with the least problems during the period of 
incomplete implementation? To me, the best choice seems we should 
negotiate an exception to the principle that ARIA does not impact UI, 
and say that because of its security implications, user agents need to 
do input masking on the password role, not just tell the AT about it. If 
that's a no-go, we could see if ATs will agree to broadly expand their 
security of passwords - but we've had difficulty with that sort of thing 
in the past, there are more ATs than mainstream UAs and they don't 
always implement quickly. Either way, I think it's also important to put 
some highlighted best practices for authors saying they should at least 
use the word "password" (language-specific of course) in the accessible 
name so even without tool support users know it's a password field and 
to be extra careful (I don't think we can meaningfully make normative 
author requirements, so has to be best practices). This won't solve 
everything, but it will be a lot better than if we do nothing. I do 
think if authors are taking the time to apply the password role, they 
will see the value in taking the additional step; it's authors who don't 
even care who will create a real problem, but there's nothing anybody in 
W3C can do about that.

Michael