- From: Gervase Markham <gerv@mozilla.org>
- Date: Fri, 8 Apr 2016 17:37:26 +0100
- To: Richard Schwerdtfeger <richschwer@gmail.com>
- Cc: Virginie.Galindo@gemalto.com, public-web-security@w3.org, ARIA <public-aria@w3.org>, Mike Cooper <cooper@w3.org>
On 08/04/16 17:22, Richard Schwerdtfeger wrote: > Companies do not use standard HTML markup when they feel it does not > meet their needs. It really does not have anything to do with whether > the markup is semantically correct. This is happening now and we > don’t even have a password role. Companies that must do this for > business reasons need a way to make it accessible. They have a way to make it accessible - use a proper password field. So what you are asking for is actually a second way to make it accessible. What happens if some company then comes forward and says they can't use your solution because for security reasons they aren't allowed to label the field "password" in any way. What do you do then? Invent an alias and call it "type='mrblobby'"? There is only a certain distance one should go to accommodate ridiculous corporate requests. "We want to do passwords but don't want to use password fields" is a user-hostile request (both for users requiring accessibility technology and other users) and should be treated as such. > The bigger issue is that passwords as a technology have long outlived > their usefulness. The growing world aging population has issues > remembering passwords for all the sites they have to gain access to > so they often use a simple, short, easy to remember password across > all the sites creating a security issue. To this end even HTML’s > password is a security risk as it is much easier to hack. This can > result in identity theft and a whole litany of issues. Captchas are > also a huge problem for aging users. This may be so; but encouraging people to use non-password fields for passwords and so avoiding all the software people are using to help them manage the password problem (which does make things better) doesn't help. Gerv
Received on Friday, 8 April 2016 16:37:57 UTC