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

Add radio/checkbox group accessibility #2739

Merged
merged 10 commits into from
Jan 8, 2020
Merged

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Jan 7, 2020

Allow passing legend prop to wrap these groups in EuiFormFieldset

To properly label groups of radio buttons, there needs to be a fieldset and legend (even if that legend is visually hidden). This PR adds a legend prop that accepts the same object as EuiFormFieldset.legend and if provided will wrap the radios in this component otherwise it just returns a div as before.

Screen Shot 2020-01-07 at 10 54 33 AM

I added this as an option for checkboxes as well since checkbox groups could have an over-arching label but by a11y rules an input cannot have 2 <label> elements attached to it. Therefore it needs to be a legend.

Screen Shot 2020-01-07 at 10 55 07 AM

Which will also help with #2493


Incidentals

During this addition, there were a couple fixes/enhancements made to these components.

1. Radio and checkbox labels are now inline-block. Before, the label was block display meaning even the white space on the right was clickable. This could have caused unintentional clicks by the user.

Screen Shot 2020-01-07 at 10 50 03 AM

2. Extended the EuiCheckboxGroup.options type to extend EuiCheckbox. Before, the options would only accept id, label, disabled. Now consumers can pass anything accepted by EuiCheckbox (including data-test-subj).


Checklist

  • Check against all themes for compatibility in both light and dark modes
  • Checked in mobile
  • Checked in IE11 and Firefox
  • Props have proper autodocs
  • Added documentation examples
  • Added or updated jest tests
  • [ ] Checked for breaking changes and labeled appropriately
  • Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@cchaos cchaos requested review from myasonik and elizabetdev January 7, 2020 16:02
@snide snide mentioned this pull request Jan 7, 2020
19 tasks
Copy link
Contributor

@myasonik myasonik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

* Wraps the group in a `EuiFormFieldset` which adds an `EuiLegend` for titling the whole group.
* Accepts an `EuiFormLegendProps` shape.
*/
legend?: EuiFormLegendProps;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should legends be required for radio groups?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary to break current implementations for an additive property. It's possible consumers could have already fixed this with their own implementation of fieldset and legend.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they've already fixed it for their own solutions, then it's likely it'd be an easy migration to this new form. If you're worried about it not being, we could allow legend={{}} as a valid option that effectively does nothing other than prove you (an implementing developer) thought about the legend.

I just worry about us adding these capabilities in building accessible pages but people not taking advantage of them because they don't see the benefit themselves without a forcing mechanism.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our strategy is to be as out-of-the-way as possible with updates and be pro-engineer rather than pro-feature with updates (regardless of what that feature or bug fix is). It's easy when you think about ONLY fixing Kibana. It's not so simple when we talk about ANY site using EUI. We can target a deprecation if we want and change it at a later time, but we always give six months for that kind of thing.

This is a very broad team strategy we've used to remove friction and keep people happy and using EUI in general.

Copy link
Contributor

@elizabetdev elizabetdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally and everything looks good to me! 🎉

@cchaos cchaos merged commit accdb66 into elastic:master Jan 8, 2020
@cchaos cchaos deleted the radio-group-a11y branch January 8, 2020 18:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants