carbon
carbon copied to clipboard
Field validation errors for Radio Group and Checkbox Group
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:
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.
Spec:
border: $support-01 icon: $support-01 text: $label-01, $text-error
@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
Yup the border would grow to accomidate the wrapping text.
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.
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.
I think we need an "i" icon next to the label for users to get the reason why they are getting the error.
@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.)
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?
Hello! I wanted to check the status of this issue as well. Can we expect the implementation anytime soon?
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. 🙂
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 🙂
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
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 https://github.com/carbon-design-system/carbon/issues/12638
I'm going to close this for now - it will be used as reference material for the effort to bring this to life.