Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 5 years ago

#21340 closed task (blessed) (fixed)

Reconsider all "tabindex" attributes in the admin

Reported by: azaozz's profile azaozz Owned by: azaozz's profile 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 12 years ago.
21340-2.patch (47.1 KB) - added by azaozz 12 years ago.
A few places were missing from the first patch.
21340-3.patch (48.3 KB) - added by azaozz 12 years ago.
21340-4.patch (50.9 KB) - added by azaozz 12 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 12 years ago.
21340.5.diff (420 bytes) - added by lessbloat 11 years ago.
21340.6.diff (2.0 KB) - added by lessbloat 11 years ago.
21340.7.diff (2.5 KB) - added by lessbloat 11 years ago.
Combined .5 and .6.

Download all attachments as: .zip

Change History (35)

@azaozz
12 years ago

#1 @azaozz
12 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.

#2 @azaozz
12 years ago

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

@azaozz
12 years ago

A few places were missing from the first patch.

#3 @nacin
12 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.

#4 @azaozz
12 years ago

Sounds good, new patch coming up.

@azaozz
12 years ago

#5 @azaozz
12 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.

#6 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

@azaozz
12 years ago

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

#7 @azaozz
12 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.

#8 follow-up: @esmi
12 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.

#9 in reply to: ↑ 8 @azaozz
12 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.

#10 follow-up: @SpencerFinnell
12 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.

#11 in reply to: ↑ 10 @SergeyBiryukov
12 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

#12 follow-up: @jkudish
12 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.

#13 @nacin
12 years ago

  • Severity changed from normal to critical

#14 @nacin
12 years ago

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

#15 @nacin
12 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.

#16 @azaozz
12 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.

#17 @nacin
12 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.

#18 @nacin
12 years ago

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

#19 @lessbloat
12 years ago

What else needs to be done on this ticket?

#20 in reply to: ↑ 12 ; follow-up: @nacin
12 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.

#21 follow-up: @nacin
12 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.

@lessbloat
11 years ago

#22 in reply to: ↑ 20 @lessbloat
11 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".

@lessbloat
11 years ago

#23 in reply to: ↑ 21 ; follow-up: @lessbloat
11 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 - 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
Last edited 11 years ago by lessbloat (previous) (diff)

@lessbloat
11 years ago

Combined .5 and .6.

#24 in reply to: ↑ 23 @lessbloat
11 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.

#25 @azaozz
11 years ago

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

Fixed in [22250].

#26 @SergeyBiryukov
11 years ago

#22886 was marked as a duplicate.

#27 @a4jp.com
5 years ago

How do I remove the tabindex from the admin bar?

Note: See TracTickets for help on using tickets.