Customizer: Improve accessibility of sliding panels

[afercia]

The Customizer has a lot of room for accessibility improvements. It's one of the most visually dynamic user interfaces in the WordPress admin and probably never fully tested for accessibility. High interactivity, sliding/expanding panels, UI dynamic updates, etc. are an accessibility challenge and at the same time an opportunity to use modern techniques and best practices.

This ticket is about improving sliding panels, see comment:3.

[celloexpressions]

We'll plan to tackle this in 4.3 a bit later in the cycle (close to/in early betas) if we're able to get the feedback together by then. If not, we can push to future.

[afercia]

One of the main accessibility issues in the Customizer is about sliding panels. When they're out of view they're just... "out of view" but they're not really hidden to assistive technologies and their content is still readable. It's also possible to tab through the ouf-of-view focusable element and activate them pressing Enter. Please refer to the screenshot below, it's the Menu Customizer, currently under development:

Here you can clearly see that after the "Social Links Menu" control, it's actually possible to keep tabbing and focus all the controls that are inside the following out-of-view panels. This happens also when using arrows to read content, as screen reader users normally do.
In the same way, it's possible to read and focus out-of-view content placed before the currently visible panel.
It's a big issue also for keyboard users, it's easy to understand how easily users may lose context and get lost.

The same issue occurred for Press This during the 4.2 release cycle. The solution was:

• Slide out: detect when the animation completes and then completely hide the out-of-view content with display: none
• Slide in: remove display: none and then start the animation.

If focus is programmatically moved from one panel to another panel, this should happen at the end of the animation.

Worth asking @azaozz and @michaelarestad who brilliantly handled this development. Since this is already done and already in core, maybe the best thing to do would be abstract it a bit and use it as a general utility method available in the admin. Any thoughts more than welcome.
Related: #30599

[afercia]

I'd propose to investigate about the controls descriptions. Currently, they're inside the label element, see screenshot. Related: #31540

[afercia]

About the widgets panel, see #28888 still waiting for a patch.

[afercia]

About the Customizer "collapse sidebar" link, see #31201. Additionally, that link should be a button and its text/title attribute should be updated depending on the collapsed/expanded status. Maybe remove the title attribute.

[ocean90]

Each accessibility related issue should have its own ticket.

If you need something to track all the issues feel free to create a post/page on make/accessibility.

[afercia]

@ocean90 hi, this is a tracking ticket, as noted in the original description we need it to keep track of all the Customizer related things. We'll open separate tickets for specific issues but please keep this open for reference and discussion.

[ocean90]

Why can't this be a post on make/a11y?

[celloexpressions]

The point of this ticket is to track it by the milestone, and generally focus on larger cross-customizer issues that affect multiple features and can be fixed in one place in the API (like descriptions or sliding panels as mentioned above).

[ocean90]

Ticket changed to focus on one of the main a11y issues, see comment:3.

Each issue should have its own ticket.

[afercia]

I think this can be closed now, the issue on comment:3 has been fixed in the past months when the Customizer panels have been changed to use visibility: hidden by default and visibility: visible on the current open panel.