WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#21340 closed task (blessed) (fixed)

Reconsider all "tabindex" attributes in the admin

Reported by: azaozz Owned by: azaozz
Milestone: 3.5 Priority: high
Severity: critical Version:
Component: Accessibility Keywords: needs-patch
Focuses: Cc:

Description

This has come up many times, the tabindex HTML attributes are generally bad for accessibility and have to be used sparingly/only when really necessary.

Looking through all admin screens, the only place that needs tabindex is the toolbar as it is outputted at the bottom of the HTML source and is shown at the top of the screen.

Attachments (8)

21340.patch (38.1 KB) - added by azaozz 3 years ago.
21340-2.patch (47.1 KB) - added by azaozz 3 years ago.
A few places were missing from the first patch.
21340-3.patch (48.3 KB) - added by azaozz 3 years ago.
21340-4.patch (50.9 KB) - added by azaozz 3 years ago.
Includes all from 3.patch plus tabindex="-1" for the menu images
skip-to-main-content-1.png (151.3 KB) - added by jkudish 3 years ago.
21340.5.diff (420 bytes) - added by lessbloat 2 years ago.
21340.6.diff (2.0 KB) - added by lessbloat 2 years ago.
21340.7.diff (2.5 KB) - added by lessbloat 2 years ago.
Combined .5 and .6.

Download all attachments as: .zip

Change History (34)

@azaozz3 years ago

comment:1 @azaozz3 years ago

21340.patch removes nearly all tabindex in the admin, leaving them only in the toolbar. Next step will be to add or fix focusing the first input field on the screens that have one.

comment:2 @azaozz3 years ago

Related tickets: #7993, #10297, #19930, #21334.

@azaozz3 years ago

A few places were missing from the first patch.

comment:3 @nacin3 years ago

I'm game for this. It would probably make sense to do both steps at once — so in the same commit, a screen gets tabindexes removed and also the initial focus fixed. Multiple screens per commit is fine, but I'd rather not remove all tabindexes in one go, then go back to test what initial focuses need to be adjusted. That also allows us to consider on a case-by-case basis where tabindex might actually be needed outside of the toolbar.

comment:4 @azaozz3 years ago

Sounds good, new patch coming up.

@azaozz3 years ago

comment:5 @azaozz3 years ago

21340-3.patch adds focusing on the first input field on the Categories, Tags and Edit Category/Tag screens (including for custom taxonomies). With these we have the following auto-focused fields:

  • Log in form: name
  • New or Edit Post: title (only if empty or after saving)
  • Taxonomy screens: tax name
  • Edit taxonomy screens: tax name
  • Edit comment: author name

With most tabindex reset/removed, tabbing works much better on all screens and follows the element order properly without skipping/bypassing fields or links.

comment:6 @DrewAPicture3 years ago

  • Cc xoodrew@… added

@azaozz3 years ago

Includes all from 3.patch plus tabindex="-1" for the menu images

comment:7 @azaozz3 years ago

In [21311]:

