Open jeryj opened 2 months ago
@jeryj I edited the testing instructions to include a note about aria-expanded
on the toggles. Failing to communicate this would confuse users into thinking nothing happened.
I think this is overall a very big lift and not one we should rush into. As imperfect as it is now, I feel like having skip links everywhere is going to make the UI that much harder to use however I do believe it is necessary to have triggering elements controlling the panels.
Thanks.
Re: The close button ordering issue, I think https://github.com/WordPress/gutenberg/pull/61553 would be a more appropriate solution. I would kindly ask designers to not think visually first. Functionality, semantics, and accessibility should always come before any visual consideration. Thanks.
@joedolson mentioned having the https://github.com/WordPress/gutenberg/issues/59013#issuecomment-2103033778:
Totally agree, that is a general principle that applies not only to 'panels'. It applies to any UI section that is initially hidden and expands when activating a trigger. Popovers, for example, have the same problem. Dropdown menus as well. Basically, any expandable section of content that resembles a 'disclosure pattern' should follow the principle of making the trigger and panel adjacent in the DOM.
I'm pretty sure this point was reported several times in the history of this project but, alas, often dismissed for other reasons I'm not sure I can support. Developing an user interface should be based on user needs first. Other arguments should come after.
That said, we have another problem to consider.
The editor UI is split into some ARIA landmarks. It is worth reminding ARIA landmarks provide an important mechanism for assistive technology users to get a sense of the main sections of a page and more importantly provide a way to jump from section to section. For example, screen readers provide dedicated shortcuts to jump through landmarks and tools to list all the landmarks in a page. In Gutenberg, we mapped ARIA landmarks to the 'navigable regions' to provide a similar navigational tool to keyboard users who don't use screen readers.
Screenshot to roughly illustrate some of the editor ARIA landmarks:
Moving the panels close to their triggers in the DOM would make this landmark structure almost useless, if not confusing. Some of these landmarks would be basically empty and unused. This is not to say I'm opposed to this proposal but we should definitely take into consideration what to do with the landmarks.
I edited the testing instructions to include a note about aria-expanded on the toggles. Failing to communicate this would confuse users into thinking nothing happened.
@alexstine Thank you for catching that! Sorry I accidentally omitted it.
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