WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 3 years ago

#6352 closed defect (bug) (fixed)

Tabindex bugs in trunk

Reported by: westi Owned by: westi
Milestone: 2.9 Priority: high
Severity: major Version: 2.5
Component: Administration Keywords: needs-patch
Focuses: Cc:

Description

I have fixed some tab index bugs in trunk in [7472] and [7473]. However some bugs still remain:

  1. We should give a tabindex to the js inserted things.
    1. The Edit link for the permalink should have a tabindex of 1.
    2. The Preview button should have a tabindex of 4.
    3. The Add button for tags (I think this is js inserted) needs a tabindex of 3.
  2. I couldn't get a tabindex on the category selection check boxes to work.
  3. Do we want a tab index of 2 on the Visual/Html switchers and the media insert buttons?
  4. The Write > Page page tab indexes don't appear to work it only seems to work for the title and the page content and nothing else.

Attachments (1)

edit-tabindex.diff (2.3 KB) - added by westi 7 years ago.
Adds tabindex to the permalink edit but doesn't work correctly

Download all attachments as: .zip

Change History (11)

comment:1 @westi7 years ago

(In [7479]) Add tabindex. See #6352.

comment:2 @westi7 years ago

(In [7480]) Tabindex for the Preview/View links. See #6352.

@westi7 years ago

Adds tabindex to the permalink edit but doesn't work correctly

comment:3 @westi7 years ago

I've done 1b,1c.

The above patch does 1a but doesn't work :-(

Need some more eyes on this.

comment:4 @Denis-de-Bernardy6 years ago

  • Component changed from General to Administration

comment:5 @Elpie6 years ago

The TABINDEX attributes in the core should be removed. If the code has a logical order, users who tab through the links and form fields will be able to follow through the order without the need for tabindex. Links and form fields receive focus in the code order without any problems.
BUT, if only a few tabindex attributes are applied (which is the case now), then those receive focus in the order specified by the tabindex. Anything without a tabindex attribute is unable to be accessed until all tabindexes have been hit.
WordPress (as of 2.8 beta) does not have tabindex attributes on all links and form fields & this decreases accessibility.
Currently, anyone who develops an admin theme has a heck of a job working around the limitations of the core tabindexes. Trying to get a good document flow is impossible unless those developers hack the core. As the admin becomes easier to theme there will be more people hitting up against this issue. Core hacks are also the easiest way for most users to get rid of the tabindexes that are output in themes.

This is a case of "too much accessibility" resulting in less usability for people who rely on navigation with the tab key.
More information is here: http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-tabindex/

So, my suggestion is - remove all tabindex attributes and rely on ensuring the code outputs a logical flow. It will make WordPress more accessible.

comment:6 follow-up: @Denis-de-Bernardy6 years ago

anyone who develops an admin theme has a heck of a job working around the limitations of the core tabindexes

It's not that nasty, actually. It merely needs some docs...

comment:7 in reply to: ↑ 6 ; follow-up: @Elpie6 years ago

Replying to Denis-de-Bernardy:

anyone who develops an admin theme has a heck of a job working around the limitations of the core tabindexes

It's not that nasty, actually. It merely needs some docs...

I just hack the core ;)
But seriously, even the tabindex in the default themes is problematic. Have you ever tried to navigate from the frontend? As soon as you load a page/post that has comments enabled, the first tab you do drops you straight down to the comment form. This completely breaks the document flow and throws users in places they don't expect to be.

The tabindex in the backend is unnecessary as long as the document is ordered. If they absolutely MUST stay, here's what I would do to improve them...

Rename the files so the UI names match the file names - they don't currently, which is confusing. This is important, particularly to keyboard users who can see what appear to be strange locations displaying in their browser bars.

Make sure there is a tabindex for every link in the logical flow of the document - otherwise users get taken from tab to tab, then to the non-indexed links afterwards, which is not necessarily the same document flow that mouse users get.

But, really, maintenance would be a whole heap easier if tabindexes were removed and attention paid to a logical document order. I find that even without any changes, I can get around the backend very quickly by keyboard, as long as I have first deleted all tabindexes.

Someone else want to test this and chime in?

comment:8 in reply to: ↑ 7 @Denis-de-Bernardy6 years ago

Replying to Elpie:

But, really, maintenance would be a whole heap easier if tabindexes were removed and attention paid to a logical document order. I find that even without any changes, I can get around the backend very quickly by keyboard, as long as I have first deleted all tabindexes.

please attach the patch

comment:9 @ryan5 years ago

  • Milestone changed from 2.9 to Future Release

comment:10 @westi3 years ago

  • Milestone changed from Future Release to 2.9
  • Resolution set to fixed
  • Status changed from new to closed

The Administration code has changed significantly since the ticket was opened and any issues need re-identifying and resolving as new tickets.

Closing this as Fixed against 2.9 when the changes above were made.

Note: See TracTickets for help on using tickets.