Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working as expected with screen readers. #11

Closed
HimanshuGoel opened this issue Jun 16, 2020 · 7 comments
Closed

Not working as expected with screen readers. #11

HimanshuGoel opened this issue Jun 16, 2020 · 7 comments
Labels

Comments

@HimanshuGoel
Copy link

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
Copy link
Owner

noppa commented Jun 16, 2020

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
Copy link
Author

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
Copy link
Owner

noppa commented Jun 19, 2020

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
Copy link
Author

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
Copy link
Owner

noppa commented Jun 26, 2020

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
Copy link

varenc commented Jul 24, 2020

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 noppa added the wontfix label Mar 19, 2021
@noppa
Copy link
Owner

noppa commented Mar 19, 2021

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.

@noppa noppa closed this as completed Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants