[docs][TextField][a11y] Dynamically modify the value of the aria-label on the eye button (password field)
mnajdova opened this issue · 10 comments
Steps to reproduce
Link to live example: (required)
Steps:
- Go to https://v5.mui.com/material-ui/react-text-field/#input-adornments
- Click on the eye button
- The
aria-labelhas the same value, although the icon changes (gives indication of sighted users about the two different states)
Current behavior
The same aria-label value is the same.
Expected behavior
In the eye password button, modify dynamically the value of the aria-label on click: aria-label=”display the password” / ”hide the password” instead of using "toggle password visibility" as it does not give indication of the current state.
Context
No response
Your environment
npx @mui/envinfo
Don't forget to mention which browser you used.
Output from `npx @mui/envinfo` goes here.
Search keywords: textfield, demo
Hi, I'd like to work on this! Just to clarify, the value of the aria-label will be dynamically set depending on the value of the showPassword state here?
Yes exactly. Please open a PR and tag me for review :)
Could fixing this be a step backward? The rationale goes like this: If I'm blind, this action is irrelevant to me, I can't use the feature. If I'm not blind, then I can see the difference, I don't need specific labels. So it's best to not fix this, to keep the translation work of a i18n team simpler?
I agree but I imagine a situation where the feature is used by mistake...maybe the user navigates to the button accidentally. It would be helpful for the label to indicate what state the password field is in since you wouldn't want a situation where the password is visible unknown to the user.
aria-label are only read by screenreaders. Why would someone who use a screen reader ever need this feature?
How would a blind user then ever be able to read the password (or have it be read by the screen reader?). If I am a sighted user this input allows me to get the password (by reading it), why would a non-sighted user not have that option?
The rationale goes like this: If I'm blind, this action is irrelevant to me, I can't use the feature.
This is bad UX, the feature should be available to everyone. When we say "show" the password, is not just about seeing it, is about reading it, copying etc.
How would a blind user then ever be able to read the password (or have it be read by the screen reader?)
@mnajdova If screen reader can't read <input type="password" but can read <input type="text" field, then 👍, it makes sense (I thought it wasn't the case).
Yep, it's not the case, e.g. focusing on a password text field, Voice over reads the following:
while if it is type="text" it reads the text itself:
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@mnajdova Alright, this change makes a lot of sense then, thanks for the screenshot with VoiceOver 👍.