Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Field validation errors for Radio Group and Checkbox Group #5390

Closed
JordanWSmith15 opened this issue Feb 18, 2020 · 14 comments
Closed

Field validation errors for Radio Group and Checkbox Group #5390

JordanWSmith15 opened this issue Feb 18, 2020 · 14 comments
Labels
proposal: accepted This request has gone through triaging and we are accepting PR's against it. role: dev 🤖 type: enhancement 💡
Milestone

Comments

@JordanWSmith15
Copy link

JordanWSmith15 commented Feb 18, 2020

Summary

Add field validation errors for Radio Group and Checkbox Group

Design required.

Justification

Maximo EAM has long-standing business logic that allows for errors to be returned from the database against any field type. We use the field validation errors available in Carbon components like Number Input and Text Input, but noticed that Checkbox Group and Radio Group do not have these options. We understand that this is not a great UX, but due to the limits of our ability to change existing business logic (as it is high risk and impacts unpredictable customization done by customers) we require a solution for these controls to display errors at the base level.

Example:
IBM creates a Maximo app with a large form that supports options A, B, C but a customer on the server back end creates a script that says "B can only be selected if field X is set to Z". On saving the form, the user would then receive an error message, but no inline identification of what field caused that error.

Desired UX and success metrics

User can receive a custom error message and identify the selection that caused the error so that they can rectify it
Passes accessibility requirements (I'm not sure if my suggestion even does this)

Available extra resources

What resources do you have to assist this effort?
I have development resources willing to submit code, once they have an approved design to go from.

Quick exploration:
Screen Shot 2020-02-18 at 1 14 16 PM

@aagonzales
Copy link
Member

aagonzales commented Feb 21, 2020

Since the error message and the error-ed item are not directly beside each other, I think the border just on the icon isn't sufficient to met color blind standards. I'd suggest something that highlights the whole row.

image

@aagonzales
Copy link
Member

aagonzales commented Feb 25, 2020

Spec:

image

border: $support-01
icon: $support-01
text: $label-01, $text-error

@JordanWSmith15
Copy link
Author

@aagonzales Cool! What is the behavior when the text for a checkbox item is long, causing the text to wrap? I would assume the box grows and the icon remains top right

@aagonzales
Copy link
Member

Yup the border would grow to accomidate the wrapping text.
image

@andrea-island
Copy link

Hello! Are we aware of any implementation of this that can be shared with other teams? Or do we know the timeline when this will be delivered as part of the carbon components? We are looking into accessibility compliance for CPD Lite 3.5 release, and this is one of the requirements for forms.

@thefirstartist
Copy link

image
For the case like this, users can't do anything unless the 2nd one was checked. This is different from the sole check box that we want user to click on it to indicate their consent. For multiple check boxes, the required one should be checked by default.

@thefirstartist
Copy link

image
I think we need an "i" icon next to the label for users to get the reason why they are getting the error.

@wkeese
Copy link
Contributor

wkeese commented Nov 19, 2020

@aagonzales - Just wanted to confirm that the error text is supposed to be $label-01, i.e. 12px, rather than the checkbox label size, i.e. 14px. In some of these mockups, the error text looks the same size as the labels to me. (But maybe it is actually smaller, it's hard for me to tell.)

@emyarod emyarod self-assigned this Feb 12, 2021
@emyarod emyarod removed their assignment Apr 19, 2021
@code-asylum
Copy link

Hi, I wanted to check what the status on this issue is, since we just ran into the same issue that we need to mark Checkboxes / Radio buttons in a complex form as invalid and there were no other information since November?

@OlgaShishkanova
Copy link

Hello! I wanted to check the status of this issue as well. Can we expect the implementation anytime soon?

@jnm2377 jnm2377 added proposal: accepted This request has gone through triaging and we are accepting PR's against it. proposal: open This request has gone through triaging. We're determining whether we take this on or not. labels Nov 17, 2021
@jnm2377
Copy link
Contributor

jnm2377 commented Nov 17, 2021

Hi, at the moment this is not on our roadmap. I'm not sure when this issue will be prioritized, our hands are quite full right now with other a11y related refactor and v11 changes. We would welcome a PR from anyone who needs this enhancement soon. 🙂

@aledavila aledavila removed the proposal: open This request has gone through triaging. We're determining whether we take this on or not. label Jan 10, 2022
@afkoziol
Copy link

afkoziol commented Aug 16, 2022

Hello, are there any updates on this item? We are approaching a year since the last post. We received a design spec that is requesting an error indicator for a checkbox group.

Thanks 🙂

@kevyyar
Copy link

kevyyar commented Aug 23, 2022

Hello Carbon team any updates on this implementation? It seems that other components have the props of invalid and invalidText where we can specify the errors but not on this component

@tay1orjones tay1orjones added this to the 2023 Q1 milestone Sep 20, 2022
@tay1orjones
Copy link
Member

tay1orjones commented Nov 15, 2022

Hey there! This has been accepted for a while but has now been planned to be tackled by the core team. 🎉

We've refined the steps to take for this out into a new set of issues you can track at #12638

I'm going to close this for now - it will be used as reference material for the effort to bring this to life.

@tay1orjones tay1orjones closed this as not planned Won't fix, can't repro, duplicate, stale Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal: accepted This request has gone through triaging and we are accepting PR's against it. role: dev 🤖 type: enhancement 💡
Projects
Archived in project
Archived in project
Development

No branches or pull requests