-
Notifications
You must be signed in to change notification settings - Fork 0
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
DROPDOWN: Common keyboard accessibility pattern on all dropdown like components #31
DROPDOWN: Common keyboard accessibility pattern on all dropdown like components #31
Comments
Adding to this, we should have an example of a dropdown with a menu to really exercise these options. Questions come up about using the |
Tagging as a spike for further investigation. |
Questions to answer: |
Part of this problem can be solved using svw/h values. https://caniuse.com/?search=svh This will handle for the address bar. Essentially the browser is aware of the visibility of the address bar and svw/h adjusts for the that. However, the browser doesn't know about the state of the operating systems virtual keyboard so there is no browser pseudo selector to key off off for that. Looks like we may not be able to adjust correctly or consistently for keyboard. https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md |
moving to blocked while we await design feedback on the PoC |
Reminder for when we pick this back up: Check the status of native Popover support in Firefox; has it been released yet? |
Moving this to blocked for now in anticipation of the work to explore native popover support. |
We are exploring AlaskaAirlines/auro-dropdown#239 to see if using native html popover will allow the keyboard a11y experience to be consistent across the board. |
Native popover (which we aren't using) and Floating UI (which we are using) have no impact on keyboard accessibility patterns. We are unburdened and can implement any pattern we would like. |
Putting to Ready to work for investigation and decision making for the pattern(s) we want to use. |
Is your feature request related to a problem? Please describe.
auro-dropdown
,auro-combobox
,auro-select
andauro-datepicker
should all have consistent behavior around when to open the dropdown bib, close the bib, focus trapping, and basic keyboard accessibility.These things are currently all coded slightly different as we learned more while developing each component.
We should identify the common experience they all should share and then look at a way to not duplicate that code across components. That may be a matter of putting more of the code into dropdown. It may be a matter of putting some code into a shared utility that each can import.
Common functionality to consider:
closeBib
on any content in the dropdown will dynamically add the right event listener to close the bib on click) so that custom JS doesn't have to be written to closedropdown.hide()
. Optionally, this could be an attribute at the root of dropdown that you can pass in an array of selectors.The text was updated successfully, but these errors were encountered: