Make WordPress Accessible

Category: Status Updates Toggle Comment Threads | Keyboard Shortcuts

  • Trisha Salas 6:08 pm on May 19, 2017 Permalink |

    The Last 3 Weeks in WPa11y! 

    Accessibility Tickets in 4.8

    These are the current accessibility related tickets slated for the 4.8 release:

    • #35566 removes the title attribute in the tag cloud widget
    • #38768 adds the site title as the alt attribute to the custom logo

    WordPress 4.8 introduces a few new media widgets as well as the ‘Nearby Events’ widget. Testing should continue to be sure that new accessibility issues aren’t introduced.

    Future Releases

    If you would like to have an impact on future WordPress releases join us during our bug scrubs! During bug scrubs we go through the “awaiting review” and “future release” reports.
    Gutenberg Editor

    The Gutenberg Editor is slated for a big reveal at WordCamp Europe.
    Let’s keep testing for accessibility related issues as development continues.

    You can find installation instructions here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

    Note that it is not a conventional plugin so there are some specific steps to follow.
    Accessibility Tasks

    There are several ongoing tasks with the goal to improve accessibility in the Admin area.

    • Proximity
    • Add widgets screen
    • Menu screen

    Widgets and menu screen

    It’s not a secret that there are many issues in the Add Widgets and Menu screens. What to do? @juliemoynat has suggested some improvements in this ticket: https://core.trac.wordpress.org/ticket/40677


    In web design, the principle of proximity states that related items should be placed close together. By the same token, if things are spaced farther apart they appear to have less relation to one another.

    This principle is so powerful, that it overrides similarity of color, shape, and other factors that might differentiate a group of objects.

    Proximity is especially critical for users with low vision. It will even be addressed in the next draft of the WCAG guidelines! https://w3c.github.io/low-vision-a11y-tf/requirements.html

    An initial ticket has been created, feel free to join in! https://core.trac.wordpress.org/ticket/40822

  • Joseph Karr O'Connor 5:03 am on August 13, 2015 Permalink
    Tags: , ,   

    Team Chat Summary August 10, 2015 

    New Structure Proposed

    Rian Rietveld wrote a proposal on how to structure our work better and plan ahead longer and we discussed it. What follows is examples from the proposal.

    Goals and Issues

    This will be a separate page on make/accessibility and also a main menu item. It gives an overview of our goals for the accessibility of WordPress, the work we (want to) do, how this is organized, how we test, a roadmap for the next year and how we track the progress of issues we are working on. An example of the roadmap for release 4.4:

    Release 4.4 (December 2015, Scott Taylor)
    • Finish still open issues focus from 4.3
    • Semantic heading structure Admin
    • The customizer
    • Handbook
    • Twenty Sixteen (?)

    Central Ideas

    Some central ideas also included in the proposal are keyboard focus, work on the handbook, color contrast, system to better follow tickets including splitting up tickets among team members on which to concentrate, and continue to develop code pattern library. Much more is included in the proposal and for now we will continue to work on the proposal to make it a more formal document to cover our activities over the next year.

    We also talked about the fact that having a planning document to refer to does not obviate the need to address all new features since there is a tight turn around towards the end of a cycle because that’s when the features going into the release are announced. If we don’t follow all new features we might miss one or more that advance to release at the very end.

    When we have it shaped up we will add the planning documentation to this blog in the form of pages and sub-pages to make it a community resource.

    • Samuel Sidler 1:43 pm on August 27, 2015 Permalink | Log in to Reply

      Just wanted to say that I love the idea of a longer term goals for this team! Short term goals are great, but it’s nice to be able to see the short term goals in context of where everything is headed. 🙂

  • Joseph Karr O'Connor 8:45 am on July 8, 2015 Permalink
    Tags: , ,   

    H1 in the admin

    For 4.3 there will be an H1 in the admin. #31650: Missing H1 heading in the admin. Assistive technology users look for the H1 for way finding. Though there is the page title, when AT separates out elements such as links, lists, and headings, the info needs to be there too. Two weeks ago we ran this by Mika Epstein @Ipstenu and she helped us understand heading levels and plugins. Mika spot checked some plugins and it showed that they are using H2 and her opinion is that “we can post about that in make/plugins to try and spread the word.” Thanks Mika. More work will be done on the rest of the hierarchy.

    Main Open Tickets

    We also briefly discussed:

    • #31661: Quicktags: Can’t add them using just a keyboard in IE,
    • #26601: Inappropriate content in headings on admin screens,
    • #32152 List table: sortable column headers accessibility,
    • #26601: Inappropriate content in headings on admin screens, and
    • #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior.
  • Joseph Karr O'Connor 2:38 am on May 2, 2015 Permalink
    Tags: , ,   

    Weekly Meeting Change

    This week during the Wednesday meeting we decided that the Monday testing meeting is now where the action is so we decided to stop having the Wednesday meeting. On Monday, May 4, we will all meet in the #accessibility channel in Slack at 18:00 UTC. We are also using Slack throughout the week to work on tickets and patches, ask questions, and discuss anything that comes up. First register for the WordPress forums and then follow the steps on the WordPress chat instruction page to get set up. Then find your way to #accessibility. See you there!

  • esmi 1:05 pm on April 12, 2012 Permalink  

    I’ve only just realised that Admin Bar links contain tabindexes. That’s bad enough but they’re not really in an intuitive/logical order. Can they be removed in a future version?

  • 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


  • esmi 9:34 pm on October 17, 2011 Permalink

    Try to figure out why it was considered necessary to add the title of an image as a title attribute to the image markup when inserting images into a post. Whose idea was that? The image’s title attribute serves no real purpose for sighted users but creates a whole load of completely unwanted noise for some screen reader users. Additionally, the title attribute is completely inaccessible to sighted non-mouse users.

    So what’s the point of it?

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