Remove nearly all tabindex attributes from the admin, leaving them only where absolutely necessary (for now that's only the toolbar).

Add tabindex="-1" for the menu images links to avoid double tab stops there when the menu is expanded.

Fix/add auto-focus on the first input fields on the Add/Edit Post, all taxonomy, all edit taxonomy, Log In and Edit Comment screens.

See #21340.

comment:8 follow-up: @esmi3 years ago

Add tabindex="-1" for the menu images links to avoid double tab stops there when the menu is expanded.

I'm not sure that's going to work consistently across all UAs. Negative tabindexes still tend to get priority above non-indexed elements whenever I've tested.

comment:9 in reply to: ↑ 8 @azaozz3 years ago

Replying to esmi:

Seems to work in current Chrome, FF, IE9 and Opera. According to the specs tabindex of -1 makes the element not focusable when tabbing. However when using a screen reader, the browser can be forced to tab to elements with negative tab index.

Was also looking at removing the links around the menu icons completely. Not sure if we should change the html drastically but can make the icons "clickable" with JS instead of having second link for each.

comment:10 follow-up: @SpencerFinnell3 years ago

  • Cc SpencerFinnell added

Not 100% sure how to make a patch, but the last commit removed an extra quotation mark out of wp_login_form(), causing the submit button to not be rendered properly.

comment:11 in reply to: ↑ 10 @SergeyBiryukov3 years ago

Replying to SpencerFinnell:

the last commit removed an extra quotation mark out of wp_login_form(), causing the submit button to not be rendered properly.

Related: #21514

comment:12 follow-up: @jkudish3 years ago

  • Cc joachim.kudish@… added
  • Keywords needs-patch added

As reported by a user on the WordPress.com forums tabbing is now broken when clicking the "edit" date in the publish metabox in the admin. Tabbing should move the focuse to the date fields but instead focused to the top of the screen with the message "skip to main content" as per this screenshot. I confirmed the problem being in Core and in the most recent version of Webkit browsers. I discussed this with azaozz who confirmed this as a WebKit bug but suggested there may be a workaround that would fix this problem for all versions. In the mean time, tabbing works fine with other browsers such as Firefox.

comment:13 @nacin3 years ago

  • Severity changed from normal to critical

comment:14 @nacin3 years ago

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

comment:15 @nacin3 years ago

  • Priority changed from normal to highest omg bbq
  • Severity changed from critical to blocker

[21311] causes the Cancel button to be tabbed to first after a comment edit or reply. The comment form tabbing order right has bitten us before — [19665]. We should probably look over [21311] again to make sure no similar situations have cropped up.

To this this one, we should probably move the Cancel button later in the page. And really for all similar situations with a Cancel button.

comment:16 @azaozz3 years ago

Yes, moving the button lower in the html would be the best. There is also a bug in Chrome where the browser doesn't advance the tabbing order after an element becomes focused/active. For now the only way to do that is by using JS.

comment:17 @nacin3 years ago

In [21883]:

Move the Cancel button for replying and quick-editing a comment to after the primary update/reply button so tabbing from the comment field takes you to the primary action. see #21340.

comment:18 @nacin3 years ago

  • Priority changed from highest omg bbq to high
  • Severity changed from blocker to critical

comment:19 @lessbloat3 years ago

What else needs to be done on this ticket?

comment:20 in reply to: ↑ 12 ; follow-up: @nacin3 years ago

  • Type changed from enhancement to task (blessed)

Replying to jkudish:

As reported by a user on the WordPress.com forums tabbing is now broken when clicking the "edit" date in the publish metabox in the admin. Tabbing should move the focuse to the date fields but instead focused to the top of the screen with the message "skip to main content" as per this screenshot. I confirmed the problem being in Core and in the most recent version of Webkit browsers. I discussed this with azaozz who confirmed this as a WebKit bug but suggested there may be a workaround that would fix this problem for all versions. In the mean time, tabbing works fine with other browsers such as Firefox.

This still needs to be fixed.

comment:21 follow-up: @nacin3 years ago

Also, everything in [21311] needs a line-by-line, form-by-form review to make sure that secondary/cancel/delete buttons or links always appear after primary/save/update/publish buttons.

@lessbloat2 years ago

comment:22 in reply to: ↑ 20 @lessbloat2 years ago

Replying to nacin:

Replying to jkudish:

As reported by a user on the WordPress.com forums tabbing is now broken when clicking the "edit" date in the publish metabox in the admin. Tabbing should move the focuse to the date fields but instead focused to the top of the screen with the message "skip to main content" as per this screenshot. I confirmed the problem being in Core and in the most recent version of Webkit browsers. I discussed this with azaozz who confirmed this as a WebKit bug but suggested there may be a workaround that would fix this problem for all versions. In the mean time, tabbing works fine with other browsers such as Firefox.

This still needs to be fixed.

As of 21340.5.diff there is no need to click tab after you click "edit", it will now auto-focus on the month select box after you click "edit".

@lessbloat2 years ago

comment:23 in reply to: ↑ 21 ; follow-up: @lessbloat2 years ago

Replying to nacin:

Also, everything in [21311] needs a line-by-line, form-by-form review to make sure that secondary/cancel/delete buttons or links always appear after primary/save/update/publish buttons.

Here are my findings:

  • QUESTION - trunk/wp-admin/edit-form-advanced.php - tabs through secondary "Save Draft" and "Preview" buttons before primary "Publish" (I'm assuming this is expected).
  • QUESTION - trunk/wp-admin/edit-form-comment.php - 1) should this be tabbing through all of the editor toolbar buttons before it gets to the comment body? 2) Tabs through secondary "View Comment" button on right before getting to primary "update" button (I'm assuming this is expected).
  • OK - trunk/wp-admin/edit-link-form.php - is going away with 3.5
  • OK - trunk/wp-admin/edit-tag-form.php - Only one primary "Update" button shows on page
  • OK - trunk/wp-admin/edit-tags.php - Only one primary "Add New Tag" button shows on page
  • OK - trunk/wp-admin/includes/class-wp-posts-list-table.php - N/A
  • OK - trunk/wp-admin/includes/class-wp-theme-install-list-table.php - N/A
  • OK - trunk/wp-admin/includes/class-wp-themes-list-table.php - N/A
  • OK - trunk/wp-admin/includes/dashboard.php - Fixed in 21340.6.diff
  • OK - trunk/wp-admin/includes/meta-boxes.php - All instances work as expected
  • OK - trunk/wp-admin/includes/template.php - All instances work as expected
  • OK - trunk/wp-admin/menu-header.php - N/A
  • OK - trunk/wp-admin/plugin-editor.php - Work as expected
  • QUESTION - trunk/wp-admin/press-this.php - Tabbing starts on secondary "Save Draft", then goes to primary "Publish" (I'm assuming this is expected). Side note: the rest of the page could use some tabbing love in general (probably best to do this under a separate ticket though).
  • OK - trunk/wp-admin/theme-editor.php - Work as expected
  • OK - trunk/wp-includes/class-wp-editor.php - Fixed in 21340.6.diff
  • OK - trunk/wp-includes/general-template.php - Work as expected
  • OK - trunk/wp-includes/js/tinymce/wp-mce-help.php - Work as expected
  • OK - trunk/wp-login.php - Work as expected
Version 0, edited 2 years ago by lessbloat (next)

@lessbloat2 years ago

Combined .5 and .6.

comment:24 in reply to: ↑ 23 @lessbloat2 years ago

Replying to lessbloat:

Discussed these questions in IRC (UI chat)

  • QUESTION - trunk/wp-admin/edit-form-advanced.php - tabs through secondary "Save Draft" and "Preview" buttons before primary "Publish" (I'm assuming this is expected).

This is expected

  • QUESTION - trunk/wp-admin/edit-form-comment.php - 1) should this be tabbing through all of the editor toolbar buttons before it gets to the comment body? 2) Tabs through secondary "View Comment" button on right before getting to primary "update" button (I'm assuming this is expected).

1) Quicktags are currently tabbed through (this is not a bug)

2) This is expected.

  • QUESTION - trunk/wp-admin/press-this.php - Tabbing starts on secondary "Save Draft", then goes to primary "Publish" (I'm assuming this is expected).

This is expected.

comment:25 @azaozz2 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in [22250].

comment:26 @SergeyBiryukov2 years ago

#22886 was marked as a duplicate.

Note: See TracTickets for help on using tickets.