Make WordPress Accessible

Updates from November, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • Jen 3:43 pm on November 28, 2011 Permalink
    Tags: 3.3   

    WordPress 3.3 is coming up on RC1 (meaning it’s close to launch). We tried to catch as many accessibility issues as we could, but chances are we missed things. If anyone would be willing to run 3.3 beta through the paces and report back on how it does/what fixes need to be made, that would be great. If you’re not set up with an svn install, you can download the beta tester plugin to put the beta on a test site.

    • Andrew Nacin 12:45 am on November 29, 2011 Permalink | Log in to Reply


    • Graham Armfield 9:40 am on November 29, 2011 Permalink | Log in to Reply

      Are you primarily thinking back end or front end or both, and should we reply here – or elsewhere?

      • Jane Wells 11:55 am on November 29, 2011 Permalink | Log in to Reply

        Mainly the dashboard, since that’s where the changes are in 3.3. Responses in comments on this thread.

    • Graham Armfield 11:05 am on November 29, 2011 Permalink | Log in to Reply

      Not accessibility I know but not sure where to put this…. It seems impossible to switch comments off at the individual page level.

      General settings are to allow comments. I edit a page and uncheck Allow comments and then Update the page. I’m returned to the edit page again and the comments checkbox is checked again. Not sure if it’s theme dependant but it happens on both twentyten and twentyeleven.

      • Jane Wells 11:53 am on November 29, 2011 Permalink | Log in to Reply

        Hi Graham. Please don’t use this blog for non-accessibility bugs, feature requests, etc. Try the support forums for troubleshooting. https://wordpress.org/support

        • Graham Armfield 11:21 am on December 2, 2011 Permalink | Log in to Reply

          Hi Jane. Understand that I’ve missed the boat on accessibility updates for 3.3. So looking forward to 3.4, please can you outline the correct route for people like myself to suggest accessibility enhancements. In order to get accessibility as right as possible I believe it’s important to design it in as early as possible.


  • Jen 2:32 am on November 28, 2011 Permalink  

    Changed a couple of settings:

    • Must fill in name and email, but removed the ‘must have previously approved’ setting so now comments go live immediately instead of waiting to be moderated.
    • Close comments on posts older than 14 days old. Comments go unnoticed, and no action gets taken. Hopefully discussions can get to agreement within 2 weeks (well before, if we’re lucky) and the resolution can make its way over to the appropriate trac ticket.
  • Jen 2:11 am on November 28, 2011 Permalink
    Tags: dashboard menu,   

    Do people think it is better for the dashboard menus down the left side to work as described in A, B, or C:

    • A. Tabbing goes from top-level item to its subs and cycles through them, then proceeds to the next top-level item, etc., and hitting Enter/Return acts as clicking on the link to whatever item you’ve tabbed to; or
    • B. Tabbing goes from top-level item to top-level item, and hitting Enter/Return ‘opens’ the subs and then you can tab through them?
    • C. A more accessible suggestion that we haven’t thought of?

    Please leave your vote/suggestion/comments in a reply to this post IF you work professionally in the accessibility field OR you need to access WordPress without a mouse/trackpad/rollerbar/other mouse-like input device (generally due to disability). If you don’t fit in one of these categories: while your opinion is valuable, it’s not the one we’re looking for at this particular time. So regular designers, developers, and users, please don’t distract from the pros and the target population on this thread. If you are an accessibility pro and have not introduced yourself on this blog before, or a keyboard access/screen reader user, please add a note about your qualifications/experience (for pros) or your typical setup/environment (for users — which screen reader, do you use keyboard shortcuts in addition to tabbing etc) so that we can put your suggestions in context. Thanks.

    P.S. Please don’t derail the conversation by using this thread to suggest other features.

    • Steveorevo 2:22 am on November 28, 2011 Permalink | Log in to Reply

      B – hitting enter twice would then activate the given top level

      P.S. Support for touch ala mobile devices in widget drag n’ drop would be nice, but hiring me would be nicer! 😉

      • Jane Wells 2:36 am on November 28, 2011 Permalink | Log in to Reply

        Can you let us know your experience with accessibility so we have some context for your participation? Thanks.

        P.S. This is not the place for feature requests. The regular forums have a whole section for that, and this blog is very specifically focused on accessibility.

        • Steveorevo 2:57 am on November 28, 2011 Permalink | Log in to Reply

          Sorry about the request here Jane. Noted.

          I’m afraid I don’t have the accessibility background, however my “related field” is UI, specifically simulation, and formerly 3D gaming engines along with some early telephony APIs (E911, etc.). This means catering UI systems to humans visually, audibly, and sometimes tactile. I guess that is a far cry from accessibility. WordPress is now my passion.

          I’d agree with Chris that K (below) that ‘B’ proposes a feel for structured hierarchy. Although you pointed out that this is strictly accessibility, part of accessibility (as in Section 508) is catering to individuals with visual and cognitive disabilities. Cognitive would relate to the acquiring of knowledge and the experience of a laid out UI. I would imagine the perception and grouping (and acting on that grouping with ‘Enter’) would influence accessibility. My reasoning behind choosing B. The implication for screen readers would reflect this as well, not unlike the structured top-level menus one would hear when navigating a voice assisted phone system.

          • Jane Wells 3:00 am on November 28, 2011 Permalink | Log in to Reply

            The UI group is where we focus on issues of hierarchy, design, etc. Most of our designers and developers (myself included) are not particularly experienced with screen readers and keyboard access rules/guidelines, which is why this separate blog exists and really is meant to be kept specific. If you are interested in more general UI stuff, you may want to follow/join in at https://make.wordpress.org/ui

    • Chris Kankiewicz 2:25 am on November 28, 2011 Permalink | Log in to Reply


      From a usability standpoint this would give the navigation a structured feel of hierarchy. I’m not sure what implications this would have on screen readers.

      • Jane Wells 2:34 am on November 28, 2011 Permalink | Log in to Reply

        We’re looking strictly for accessibility (as in Section 508) feedback here, not general usability.

        Can you let us know what your background with accessibility includes so we have some context for your participation? Thanks.

        • Gooitzen van der Ent 7:16 pm on January 7, 2012 Permalink | Log in to Reply

          Hello Jane,

          A bit difficult to jump in on a conversation somewhere. Read you were looking for people to help out.

          Made an inventory of accessibility within WordPress. Sure it can be improved. Feel free to use it where you can. Hope it helps.

          • Gooitzen van der Ent 7:21 pm on January 7, 2012 Permalink | Log in to Reply

            Of course adding the link to the blog post might help…. :duh:: 😉

            Blog post title: Accessibility & WordPress
            Blog post link: http://ecodelphinus.com/2012/01/07/accessibility-and-wordpress/

            I have multiple years experience designing for accessibility. However, at the moment a bit stretched for time and means to do any testing and take on volunteer jobs at the moment. Will try to keep an eye on things, and help where possible.

            Would like to add or see added a, clearly marked, accessible and WCAG 2.0 theme to WordPress.com if possible. Seems to be missing at the moment.

    • Larry Thacker Jr. 2:28 am on November 28, 2011 Permalink | Log in to Reply

      Not all screen readers are very good at handling dynamic content, so the simpler the better. Thus I prefer the first option. I am not an accomplished web coder, but perhaps using heading levels would help a screen reader user approximate the second option by heading level navigation, which all screen readers I know of can do.

    • SG 2:54 am on November 28, 2011 Permalink | Log in to Reply

      C. I think a mix of A and B would be more efficient, as explained below:

      Most admins keep their most-used top-level items expanded most of the time. Tabbing should work as described in B, jumping from top-level to top-level, and hitting enter expands any non-expanded groups. When tabbing arrives at an already-expanded group, it should work as described in A, and tab to each sub-level element. Hitting enter on an expanded element should collapse it.

      My 2 cents. 😉

      • Jane Wells 2:56 am on November 28, 2011 Permalink | Log in to Reply

        In 3.3, there’s no more click to expand/keep expanded… everything is done with flyouts (unless you don’t have javascript enabled) so that everything is (for mouse users) one click away.

        • Steveorevo 3:00 am on November 28, 2011 Permalink | Log in to Reply

          Forgot about that in the latest beta sounds like B would even be more to the point as A would entail excessively long tabbing operations. 🙂

        • SG 5:39 am on November 28, 2011 Permalink | Log in to Reply

          Jane, in that case A does work better, but I still think it could be augmented.

          How about when tabbing over the top-level items, the currently selected item is automatically expanded (to show what’s inside). If the user wants to go down, they hit enter, if not, they keep hitting tab to traverse the remaining top-level elements. Naturally each auto-expanded item is then auto-collapsed upon tabbing away from it.

          Have you thought about allowing the use of arrow-keys once the user has ‘tabbed’ into the menu area? Down to jump down to the next element within the current hierarchy (eg. top-level items), right to go down into sub-elements, and left to go back up to the top-level parent.

    • Peter Bossley 2:56 am on November 28, 2011 Permalink | Log in to Reply

      I am a screen reader reliant user of Word Press and I believe option B is preferable, assuming that you can make this function properly with a wide range of screen readers which might be difficult, but possible. Heading navigation would be good in this context since screen reader users are used to navigating by headings to skip to the next set of controls, etc. While keyboard shortcuts are nice to haves, because of screen readers heavy use of keyboard hooks for quick navigation mode they are somewhat less useful for screen reader reliant users out of the box. In other words they have to know the shortcuts are there and then activate bipass mode to pass the keystrokes directly to the browser.

    • Graham Armfield 10:47 am on November 28, 2011 Permalink | Log in to Reply

      My gut feel is for A as tabbing is surely the lowest common denominator of keyboard accessing links etc on a page.

      B sounds appealing but how do you intend to convey to keyboard users (both sighted and non-sighted) how the menu functionality works before they come across it? If that can be squared successfully then I’d probably favour B.

      Another technique I’ve experienced is using the space key to open menus, but I guess that’s less useful these days with touch screens.

    • Everett Zufelt 11:08 am on November 28, 2011 Permalink | Log in to Reply

      I think that B would be the easiest to use, provided that you can provide some type of affordance to educate users about the functionality. The common paradigm, as I currently experience it, is that tabbing cycles through all items in a superfish style of menu. That being said, the assistive tech / keyboard only user that is tabbing through a page is * incredibly * inefficient.

      I think he problem should be ‘How can we provide an affordance to indicate to users that the top level menu items, when activated, expose a sub-menu?’. Once the menu is exposed I would think that the ability to tab through the sub-menu items would be expected by most users.

      Drupal Core Accessibility Maintainer, 7 years experience using screen-readers.

    • Léonie Watson 11:47 am on November 28, 2011 Permalink | Log in to Reply

      Option B would be the preferable default solution IMHO. To offer a really good experience, give people the option to enable option A if they wish though.

      ARIA could be used to build in the affordance needed to make option B really usable, for recent screen readers at least. Check out the menu, menubar and menuitem roles:

      Headings really shouldn’t be used to represent the menu hierarchy. It’s semantically incorrect for one thing, and it negates the usefulness of headings as a navigation mechanism within the content of the page for another.

      • Graham Armfield 12:05 pm on November 28, 2011 Permalink | Log in to Reply

        Hi Léonie, do you have an example site that uses option B and ARIA to ‘build the affordance’ that you would consider to be accessible. I’d be really interested to analyse that.


    • Bob Easton 12:42 pm on November 28, 2011 Permalink | Log in to Reply

      previously: consultant for IBM’s Accessibility Center – now: recently retired

      Many of us favor B because the function feels right. Screen reader users (blind and low vision) are the most difficult to accommodate. Implementing choice B with conventional HTML, and even with script supplemented HTML is not only difficult to do well, but leaves us with the problem several have noted: how is the visitor informed of how the structure behaves.

      Léonie’s answer is the best because ARIA does exactly what is needed. ARIA was designed specifically for bring accessibility to dynamic implementations. The key is the “role” attribute. Just as screen readers (can, if enabled) announce HTML elements, they can announce ARIA roles. And THERE is how the visitor learns of the behavior. The screen reader will announce to the visitor that the top level is a menu, and that lower elements are menuitems.

      Graham: many examples can be found with a Google search for “aria menu example.”

      For anyone else not familiar with ARIA, the WAI-ARIA Overview at W3C is very helpful.

    • Sharron Rush 2:14 pm on November 28, 2011 Permalink | Log in to Reply

      +1 for Leonie’s suggestion. B is the best of those offered. Consider adding a level of access to the sub-menus that is operated using arrow keys. So you tab through the top, main navigation level and then use the down arrow to open and explore sub-items. You can see this type of navigation in action on our web site http://www.knowbility.org. And congratulations WordPress on providing these accessibility options!

      Sharron Rush
      co-author, Maximum Accessibility
      Executive Director, Knowbility, Inc

      • Graham Armfield 6:20 am on November 29, 2011 Permalink | Log in to Reply

        Thanks for the link Sharron. I’ve had a look at the navigation and it works as you say. But I’m wondering how you’re informing people that they need to use the up/down keys when the flyout menus appear?

        I’ve also tried with NVDA and JAWS in Firefox but I’m not getting any audio prompt to indicate that a submenu is there.

        • Bob Easton 10:50 am on November 29, 2011 Permalink | Log in to Reply

          Do you hear “menu” spoken? That should be the clue. Once the visitor hears that word, they should know there are menuitems reached by arrow keys. Unfortunately the blind have to know a lot more about how things work than most of us. Hearing an ARIA role announced, they learn / know to take the right action.

    • esmi 3:27 pm on November 28, 2011 Permalink | Log in to Reply

      I’ve already argued strongly against option A and for option B on the wordpress.org support forums as I think A would create significant problems for keyboard navigators. I do like Leonie’s suggestion of using ARIA as an enhancement – just as long as there is no reliance on this additional functionality. Not all non-mouse users will be using screen reading software.

    • Jane Wells 3:41 pm on November 28, 2011 Permalink | Log in to Reply

      Looks like B is the clear winner, which is handy since that’s what went into core over the weekend. We’re at the end of beta, pre-RC right now in the 3.3 dev cycle. We tried to catch as many things like this as possible, but there were a lot of changes with the admin menus and admin bac/toolbar, so we may have missed something. If anyone would be willing to put the 3.3 beta through its accessibility paces, if we missed other things we can try to hit them before we get to RC. Will start new thread for that, though.

    • Everett Zufelt 6:14 pm on November 28, 2011 Permalink | Log in to Reply


      You say that B went in over the weekend. Can you say how you’ve addressed the requirement for there to be an affordance to assist sighted and visually impaired users about the functionality of the top level menu links?

    • sam C 11:56 pm on November 28, 2011 Permalink | Log in to Reply

      D. I think the WordPress admin menu should work the same way the Fluency Admin plugin (https://wordpress.org/extend/plugins/fluency-admin/) works it. Because when user clicks a link, it doesn’t take em back to the top.

      • Jane Wells 12:35 am on November 29, 2011 Permalink | Log in to Reply

        The point of this thread is to deal with non-click situations, when there is no mouse or equivalent input device.

        • Sam C 10:24 pm on December 10, 2011 Permalink | Log in to Reply

          Thanks for that clarification. I was alluding to the fact that, that mention plugin has short-cut keys. But when you said “Tabbing”, I first thought of the Tabs or buttons in general, but I now know you actually mean the “Tab” Key on my keyboard. In my UX experience when developing AIR applications (that’s, of course, when I’m not developing WordPress sites. 😉 ) it seems to be standard that the tabbing on menus that have sub-menus go as choice “B”, but the “spacebar” key usually expands the parent tab just like in the [+] to [-] show/hide links does on many sites. However the “Enter” key is what executes the selected item.

          Thanks Sam

    • Everett Zufelt 3:47 pm on November 30, 2011 Permalink | Log in to Reply

      Since option B has been implemented, I am curious if anyone has tested it? In particular, I am curious about what affordances are available to indicate the functionality of the link?

      • Andrew Ozz 8:37 pm on November 30, 2011 Permalink | Log in to Reply

        The full “first run” version went in yesterday evening. It implements role=menu, role=menuitem and aria-haspopup on both the top menubar and the left-side menu.

        The functionality is still enhanced with JS: Tab to select, Enter to open submenus that have role=menu, Tab to go through submenu items when opened (visible) , Esc to close the submenu and return to the top menu (and select it), then Tab to go to the next top menu item.

        As always we would appreciate more testing of this, especially by people that work in that field or by screenreader users.

        • Jane Wells 10:37 pm on November 30, 2011 Permalink | Log in to Reply

          Bearing in mind that today is RC, so no more enhancements. Only addressing blocker bugs that are bad enough for enough people to prevent moving forward for the rest of 3.3 (less than 2 weeks).

          Any enhancements at this point will go in the dot release or 3.4.

    • Everett Zufelt 10:21 am on December 1, 2011 Permalink | Log in to Reply

      I don’t rally have time, but if someone can provide me with credentials to a installation to test I will test these menus. My intuition tells me that you will have some confused users. Particularly since menu and menuitem are ‘widget’ roles (interactive), and can cause screen-readers to work in a way that some users may find disorienting.

      The menu / menuitem roles are really designed to mimic a menu in a desktop application (think the ‘File, Edit, View, etc.’ menus in Google Docs).

      • Jane Wells 11:51 am on December 1, 2011 Permalink | Log in to Reply

        We don’t generally set up test installations for volunteers to QA on, as the main point is to see how things work on real setups (vs our own protected/quirky environment). The beta tester plugin can turn any WP installation into a test site running trunk: https://wordpress.org/extend/plugins/wordpress-beta-tester/

        If the Aria stuff is likely to confuse people we can delay release to pull it out, but it was added at the suggestion of comments on this thread. We released RC early this morning and are not supposed to still be making changes, so I would say either make a very specific suggestion that you think will address the problems you’re anticipating and provide a link that will explain the how-to so @azaozz can look into it, or hop into IRC today to discuss real-time. irc.freenode.net #wordpress-dev Thanks.

    • Everett Zufelt 12:50 pm on December 1, 2011 Permalink | Log in to Reply

      @westi on #wordpress-dev setup a test environment for me. I tested with FF 8.0 / JAWS 13.

      1. I logged into the site.
      2. I was taken to the Dashboard.
      3. There was nothing identified as ‘menu’
      4. There was a ‘list of 14 items’ near the top of the DOM.
      5. The first item ‘Index’ had a sub-list of 2 items, but they had no content (no words / links / anything).
      6. Activating another item in the first list (Users) took me to a new page.
      7. @westi told me that ‘Posts’ is one of he top level menus, JAWS (control + f) could not find ‘Posts’ on the Dashboard page.
      I hope this feedback helps.

  • esmi 1:53 pm on November 7, 2011 Permalink


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