Re: Objection to password role

cc Ted.

> Regarding the password role, Richard Schwerdtfeger wrote:
> 
> I am working to get JAWS support. We do have Linux support. I have not heard from Apple or Microsoft yet.  

As Michiel mentioned in the start of this thread, there are a number of objections, including concerns from me. I'm not convinced those concerns and objections have been addressed and I'm reluctant to implement this role in WebKit.

Here's another example security problem: Browsers commonly save text typed into text fields, making it easier for users to reuse the same text later. This auto-completeable text is then available as an autocomplete in other fields, across sessions, often stored on disk. 

For obvious reasons, native password fields do not work this way, but ARIA password fields would, because they wouldn't have the security support that is built into native password fields. ARIA password fields would be plain text fields (with no security features) masquerading as password fields. This seems likely to give the user a false impression of security. I'm certain I could come up with a few more problems, and I don't consider myself to be especially knowledgeable on the topic of security. 
 
If the WG completed a security review, this point should have been raised. If it was not raised, I question the validity of the review.

> The purpose of CR is implementability. It is not to get support in every major implementation that holds up nobody on CR. The problem I have is that the people who are asking for the world are not willing to go out and get the world on board. I think putting the feature at Risk is important. If we don’t get 2 implementations in browsers that and ATs that would stop it going into the final recommendation. 

The purpose of a CR is not just implementability. It's about building a consensus of useful features that the working group thinks browsers vendors would be willing and able to implement. 

> When you have a custom password and no password role AT vendors are echoing the keyboard key typed versus speaking what is actually rendered. 

If that's really the only problem, it'd be better addressed as as  "suppress typing echo" feature (IMO, for ARIA 2.0, related to ISSUE-603) rather than a "password" role, which would almost certainly trigger some Formal Objections for ARIA 1.1. 

James