Text Entry: Read-only

[JordanWSmith15]

Name of the component that the contributor wants to change
Text Entry

Explanation of why the contributor wants the change and thinks it's necessary
This request is to handle a text entry component that is filled, but is no longer editable.

My product has a very common use case for text that has been entered by one user and is important data for consumption, but can no longer be edited for a variety of reasons. The “Disabled” option is not viable, as the label and entered data is not accessible. Proposal is to simply remove the line at the base of the "Filled" version of the component, so that it closely matches with the Disabled component, but passes accessibility.

Box folder:
https://ibm.box.com/s/m2hv0o3plpadsttr5ss6rze7ids34co1

Contact:
Jordan Smith
jordanwsmith15
[email protected]

[JordanWSmith15]

@joshblack @shixiedesign

[shixiedesign]

@JordanWSmith15 This makes sense to me! Thanks for the contribution. We are currently in V10's last push so we might not get to new features this week. I will also take this back to other designers for consensus in case I missed something.

[shixiedesign]

@JordanWSmith15 On second thought, loosing the underline makes the field technically a button styling, so it still looks very interact-able. We can consider loosing the background and re-align text...

[JordanWSmith15]

@shixiedesign That also works. That way, it becomes more of a label with data under it. We would need to consider what text overflow looks like. Would it be cut off by an ellipsis or something?

[JordanWSmith15]

Two views to consider:

[JordanWSmith15]

@shixiedesign Any update on this? Are we leaning towards option 1 (keeping the line and removing the box)?

[werdnanoslen]

I've done the same thing @JordanWSmith15. I made a symbol based on the text input component with the text top-aligned to where the top of the input field used to be:

[shixiedesign]

Update! @JordanWSmith15 @werdnanoslen

Spec summary:

• Read-only variant will be keeping underline and dropping the background of the field. We need the underline for low-vision users to recognize this as a text field. Also loosing the underline makes the element a button-style, which would be confusing.
• Not moving the text position after all. Keeping text 16px away from left of border helps with preserving the form structure.
• Cursor hover should be not-allowed cursor
• Overflow text in the field will show in tooltip on hover

Below are some in context explorations from @laurenmrice

[shixiedesign]

Closing this issue and tracking development of component here:
carbon-design-system/carbon#2177
Feel free to re-open if you'd like to discuss the design.

[dianasanborn]

Hey @shixiedesign !
Just wanted to revisit this quickly — I was curious as to why some of the options explored above were not considered? Specifically the example @werdnanoslen had. I see the value of having a read only option that stays in the same placement as other text inputs when it's in a form with a mix of both read only and editable, but there are also some scenarios where the entire page is read only, and we need a label/value variant that doesn't take up too much space between fields.

See example below:

We also have this showing up in smaller panels, and would love to consider an alternative read only option as well.

[JordanWSmith15]

@dianatran18 I think for labels with data that are always read-only, a different component is needed, rather than an extension on the inputs. My team created this to handle your usecase: https://pages.github.ibm.com/maximo-app-framework/graphite/react/storybook/?path=/story/components-%E2%9C%93-field--field-label-placement-on-top