-
Notifications
You must be signed in to change notification settings - Fork 15
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
feat(select accessibility): add <SingleSelectA11y/> component #1620
base: master
Are you sure you want to change the base?
Conversation
🚀 Deployed on https://pr-1620--dhis2-ui.netlify.app |
What exactly are the breaking changes compared to the previous input besides new props and features? Are certain functionalities no longer working? I would say a breaking change release would be better than introducing a new component, and if both components should be kept in the package maybe the old one should be renamed so people have the option to upgrade with just a name change? I am also missing some documentation about this in the |
The existing component accepts children, which means you can pass anything to the component and it will be rendered in the menu, which you can see here. Other potential breaking changes relate to custom options: The options in the new component uses a
I can elaborate my reasoning for introducing an additional component with a new name: I'm mostly worried about the impact on devs when they want to upgrade UI for other reasons. Say we introduce a breaking change but the teams don't have time at that moment to transition, then release another feature that is unrelated to the select component and one of the apps needs that change. If the app has many selects, it'd be a lot of work. Releasing two components, deprecating the old one and keeping its name for the time-being would allow devs a transition time. Of course we could force apps to use the new component and be more accessible asap. This mostly depends on how we want to move forward organization-wide. My stance is to be careful which breaking changes in essential components and give developers enough time to transition from one component to another without stopping them from upgrading the library when they need other changes.
Yes, this is still draft and the docs checkbox isn't checked. The goal is to discuss the general direction now that I have something I can show. |
Alright I get the reasoning! I'm not the one to decide that but that would be my recommendation. Releasing a new major version also allows for breaking changes and I think that is the best way forward as it would be a new best practice. It also allows people to stay on an older version if they don't have time to upgrade. We'll just have to document the breaking change properly, not only in the releasenotes but also in the Perhaps @amcgee can share his opinion on the matter. |
1e0a40e
to
25b4a65
Compare
25b4a65
to
03e556c
Compare
de15432
to
d8efd07
Compare
81185f8
to
7619446
Compare
7619446
to
0dc3760
Compare
0dc3760
to
356bd4f
Compare
Quality Gate failedFailed conditions See analysis details on SonarQube Cloud Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE |
Implements LIBS-559
Storybook demos here.
Description
Adds an accessible version of the single select component.
This component is significantly different from the existing single select component in some aspects,
so I decided to create a new component rather than modifying the old one.
In order to make this component accessible:
[role="combobox"]
aria-placeholder
,aria-labelledby
&aria-expanded
combobox
points to thelistbox
viaaria-controls={listBoxId}
andaria-haspopup="listbox"
[role="listbox"]
aria-live
andaria-busy
button
elements with[role="option"]
aria-selected
,aria-disabled
&aria-label
aria-label
when afilterLabel
has been providedStyle-wise there should be no difference between the existing component and the new one.
There are some differences in which props exist and which props are expected:
The new component
name
prop.The HTML element that displays the selected value (combobox) needs to point to the element that has the options (listbox), which is done by using id attributes. Instead of creating one randomly, I decided to make this prop requried.
This makes it easier to access the options without having to go through children. In order to support custom options, the options can have a
component
prop, which will override the default option style while the accessible option wrapper will stay intactselected
prop which is an option ({ value: string, label: string }
).This should help providing the selected value and its label while still loading the options. This eliminates an issue we've had in the past with other components where the selected option would have to be added to the options array, regardless of whether it should be displayed or not
clearText
prop to be present when the select isclearable
.This way we can have an
aria-label
on the clear button.filterValue
&onFilterChange
).Consumers can now use the filter to load more options or control the options list in any other way
data-test
propertiesBreaking changes (disregarding prop changes) if we'd replace the existing component
Thinks I want to discuss
A11y
in its name. I don't think we should replace the old component but deprecate it to give developers time to transition to the accessible variants. But how should we call the new one?autoFocus
prop, which was calledinitialFocus
before. I didn't really think about the name until I realized it deviates. I suppose I should just use the old name?autofocus
is the name of the actual HTML attributecomponent
property. Would it make sense to introduce aoptionComponent
prop on the select which would apply to all options unless an individual option has acomponent
property?aria-live
andaria-busy
to update the user about changes. Thearia-live
attribute can have different values:off
,polite
&assertive
. I thinkassertive
could be better, but depends on the use-case I suppose. Do we want the consumer to be able to control this value? And if yes, what should the default value be?I think it could be useful for the transfer to do the same (above and below the options (and the listbox HTML element) in the menu). We could even get rid of the search functionality here and let apps handle that, making the component leaner and reducing the maintenance burden in the app.
Open TODOs
disabled
states when handling keyboard inputsChecklist
Code explanations
Component implementation:
SingleSelectA11y.-.Function.code.mp4
Test implementation:
SingleSelectA11y.-.Testing.mp4
Documentation:
SingleSelectA11y.-.Documentation.mp4