WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 3 years ago

#27705 closed defect (bug) (fixed)

Keyboard navigation should be constrained to the theme installer overlay

Reported by: nacin Owned by: afercia
Milestone: 4.7 Priority: low
Severity: normal Version: 3.4
Component: Themes Keywords:
Focuses: accessibility, administration Cc:
PR Number:

Description

Follow-up to #27521. This has existed since the overlay was added in 3.4.

Change History (10)

#1 @lancewillett
5 years ago

See also #28823 for the plugin screen overlay. Could be an a11y issue for any "overlay" interaction in the backend: Media Grid, theme and plugin details, etc.

#2 @afercia
4 years ago

  • Keywords close added

As far as I see maybe we can close this ticket?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 years ago

#4 @joedolson
4 years ago

This is still an issue, following discussion and testing by the #a11y team. The theme installer full screen modal does not constrain focus, allowing a user to tab into the full admin menu.

To test: open the theme installer modal. Tabbing forward: Tab through the modal into the preview screen. Tab through the preview. Focus will move into the browser address bar. When tabbing forward, will go to the admin menu. Tabbing backwards: initial focus is on close button. Press Shift+Tab and focus is moved to the list of themes.

What should happen: moving forward: after end of preview, tab should cycle back to close button. Moving backward: from close button, focus should move to end of preview window.

#5 @joedolson
4 years ago

  • Keywords close removed

#6 @afercia
4 years ago

Thinking this kind of issues where there's the need to remove from the tab order relevant parts of the UI can be solved without any JavaScript and using just CSS.

Unlike display: none, visibility can be overridden by setting the 'visibility' property on the descendants.

http://www.w3.org/TR/CSS21/visufx.html#visibility
The generated box is invisible (fully transparent, nothing is drawn), but still affects layout. Furthermore, descendants of the element will be visible if they have 'visibility: visible'.

This feature can be used as a handy way to remove elements from the tab order.

Applying visibility: hidden to the main body and visibility: visible to the Customizer, would allow to completely remove from the tab order all the main body focusable elements and bring back in the tab order just the Customizer descendants. The Customizer content would be the only visible (and tabbable) content available to assistive technologies.

In practice, this would emulate the native tabbing behavior: once users reach the end of the page, the tab order will start again from the beginning (the browser's URL bar) and vice-versa.

This could help with the Customizer sliding panels too, see #32493. cc @celloexpressions

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 years ago

#8 @afercia
3 years ago

Related: #33228

#9 @afercia
3 years ago

  • Keywords needs-patch removed
  • Milestone changed from Future Release to 4.7

Going to fix this in #33228.

#10 @afercia
3 years ago

  • Owner set to afercia
  • Resolution set to fixed
  • Status changed from new to closed

In 38520:

Accessibility: Improve the Customizer and Theme Installer initial focus.

The Customizer and Theme Installer open in full overlays that need to receive
focus. Also, keyboard navigation should be constrained within the overlays. Using
CSS visibility to hide all the content except the overlays, makes them the only
available and focusable content and allows browsers to handle focus natively.

See #29158.
Fixes #33228, #27705.

Note: See TracTickets for help on using tickets.