Make WordPress Core

Opened 10 years ago

Closed 7 years ago

#30490 closed defect (bug) (wontfix)

Switch editor tabs focus style

Reported by: afercia's profile afercia Owned by: afercia's profile afercia
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: Editor Keywords:
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 10 years ago.
current.png (3.3 KB) - added by azaozz 9 years ago.
with-patch.png (3.7 KB) - added by azaozz 9 years ago.

Download all attachments as: .zip

Change History (24)

10 years ago

#1 @afercia
10 years ago

  • Keywords has-patch added

#2 @azaozz
10 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
10 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
10 years ago

  • Version changed from trunk to 4.0

#5 @iseulde
9 years ago

  • Keywords needs-patch added; has-patch removed

#6 @iseulde
9 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
9 years 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

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.

9 years ago

#9 @jorbin
9 years 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
9 years 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 9 years ago by azaozz (previous) (diff)

9 years ago

9 years ago

#11 @afercia
9 years 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
9 years 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 9 years ago by azaozz (previous) (diff)

#14 @afercia
8 years ago

  • Keywords early removed

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

8 years ago

#16 @rianrietveld
8 years 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
8 years ago

  • Owner set to afercia
  • Status changed from new to assigned

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

7 years ago

#19 @afercia
7 years ago

  • Milestone changed from 4.8 to 4.8.1

We're running out of time for the 4.8 release, so: punting. Also, the new editor could change lots of things here.

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

7 years ago

#21 @afercia
7 years ago

  • Keywords needs-patch removed
  • Milestone 4.8.1 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

With the new editor (Gutenberg) coming soon, this issue is outdated. Closing as per today's bug scrub.

Note: See TracTickets for help on using tickets.