Read-only Field component

[rolfsmeds]

A component for non-editable key-value pairs consisting of a label and a value, for use e.g. in read-only forms.

• Labels above and aside variants
• Databindable (like input fields)
• Nice-to-have: built-in formatting support for numbers, datetime...)

Labels above: (This should work nicely out of the box in FormLayout, and align appropriately with input fields)

Labels aside: (note: labels-aside mode should be considered together with labels-aside support in input fields)

Semantics

Could be as simple as

• ReadonlyField root (generic)
  • label
  • span (value), with aria-labelledby reference to label

Or we could consider using <data> element for the value, and have the possibility to provide a machine-readable value in addition to the rendered value, possibly also switching that to a <time> element for datetime values.

Open questions

Is ReadOnlyField / vaadin-read-only-field a good name?

Could consider having a secondary text / slot, somewhat similar to the helper-text below input fields, e.g. for use cases such as this

[DiegoCardoso]

I was playing around with this proposal to see if I understood how the component should behave in terms of accessibility. So, I came up with this prototype (https://codepen.io/diegocardoso/pen/BaXpyWZ). What I could see is that if aria-labelledby would probably need to reference both the <label> and the <span> elements, otherwise it will be skipped in the announcement. Here's a recording of the different approaches in the test using VO+Safari:

https://github.com/user-attachments/assets/17ba3629-d1cb-4cec-8ffe-7f3162921f36

I used role=group in some cases to see if it would make any difference, but nothing could be noted for VoiceOver. Not sure if there's a better role to be used instead (or none).

[rolfsmeds]

Ah, indeed, I added that "with aria-labelledby reference to label" to the wrong "node" in the DOM proposal, it should be on the span.

[DiegoCardoso]

Even in that case, if the <span> has an aria-labelledby attribute, its content ends up ignored in favor of the element it references. So it would need to reference to itself.

[rolfsmeds]

Ah, I hadn't expected that. I would have expected the label and the span to be "concatenated" in the announcement. Good catch!

Then our options are probably

• No semantics, just two generic text elements (or a <label> and <data> or something, if we find that there's any benefit to that) after each other (which is probably fine)
• DefinitionList semantics, which is a bit weird since there would be only one item in that list.

[rolfsmeds]

I also just now realized that using a non-input element as a "permanently read-only" field in a form (amongst normal editable fields) might not work well with NVDA and JAWS, since those usually switch to "forms mode" when they encounter an input, and in that mode they generally skip any non-field content until the user either reaches the end of the form or exits forms mode manually, which means that these "permanently readonly fields" would be skipped.

If that is the case, these would not be a viable solution for use in forms where some fields are editable.

That does still leave at least two other use cases:

• Entirely read-only forms
• Standalone label+value pairs

For standalone label+value pairs, a dedicated component might be overkill, so we could look into extending the use cases for https://github.com/vaadin/web-components/issues/7958 to cover that as well.

Entirely read-only forms would probably make the most sense as DefinitionLists, so that could push us towards something like a ReadOnlyFormLayout, or a mode in FormLayout for rendering it as such (although that would also require a new type of API for defining the contents of the form that goes beyond adding specific field components to it).

The value in having a dedicated non-input-based read-only rendering for read-only values is twofold:

• It's a lot more lightweight than rendering a bunch of different input field components
• Long values can wrap to multiple lines (which is impossible to achieve with <input>)

Another possible solution, that would serve that last point, could be a feature in the input field components to render their visible value as a wrapping text element (hidden from screen readers), while keeping the (visually hidden) available for screen readers.