#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)
Change History (35)
#3
@
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.
#5
@
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.
#8
follow-up:
↓ 9
@
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
@
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:
↓ 11
@
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
@
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:
↓ 20
@
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.
#15
@
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
@
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.
#18
@
12 years ago
- Priority changed from highest omg bbq to high
- Severity changed from blocker to critical
#20
in reply to:
↑ 12
;
follow-up:
↓ 22
@
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:
↓ 23
@
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.
#22
in reply to:
↑ 20
@
12 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".
#23
in reply to:
↑ 21
;
follow-up:
↓ 24
@
12 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
#24
in reply to:
↑ 23
@
12 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.
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.