Make WordPress Accessible

Updates from July, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • esmi 12:33 pm on July 26, 2012 Permalink  

    Negative Tab Indexing 

    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?

    • Andrew Ozz 9:30 pm on July 26, 2012 Permalink | Log in to Reply

      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 | Log in to Reply

      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.

  • Andrew Ozz 12:42 am on July 24, 2012 Permalink  

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

    • esmi 8:33 pm on July 25, 2012 Permalink | Log in to Reply

      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.

      • Andrew Ozz 10:12 pm on July 25, 2012 Permalink | Log in to Reply

        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.

        • esmi 11:48 am on July 26, 2012 Permalink | Log in to Reply

          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?

        • Cyndy Otty 12:47 pm on July 26, 2012 Permalink | Log in to Reply

          As a screen reader user, I could almost cry with joy to see this fairly simple addition of a skip link made. 🙂

    • Bim Egan 4:04 pm on July 30, 2012 Permalink | Log in to Reply

      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.

      • esmi 9:26 am on July 31, 2012 Permalink | Log in to Reply

        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.

  • Andrew Ozz 12:39 am on July 24, 2012 Permalink  

    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.

    • esmi 8:21 pm on July 25, 2012 Permalink | Log in to Reply

      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?

      • Andrew Ozz 10:05 pm on July 25, 2012 Permalink | Log in to Reply

        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.

        • esmi 12:11 pm on July 26, 2012 Permalink | Log in to Reply

          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.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar