fix(FluidTextInput): label overflow scroll #12261
Conversation
✅ Deploy Preview for carbon-components-react ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for carbon-elements ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
The scroll bar covers up the label some times and it does fade away eventually. I guess there's probably nothing we can do about that though.
|
|
Actually, the field text doesn't have the scroll bar either. Is there a way to fix this in the label then?
|
|
@aagonzales Sometimes the scroll bar doesn't fade away depending on the user settings
I suspect we might see similar problems with the scroll bars in windows. The textbox scrolling is something the browser does by default. It's possible to hide the scroll bar on the label, but WCAG recommends against it citing usability and accessibility concerns. It looks like there's a new draft spec for All said, I think hiding the scrollbar in this case could be the most beneficial option. |
|
The good thing is, either way, I think label scrolling is a very side edge-case. If we can remove it without causing violations, then lets do it but if we have to keep it then its fine. @jnm2377 @tay1orjones |
|
@mbgower do you think in this instance it's acceptable to remove the scrollbar? |
|
The primary requirement for WCAG is covered under Reflow. So it really depends on how you're handling breakpoints and text resizing. IMO, a text input area is likely an acceptable place to use horizontal scrolling without violating this because the input width is constrained by design -- although I assume Carbon has some guidance saying that where the character count allows more characters than can be displayed, use a text area! I know Carbon does have guidance saying input labels should be short, so I think your design guidance is making this outcome very unlikely. But you're asking about the opposite of this. 'Can I remove scrolling?' There are a couple of things to note... The place where you create a potential issue if you don't offer scrolling is actually the mouse user. But I believe the interaction workaround would be that they too would click in the input and use arrow keys, or the OS affordance for panning within text, to read the information. If that's acceptable to you folks, I don't think it violates accessibility (which tends to be worried about keyboard more than mouse). So that only leaves the label as a potential problem. I think I was reading above that the label will line break, rather than scroll? So I'm not sure I understand a scenario where you'd need scrollbars. |
|
I thought up an example... Use of read-only inputs. In such a situation, if you are constraining the horizontal width, you could potentially be in a situation where the user would be unable to see either a very long label or any input text that exceeds the horizontal spacing of the input. @quarryboy, do you have any thoughts on this? |
|
@mbgower would the label not be seen in that instance? i thought it was the opposite of disabled and would be seen/processed for read-only. i think it's a bit concerning that the label would be more than a few words long. what's the actual use case? it seems like the emphasis should be on putting all that text into a tooltip instead. @aagonzales out of curiosity, how does this test with browsers that use a two-finger horizontal scroll in conjunction with it's history? e.g.—two-fingers to the left causes you to go "back". seems like it would be very frustrating to accidentally go back in history and have to start the entire form process over again. i saw somethign about violations above? how do violations fit in with this particular use case? |
@mbgower Yes, this is a very rare edge case. I don't expect it to happen often, if at all since labels are pre-defined. I think the most likely instance will be in translation which could trigger a label to scroll (especially with a short input). We do not want the labels to wrap in the Fluid style because it will effect the container size.
@quarryboy We have not tested it and it hasn't been brought up before. Horizontal scrolls already exist in the default text input along with several other components like data table and code snippets. If horizontal scrolls are triggering violations then that will have consequences across components and we will need to spin up a workstream to address that system wide. |
|
@mbgower What we're really asking is can we hide the scroll bar because the scrollbar when active is covering up the label content. See #12261 (comment) |
|
@aagonzales it's a question of balancing considerations in the edge case where the label is long. On the one hand, the scrollbar somewhat obscures the label. But in the example you show, it is only obscuring while the user is actively employing it. You can reposition with the scrollbar and then move your mouse away and see the adjusted text position. So, there is a way to see the text. Whereas, if you remove the scrollbars entirely, you seem to be removing a users ability to reposition the label to even see one that is truncated? |
Yes, we'll only be hiding the visual scrollbar. The ability to scroll will be retained. |
Closes #12082
Changelog
Testing / Reviewing