Reconsider all "tabindex" attributes in the admin

[azaozz]

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.

[azaozz]

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.

[azaozz]

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

[azaozz]

A few places were missing from the first patch.

[nacin]

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.

[azaozz]

Sounds good, new patch coming up.

[azaozz]

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.

[azaozz]

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

[azaozz]

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.

[esmi]

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.

[azaozz]

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.

[SpencerFinnell]

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.

[SergeyBiryukov]

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

[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.

[nacin]

[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.

[azaozz]

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.

[nacin]

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.

[lessbloat]

What else needs to be done on this ticket?

[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.

[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.

[lessbloat]

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]

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

[lessbloat]

Combined .5 and .6.

[lessbloat]

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.

[azaozz]

Fixed in [22250].

[SergeyBiryukov]

#22886 was marked as a duplicate.

[a4jp.com]

How do I remove the tabindex from the admin bar?