Re: Objection to password role

> I understand your concerns but we know what is needed and we have already started down the path of addressing the issues and putting dollars on it. Delaying to ARIA 2.0 will not buy us anything. If we don’t put the changes in it is not like we are going to keep working on them. We are going to have to rip the code out that is already being developed and start over again.

Who needs to rip out code? AT vendors working on a role that isn’t accepted yet? I can’t imagine this taking a lot of time to get out of the spec if you’re referring to ARIA 1.1. And I hope website developers are not using a role that isn’t even in the spec yet.

In search for a real world example, I went and had a look at a range of websites. Twitter, Facebook, Google, Microsoft (live.com), IBM ID, Amazon, Apple, IMDb, even Slack all use type=password. Fred pointed to Angular somewhere in this thread. Angular actually uses all native input fields in its documentation and tutorials.

Michael makes a fair point that some of these issues lie with custom password fields themselves and not so much this role. Nevertheless, this role feels rushed and—for the moment—doesn’t have support from a couple major AT vendors. In light of that, I think it would be better if we push this off to 2.0. If this is indeed a problem that exists, we will want to solve it properly, not rushed.

—Michiel