RE: Show/hide toggle to reveal masked password

I’ve recently been doing some testing on show/hide passwords, and I found them to be pretty well supported. I think the positioning of them in the tab order after the input space is logical, since the user obviously has to type something to reveal it. Even where the password value is prepopulated, it still seems logical to position the ability to reveal it after the input entry itself.
In regard to accidental triggering, if one assumes the button is well named (and so not failing 2.4.6), then as others have said, I think a screen reader user is actually less likely to accidentally trigger, since they will hear the state change and of course hear the actual text where before they heard star, star, star, etc.
I also agree with other comments that where the Show password function is absent, it is not an accessibility issue per se. All users are experiencing the same limitation. There may be a greater demand on those who have difficulty with text entry, but as also pointed out, free and dependable password managers exist to offset this challenge as well.

All in all, I don’t think there is a big problem needing to be solved.

Thanks for raising, and for some of the good counterpoints offered.
Mike

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Tuesday, July 12, 2022 at 6:10 AM
To: w3c-wai-ig@w3.org <w3c-wai-ig@w3.org>
Subject: [EXTERNAL] Re: Show/hide toggle to reveal masked password
On 12/07/2022 13:30, Marc Haunschild wrote:
[...]
> The most common design pattern is, that the button, that reveals the password, is put after the input. I just took that as given.
>
> But that should fail Success Criterion 1.3.2 Meaningful Sequence and/ or Success Criterion 2.4.3 Focus Order anyway.

I wouldn't say it's as cut and dry as that, to be honest...

P
--
Patrick H. Lauke

https://www.splintered.co.uk/  | https://github.com/patrickhlauke
https://flickr.com/photos/redux/  | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke