Make WordPress Core

Opened 2 years ago

Last modified 5 months ago

#30490 assigned defect (bug)

Switch editor tabs focus style

Reported by: afercia Owned by: afercia
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.0
Component: Editor Keywords: needs-patch
Focuses: ui, accessibility Cc:


Please consider focus style should always be visible for accessibility.
On the "Visual" and Text" editor switches, it's currently reset for the "active" state.

When activating "Visual" or "Text" there's a difference in focus management and this introduces a different visual "effect" but the focused element should always be perceivable.

Attachments (3)

30490.patch (630 bytes) - added by afercia 2 years ago.
current.png (3.3 KB) - added by azaozz 22 months ago.
with-patch.png (3.7 KB) - added by azaozz 22 months ago.

Download all attachments as: .zip

Change History (20)

2 years ago

#1 @afercia
2 years ago

  • Keywords has-patch added

#2 @azaozz
2 years ago

The problem is that the Text tab/button remains focused after clicking it. With the above patch the blue outline is visible and doesn't look right. The Visual tab remains focused too but TinyMCE moves the focus to the iframe on show, so this is less noticeable. Don't see a good way to fix this from CSS, i.e. have a :focus styling and not show it on click.

Trying to focus the Text editor (textarea) on clicking the Text button may behave unexpectedly in different browsers (Chrome tries to scroll-into-view to the bottom of long posts, etc.). Even if we get that to work right, it will be a change of behavior for the Text editor "tabbing" as it will "jump over" all buttons.

#3 @afercia
2 years ago

Yup the blue outline will be visible: the button is focused so it should be visible.
Please consider also this is a WCAG "Failure of Success Criterion", see:
Not sure about US Section 508 but I know it's under review to be updated and aligned with WCAG 2.

If the concern is about the outline when the button is clicked with the mouse, what about to move focus to the first quicktags button? That's actually the first thing to get focused when users tab forwards so it would just replicate the standard behavior.

Anyway, moving focus around is often problematic for accessibility, see #29838

#4 @helen
2 years ago

  • Version changed from trunk to 4.0

#5 @iseulde
2 years ago

  • Keywords needs-patch added; has-patch removed

#6 @iseulde
2 years ago

  • Component changed from TinyMCE to Editor
  • Summary changed from TinyMCE: switch editor tabs focus style to Switch editor tabs focus style

#7 @afercia
22 months ago

  • Milestone changed from Awaiting Review to 4.3
  • Type changed from enhancement to defect (bug)

I'd propose to make a decision for 4.3, either fix this or close the ticket :) As already pointed out, please consider visible focus is a specific Level AA Success Criterion, see http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

Removing or making the visual focus non-visible would be a clear "Failure", in WCAG terminology.

This ticket was mentioned in Slack in #core by jorbin. View the logs.

22 months ago

#9 @jorbin
22 months ago

  • Keywords early added
  • Milestone changed from 4.3 to Future Release

This coming back up two days before Beta doesn't give enough time to make a fix or don't fix decision (since we should fix this as our aim is to pass WCAG 2.0 AA as much as possible).

Some screenshots of the current behavior and proposed behavior could help move this forward. Let's aim to get this addressed in 4.4

#10 @azaozz
22 months ago

Maybe we need a better "focused" style for these two buttons, perhaps something subtler? None of the other buttons that remain visible after clicking gets that blue outline (as far as I see).

Last edited 22 months ago by azaozz (previous) (diff)

22 months ago

22 months ago

#11 @afercia
22 months ago

@azaozz beat me by a couple of minutes :) Screenshot to illustrate the issue:


Whether or not focus gets moved inside the editor area when users activate one of the two buttons, keyboard users move around (and backwards) tabbing. At some point focus will be hidden for them. The proposal would be to just don't reset the standard focus as the current CSS does.

#12 @azaozz
22 months ago

Yeah, the problem is that the blue outline stays visible for all users after clicking on one of these buttons. I wish there was a simple way to make that work only for people that need it :)

Also when the Visual editor is selected, the "Visual" button is practically disabled (nothing happens when clicked). Same for the Text button and the Text editor. Don't think we add outline/focus style to disabled buttons.

Last edited 22 months ago by azaozz (previous) (diff)

#14 @afercia
8 months ago

  • Keywords early removed

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

5 months ago

#16 @rianrietveld
5 months ago

  • Milestone changed from Future Release to 4.8

Discussed this in the accessibility team meeting:
We need to do more research on what will be the best behaviour
Set for 4.8

#17 @rianrietveld
5 months ago

  • Owner set to afercia
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.