Consistent Sidebar DOM and Open/Closing Interactions #61837
Labels
[Focus] Accessibility (a11y)
Changes that impact accessibility and need corresponding review (e.g. markup changes).
Needs Accessibility Feedback
Need input from accessibility
Needs Design Feedback
Needs general design feedback.
[Type] Bug
An existing feature does not function as intended
Description
This has been discussed in various places, but I couldn't find a central area to discuss how the various Panels that are open/closeable from the header should be be implemented in a consistent way. Fixing this would fix deeper issues that are workarounds such as the panel close button between the tabs and tab content, and simplify the codebase by removing a lot of workarounds/hacks that auto-focus panels when they open.
@joedolson mentioned having the Panel DOM be adjacent to the button that activates it:
If we do this, we could remove the close button, as suggested by @afercia:
We shouldn't remove the close buttons unless the panel is next in the DOM to the button that triggers it opens/closes though.
Moving the panels in the DOM to be adjacent to the button that triggers them could introduce some other undesirable interactions though. For example, right now the panels are close in the DOM to the editor canvas. Being able to tab between the editor canvas and the inserter and settings panels is quite nice. If we move these panels to be close to the button that triggers them, should we also add some hidden skip links to allow moving easily between the panels and the editor canvas?
Proposal
Step-by-step reproduction instructions
What I expect to happen
aria-expanded="true"
to communicate visible state.Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: