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

DROPDOWN: Common keyboard accessibility pattern on all dropdown like components #31

Open
jason-capsule42 opened this issue Jul 26, 2022 · 10 comments · May be fixed by AlaskaAirlines/auro-dropdown#209
Assignees

Comments

@jason-capsule42
Copy link
Member

Is your feature request related to a problem? Please describe.

auro-dropdown, auro-combobox, auro-select and auro-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:

  • Enter key to open/close/toggle
  • Space key to open/close/toggle
  • Esc key to close
  • Focus trapping?
  • dynamic element closers (e.g. adding an attribute called 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 close dropdown.hide(). Optionally, this could be an attribute at the root of dropdown that you can pass in an array of selectors.
@jason-capsule42 jason-capsule42 added the Type: Feature New Feature label Jul 26, 2022
@blackfalcon blackfalcon added the not-reviewed Issue has not been reviewed by Auro team members label Sep 2, 2022
@blackfalcon blackfalcon transferred this issue from AlaskaAirlines/auro Mar 22, 2023
@blackfalcon
Copy link
Member

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 tab to get into a menu when this is not correct and we use the arrow keys to move up/down a menu within the bib.

@Patrick-Daly-AA
Copy link

Tagging as a spike for further investigation.

@Patrick-Daly-AA Patrick-Daly-AA removed the not-reviewed Issue has not been reviewed by Auro team members label Oct 18, 2023
@Patrick-Daly-AA
Copy link

Questions to answer:
Is it possible to change the dropdown bib into a modal dialog below a certain breakpoint?
Can we adjust/configure this breakpoint based on component and/or screen size?
Address Bar explorations (Apple and Android): Does the address bar hiding and showing impact the user having a good experience? And can we configure different behavior to accommodate this?
Keyboard Explorations (Apple and Android) Does the keyboard hiding and showing impact the user having a good experience? And can we configure different behavior to accommodate this?

@Patrick-Daly-AA Patrick-Daly-AA changed the title Common keyboard accessibility pattern on all dropdown like components SPIKE: Common keyboard accessibility pattern on all dropdown like components Oct 18, 2023
@jason-capsule42 jason-capsule42 self-assigned this Oct 20, 2023
@jason-capsule42 jason-capsule42 linked a pull request Oct 20, 2023 that will close this issue
6 tasks
@jason-capsule42 jason-capsule42 linked a pull request Oct 20, 2023 that will close this issue
6 tasks
@jason-capsule42
Copy link
Member Author

jason-capsule42 commented Oct 30, 2023

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
https://developer.chrome.com/blog/viewport-resize-behavior/

@Patrick-Daly-AA
Copy link

moving to blocked while we await design feedback on the PoC

@Patrick-Daly-AA Patrick-Daly-AA changed the title SPIKE: Common keyboard accessibility pattern on all dropdown like components Common keyboard accessibility pattern on all dropdown like components Jan 17, 2024
@Patrick-Daly-AA
Copy link

Reminder for when we pick this back up: Check the status of native Popover support in Firefox; has it been released yet?

@jason-capsule42
Copy link
Member Author

Moving this to blocked for now in anticipation of the work to explore native popover support.

@braven112
Copy link
Member

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.

@Patrick-Daly-AA
Copy link

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.

@jason-capsule42 jason-capsule42 removed the Type: Feature New Feature label Oct 3, 2024
@Patrick-Daly-AA
Copy link

Putting to Ready to work for investigation and decision making for the pattern(s) we want to use.

@Patrick-Daly-AA Patrick-Daly-AA transferred this issue from AlaskaAirlines/auro-dropdown Nov 6, 2024
@jason-capsule42 jason-capsule42 changed the title Common keyboard accessibility pattern on all dropdown like components DROPDOWN: Common keyboard accessibility pattern on all dropdown like components Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants