Not working as expected with screen readers.

[HimanshuGoel]

While using the screen reader, it doesn't spell it like 'hidden' or 'dot' in case of type as password. After using this library, screen reader exactly spells the character which we typed in the textbox.

[noppa]

Thanks for the report. However I fear this might be out of scope for this library. aria-role="password" could perhaps solve this, but apparently it's held off because the w3c people aren't liking the security implications of implementing your own custom password field (w3c/aria/issues935).

You might want do some further css trickery to show a regular password field only for screen readers. Of course, this might bring with it the input type=password problems you were originally trying to avoid with this font.

[HimanshuGoel]

Thanks, @noppa for these details. As of now, we have chosen security instead of usability until there is a solution available for this screen reader issue.

[noppa]

Sounds like a good decision. If you are looking for a "pin" style password field like the poster of that StackOverflow question, inputmode="tel" at least works on iOS Safari.

[HimanshuGoel]

No, actually we are using it like a memorable word. In which, the application presents a challenge to the user to enter some random characters of this memorable word to validate him.

[noppa]

Maybe

<input type="password" autocomplete="one-time-code" />

then? (MDN for autocomplete attribute) At least most browsers don't try to autocomplete that field. Most browsers still seem to suggest saving that as a password after entering, though, which is... still weird.

[varenc]

In a similar vein, since the browser treat these as a normal text inputs, it isn't treated with the extra special security properties that password inputs normally have. On macOS password inputs are marked as a "Secure Input" in the OS which protects them from being read by other applications even if those apps have the "input monitoring" permission. This is why Screen Readers can read out the letters. I'm sure there's other security properties of password inputs I'm missing as well.

I can see some use cases for this, but overall I worry that if people are doing this to improve security, they'll just end up making it worse.

[noppa]

I'm going to close this as wontfix, as there doesn't seem to be a practical way of getting screen readers to treat text fields like they treat password fields. Bending over backwards to make this work would likely be out of the scope of this font. I've added a small note about the accessibility and security issues of this approach to readme.