Replies: 1 comment 2 replies
-
|
We are starting to have accessibility problems with this. You can take a look at a use case. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JoseTelefonica, Regarding a11y
I have questions regarding the current solution. If the user can change the phone number prefix, using the field prefix is not a solution, since is not an interactive area for the user to click and type. This problem is beyond accessibility. If the phone prefix is a fixed value that cannot be modified. We should review in all cases the prefix is defined, the input field should be displayed as "open" (meaning that is showing only the prefix without showing any value) since currently the input even if the prefix is defined, if it has no value, is not open.
What I reproduced is the prefix is the first element read aloud, when should the input itself with its associated label. This is something we definitively should review, prefixes should be hidden to screen readers. The current implementation is failing to link the phone prefix with the label of the input, so there's no context about this number when read. This is a failure of info and relationships. If they should be hidden, and the phone prefix is fixed and cannot be changed...how this can be solved? One solution here is to have a readonly input with the phone prefix, that provides the information to the user with a label that explains what the value of the input is: "Phone number prefix" and another input to introduce their phone number. If everything needs to be solved in one input field, the information of the phone prefix should be included in the label or helper text of the input, so the user has this context when interacting with it. Here govuk design system explains it well. If the phone prefix can be modified...well, then just provide an input for the prefix, and another for the phone number as your proposal suggests. Another options is to expect the number with prefix in one input. Regarding the proposalIt is already possible to make a custom layout changing the width of the fields in order to give them a custom width. The problem you will face is that the min-width defined for inputs is 96px and in a 360px width screen the space designed for a 20% input is smaller than that. Here an example: Have you considered stacking the inputs vertically? This would solve the problem without any change in the double field or the min-width definition of the input fields. We have added some explorations in the Figma you provided with other options. |
Beta Was this translation helpful? Give feedback.
-
We have identified this behaviour as a potential a11y problem and included it in our backlog: #2082 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Goal
The need is to pass a custom percentage to the double field instead of using the predefined value.
Context
The current component only allows a set of pre-defined values in order to organize the lenght of the fields.
Impact
A issue proposing an atomic alternative is the space for error fields when using this component.
Discussion Questions
What are the advantages of using this component vs using a custom solution to put the size of any input custom?
I see as an advantage to control the display of the errors, making a stack of them under the double field so the constraints of the field size are not translated to the error texts.
Additional considerations
No response
Do you have a visual proposal?
No response
Beta Was this translation helpful? Give feedback.
All reactions