Improve back-office custom field inputs accessibility and ergonomy

[charleshopfner]

Is your feature request related to a problem? Please describe. The inputs in the Vendure Back-office lack certain accessibility features and could be improved in terms of behavior and usability.

Describe the solution you'd like I would like to enhance the custom fields inputs in the Vendure Back-office to improve accessibility, behavior, and usability. This would involve adding features such as the ability to include captions and labels for the fields, add visual distinction for the differents input states (readonly, ...) , and enhancing overall user experience.

Describe alternatives you've considered One alternative solution could be to rely on third-party libraries to achieve similar functionality. However, integrating these may introduce dependencies and increase maintenance overhead.

Additional context Depending on the ids of the custom fields, the displayed name isn't always easily understandable for all the back-office users. Also, there is no visual disctinction made between readonly fields and editable fields. As example, the "is" field below is readonly, and the "asics" field is editable :

[michaelbromley]

Hi!

Let's split this into the concrete changes:

1. (fix) Make readonly state easily visually discernable
2. (feat) Ability to add caption to a custom field. Can you give an example use-case for this?
3. (feat) Ability to add a label to a custom field. Is this different from what already exists with the label property?

One alternative solution could be to rely on third-party libraries to achieve similar functionality. However, integrating these may introduce dependencies and increase maintenance overhead.

100% agree on this.

Here is where you will find all the built-in form components used by custom fields: https://github.com/vendure-ecommerce/vendure/tree/9eb9d9d53d79838b487480089166906c7c3ef902/packages/admin-ui/src/lib/core/src/shared/dynamic-form-inputs

[charleshopfner]

Hi, Thanks for your answer. For the 2) : as example, we encountered a custom field for the current electricity price and we used a text input for this. It would have been interesting to add a helper below the field to indicate what price format is needed. More generally, it is also important for accessibility to help the user to fill the forms.

For the 3): My bad, i forgot this property, and yeah this is what I was talking about... We didn't use it because we couldn't manage the translation in a .json file and opened this issue at the time.

Another thing is coming to my mind : Adding a symbol at the end of the label for the required fields. At the moment, there is no distinction between required and non-required fields.

Thanks for the infos ! If it is ok for you, i'll start working on this

[michaelbromley]

For 2, we have the existing description property which I think serves the same purpose? If defined, it will get displayed as a popup tooltip. I'm not sure about the accessibility implications of the current design for screen readers.

Adding a symbol at the end of the label for the required fields.

Yes, this is a good idea.

If it is ok for you, i'll start working on this

Yes, go ahead! 🚀