-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update ADR file with notes about our combo-box choices from issue #484.
- Loading branch information
Chach Sikes
authored and
Chach Sikes
committed
May 24, 2022
1 parent
1055a7e
commit c4b1410
Showing
1 changed file
with
7 additions
and
3 deletions.
There are no files selected for viewing
10 changes: 7 additions & 3 deletions
10
src/js/charts/cannabis-local-ordinances/adr/03-autocomplete.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,17 +1,21 @@ | ||
# 3. Autocomplete/combobox | ||
|
||
Date: 5/16/2022 | ||
Date: 5/23/2022 | ||
|
||
## Status | ||
|
||
Starting | ||
Introducing first prototype of an accessible, performant, adaptation of the W3 combo-box, with a couple of alterations to help it work for an interactive data viz web component. | ||
|
||
## Context | ||
For the Cannabis Local Ordinances data visualization, we needed a reliable, fully and definitively accessible combo-box/autocomplete solution for one of the map filters. This did not exist in the CA Design System. @chachasikes tried the USWDS combo-box. Ran into some issues with its highly integrated & abstracted event system, though the pure components code seemed promising. The covid19 site had included an autocomplete feature on the What's Open search, but in our deep stress-testing of this components, we noticed some accessibility issues that Chach could not fully replicate and debug with the accessibility debugging tools with enough rapid confidence to alter or switch out that component in mid-flight during the peak of the pandemic. | ||
|
||
Adding | ||
Since this would be a really helpful project for the Design System to include, and because the default HTML select option worked great, but caused a managable and not-entirely horrible (though very long!) UX issue that we could take the time to resolve completely, correctly, sensibly, and with our best approaches at documenting this contribution for future Design System component proposals. Zakiya shared in the Office of Digital Innovation's Engineering team's weekly Codeshare how she reviewed a variety of components, and introduced this to this repo in the prior pull request. Hopefully she will write a blog post about her alterations to the W3C component, but our process includes stress-testing component code on production sites, so we will be QA testing this component this week to try to include it in an update. It looks good already and has passed our teams initial code reviews and checks (especially accessibilty, translatability, performance.) | ||
|
||
See issue #484 for more details. | ||
|
||
## Decision | ||
|
||
Using [W3.org Combobox With Both List and Inline Autocomplete Example](https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.0pattern/combobox-autocomplete-both.html) as a basis for the places select. | ||
|
||
## Consequences | ||
Process note: On launch, will set calendar reminders for the team to review this component quarterly or every six months for an update on what the consequences have been. Eventually someone will write a consequences file about what happened to this component. Hello future person. Please find @chachasikes, @zakiya, @aaronhans and let us know what happened!👋 |