Core Development WordPress UI Forum Posts
Using a tabindex of -1 is (in my books) a fairly old trick to try and drop elements out of an existing tabindex order. But I suspect it’s a trick may have outlived its usefulness and may behave inconsistently across different user agents.What are your thoughts/experiences? Do we have more consistent best practice techniques that we can use instead?
@esmi the tabindex attributes are still needed on the toolbar as the HTML for it is outputted at the bottom but it’s shown at the top of the screen. All other tabindex have been removed making “tabbing” flow much better.
The problem with tabindexes is that they remove choice. I appreciate that the markup is at odds with the visuals but those who can see & use a mouse still have a choice as to where to go next. Tabindex takes that choice away from the keyboard navigators.
What about using “jump-to” links instead? Preferably hidden offscreen at the top of the markup but revealed on active/focus? That would be way cooler and offers choice.
Sure, can do that. There is already a “Skip to content” link that moves the focus to the main content area on all admin pages, bypassing both the toolbar and the menu.
Thinking we can add a similar link that would focus the toolbar’s container. It will have to be part of the toolbar code so it’s outputted on the front-end too and will have to have tabindex set as it will be near the bottom of the HTML source, but there will be no need for other tabindex attributes in the toolbar.
I’ve been playing with the admin bar, I removed all tabindexes (including the one in the admin bar search) and inserted a link immediately after the #wpadminbar div that pointed to #wibble.This was the only link with a tab index (1 , in this case).
I then added the wibble id to the quicklinks div. The resulting markup allows keyboard navigators to either proceed to the admin bar (by pressing Enter or similar) or, by just moving on, go go straight to body of the page. That works really nicely and keeps the whole thing self-contained for use on the front or back end. Thoughts?
Yes, that’s exactly what I meant. Lets put that in.
With this we will have two skip links at the top of each screen in the admin: Skip to content and Skip to toolbar. Perhaps both links can have the same tabindex value, maybe 5 or 10, so that they are accessed first on the screens. All other tabindexes are/will be removed.
Added this in [21423]. The trac ticket is at: http://core.trac.wordpress.org/ticket/21471
As a screen reader user, I could almost cry with joy to see this fairly simple addition of a skip link made. 
Cyndy, as a fellow screen reader user I was sad to think that you may not get what you hope for out of the proposed skip links. This is because the skip links themselves will need a tabindex value to move them to the top in tab order, because they are actually at the end of the page. Tabindex rarely works for screen reader users because the screen reader is working with a buffered copy of a page, not the page itself. So the skip links may not help you. Do you also use headings for navigation? Most screen reader users find these a lot more useful and reliable. Just press the letter “H” and see if your screen reader supports heading navigation.
If you re-read Ozz’s response, you’ll see that there will be a skip link at the top of the page in the Admin area that will allow people to jump straight to the Admin bar.
There are several new accessibility tickets on trac dealing with the use of “tabindex” and other accessibility enhancements. A few are already committed. It would be good if these can be tested and any substandard/improper behavior fixed while still early in the development cycle for 3.5.
I’ll be installing 3.5 bleeding edge on my local dev server shortly but, if I can, I’ll try to set up a remote 3.5 install that some of the others in this group can use for testing. Then we’ll try to collate some group feedback for you. Do you have a deadline date that we can use?
No strict deadline but would be good to deal with this before coding on the new features in 3.5 starts. About a week would be great.
Had a quick look through all of the current 3.5 tickets. Graham seems to be on top of a few of them. I’ve also added comments where appropriate. The rest seem fine to me.
Bim Egan, and 1 other are discussing. 
Andrew Ozz 9:30 pm on July 26, 2012 Permalink |
Yes, tabindex=”-1″ has been around for quite a while and is a bit inconsistent between the browsers. The good thing about it is that this is the only way to make a link or a form element “skip” when tabbing. Another good thing is that it makes any HTML element “focusable” from JS, so <div id=”can-focus” tabindex=”-1″> will not be in the tabbing order and can be focused with
document.getElementById('can-focus').focus(). Both of these are consistent for all browsers.sprungmarker 8:26 pm on July 30, 2012 Permalink |
Tabindex was not used for quite a while because if using it you have to use it consistently for the whole site. It was a real burden to get that maintained. tabindex -1 and 0 is now in use to get javascript working properly for keyboard use i.e. I am only use tabindex for the latter.