WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 18 months ago

Last modified 16 months 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 21 months ago.
21340-2.patch (47.1 KB) - added by azaozz 21 months ago.
A few places were missing from the first patch.
21340-3.patch (48.3 KB) - added by azaozz 21 months ago.
21340-4.patch (50.9 KB) - added by azaozz 21 months 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 20 months ago.
21340.5.diff (420 bytes) - added by lessbloat 18 months ago.
21340.6.diff (2.0 KB) - added by lessbloat 18 months ago.
21340.7.diff (2.5 KB) - added by lessbloat 18 months ago.
Combined .5 and .6.

Download all attachments as: .zip

Change History (34)

azaozz21 months ago

comment:1 azaozz21 months 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 azaozz21 months ago

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

azaozz21 months ago

A few places were missing from the first patch.

comment:3 nacin21 months 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 azaozz21 months ago

Sounds good, new patch coming up.

azaozz21 months ago

comment:5 azaozz21 months 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 DrewAPicture21 months ago

  • Cc xoodrew@… added

azaozz21 months ago

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

comment:7 azaozz21 months 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: esmi21 months 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 azaozz21 months 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: SpencerFinnell21 months 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 SergeyBiryukov21 months 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: jkudish20 months 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 nacin19 months ago

  • Severity changed from normal to critical

comment:14 nacin19 months ago

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

comment:15 nacin19 months 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 azaozz19 months 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 nacin19 months 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 nacin19 months ago

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

comment:19 lessbloat19 months ago

What else needs to be done on this ticket?

comment:20 in reply to: ↑ 12 ; follow-up: nacin19 months 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: nacin19 months 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.

lessbloat18 months ago

comment:22 in reply to: ↑ 20 lessbloat18 months 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".

lessbloat18 months ago

comment:23 in reply to: ↑ 21 ; follow-up: lessbloat18 months 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 - Works 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 - Works as expected
  • OK - trunk/wp-includes/class-wp-editor.php - Fixed in 21340.6.diff
  • OK - trunk/wp-includes/general-template.php - Works as expected
  • OK - trunk/wp-includes/js/tinymce/wp-mce-help.php - Works as expected
  • OK - trunk/wp-login.php - Works as expected
Version 1, edited 18 months ago by lessbloat (previous) (next) (diff)

lessbloat18 months ago

Combined .5 and .6.

comment:24 in reply to: ↑ 23 lessbloat18 months 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 azaozz18 months ago

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

Fixed in [22250].

comment:26 SergeyBiryukov16 months ago

#22886 was marked as a duplicate.

Note: See TracTickets for help on using tickets.