Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#33767 closed defect (bug) (invalid)

AX_FOCUS_03: Admin Toolbar Should Use Negative Tabindex for 'Skip to toolbar'

Reported by: atomicjack's profile atomicjack Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Administration Keywords: has-patch
Focuses: accessibility, administration Cc:


Admin toolbar currently uses positive tabindex values, this is not recommended practice for accessibility.

It is recommended that authors avoid positive values for the tabindex attribute because it is brittle (any focusable elements added to the page without an explicit tabindex value greater than zero will come last in the tab order) and can easily result in a page which is extremely difficult to navigate, causing accessibility problems.

The rules also state that, either all tabindexes must be 0 OR greater than 0. Currently there are several set to 0, -1, etc. Moving these all to 0 or a negative value would ensure the order of tab is predictable and more accessibly-friendly.

<a class="screen-reader-shortcut" href="#wp-toolbar" tabindex="1">Skip to toolbar</a>

Attachments (1)

33767.diff (741 bytes) - added by atomicjack 9 years ago.
Changes the Skip to Toolbar tabindex to 0 for consistency, accessibility and predictability

Download all attachments as: .zip

Change History (4)

9 years ago

Changes the Skip to Toolbar tabindex to 0 for consistency, accessibility and predictability

#1 @atomicjack
9 years ago

  • Keywords has-patch added

#2 @atomicjack
9 years ago

Before patch: #wpadminbar failed ax_focus_03 accessibility standards.

After patch: #wpadminbar passes ax_focus_03 accessibility standards and brings in-line with the rest of WordPress.

#3 @joedolson
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Thanks for your contribution! However, the WP Admin bar actually needs to use positive tabindex in order to be reasonably accessible via keyboard. The reason for this is because the keyboard HTML is placed at the very bottom of the code when it's inserted in wp_footer. While it's not generally recommended to use positive tabindex, it is actually a reasonable solution to this issue. In actual user testing, this is a better experience than removing that value.

Because it's only a single link that has tabindex and it has an index of '1', it works effectively. The problem with positive tabindex is that in maintaining sequence and pushing items out of sequence. This this code is visually positioned at the top of the document and should become the first focused item in tab sequence, this is the right solution.

If WordPress had a hook for inserting code at the top of the HTML body element, that would potentially be a better solution, but that's not possible.

Note: See TracTickets for help on using tickets.