Ready to get started?Download WordPress

Make WordPress Accessible

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Graham Armfield 10:22 am on October 22, 2013 Permalink
    Tags: ,   

    Welcome to the Make WordPress Accessible Team 

    Hello. You’ve found the blog of the Make WordPress Accessible team – a bunch of volunteers who are striving to improve the accessibility of WordPress. We need your help.

    (More …)

  • Joseph Karr O'Connor 6:41 pm on June 25, 2014 Permalink | Log in to leave a Comment  

    Visual Focus Indication in Left Navigation 

    Rectangle Indicating Visual Focus

    Following up on trac ticket #28599, one of the proposed options is visual focus indication using a contrasting color rectangle around the border of the item selected. Since color alone should not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element, this is a second element in addition to color changes: dark gray to black when Plugins menu is selected, gray to blue text when sub-menu item Editor is selected.

    Left navigation menu with Plugins menu selected showing contrasting rectangle around menu item bounding box.

    Plugin menu selected, 2 px contrasting color rectangle indicating visual focus.

    Left navigation menu with Editor menu item selected showing contrasting rectangle around menu item bounding box

    Sub-menu item Editor selected, 2 px contrasting color rectangle indicating visual focus.

  • Joe Dolson 3:39 pm on June 24, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Draft guide for accessibility-ready reviewers 

    To go along with the accessibility-ready guidelines, I’ve been working on a document to help people who want to help perform accessibility reviews on themes. This document is targeted at members of the accessibility team who want to help support the review process by checking themes for accessibility.

    Please provide comments, so I can edit them into the most helpful guide they can be!

    Theme Accessibility Guide for Reviewers

  • Jen Mylo 5:45 pm on June 20, 2014 Permalink
    Tags: ,   

    More WCSF/Team Meetup Planning 

    Howdy again, folks. We’re working on making sure we have enough room blocks to make sure all the contributors who are coming in October can get a decent rate (or have a room provided by us if needed). Some of you replied to my post from last week and filled in the survey so I’d know you were planning to come, but some haven’t. I just want to make sure we count everyone so we can put you at the same hotel to make the meetup part easier.

    If you didn’t read the post before, the plan for the event is:
    Sat/Sun — WCSF conference
    Monday — community summit
    Tues/Wed — team meetups (i.e. the accessibility team being together in a place to talk issues, make plans, work together, etc)

    The people who identified themselves as active members of the accessibility team in the survey are:
    Katherine Mancuso, Cousett Hoover, Amy Hendrix, John Blackbourn, Joe Dolson, and Joseph Karr O’Connor.

    1. Is everyone on that list active on this team? I think a couple of people may have done something at one point but are actually more involved with core, but I don’t want to make any assumptions. Could someone let me know which of these fine folks are active here?

    2. A quick scroll back through the blog shows me some names that didn’t fill in the survey, like @grahamarmfield and @davidakennedy. If you guys aren’t interested in coming, can you let me know in the comments? If you are interested in attending, can you fill out the survey so I can have you on the list as we start deciding which hotels to put each team in (this goes for anyone on the team that’s not listed above)? We’ll be spread out among 4 or 5 hotels, so I want to be sure we can keep the teams together.

    And just a reminder that we have a travel assistance program this year to help contributors who don’t work for a wp-based company and can’t cover travel costs on their own. Apply for travel assistance by June 30.


    • Joe Dolson 3:06 pm on June 21, 2014 Permalink | Log in to Reply

      I don’t recognize Cousett Hoover or John Blackbourn as being participants in this team, but that’s possibly just because I only know them via IRC handles or WordPress.org user names; somebody else would have to confirm. There are currently a lot of quiet members of the team, I’d judge; people who are currently silent participants while they learn the ins and outs of accessibility, so it’s difficult to tell.

    • John Blackbourn 12:16 am on June 22, 2014 Permalink | Log in to Reply

      I’m johnbillion on wordpress.org. I put my name down for accessibility because the accessibility meetup we had at WordCamp London went very well. I would need to prioritise the core team though, if that affects things.

    • Joe Dolson 3:24 pm on June 24, 2014 Permalink | Log in to Reply

      Ah! Yep. Only know you as @johnbillion. Real names…so mysterious…

    • David A. Kennedy 2:28 pm on June 25, 2014 Permalink | Log in to Reply

      Howdy @jenmylo! Thanks for reaching out. My current schedule isn’t looking good for making it, although I’d love to! That may change, but probably not before you need to make your arrangements. Thanks for asking!

    • bramd 3:26 pm on June 25, 2014 Permalink | Log in to Reply

      I’m willing to attend WCSF and help out with accessibility related things. I just submitted a request for travel assistance. Funny enough that form lists all kinds of diversities, but not blindness.

  • Joseph Karr O'Connor 6:27 am on June 20, 2014 Permalink  

    Accessibility Team Update: June 18, 2014 

    Visual Focus In Left Navigation

    Screenshot of admin left navigation showing Posts menu selected with New Post submenu selected

    Posts menu selected with indistinguishable darker black shading, Add New sub menu item selected with text in dark blue. Note that dark blue text against dark gray is hard to see.

    Color Alone

    Visual focus indicators for wayfinding are relied on heavily by some keyboard-only users. @helen notes the enhanced visual focus indicators now in trunk. Ticket #28267 needs a lot more work bringing the focus style to various places but one area that needs a smart solution is left navigation. Now we are relying on color changes which are, in some instances, too subtle. Indeed, color is not to be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.


    We discussed this for most of the meeting and here are some suggestions.

    • Helen reports that a blue glow does not look good
    • White outline around menu item with white outline also around selected submenu item
    • Reversing the colors with another undefined indicator element
    • Triangle to the left of main menu item and selected submenu item
    • Underline under main menu item and selected submenu item (might be mistaken for links)

    Solution Needed

    We need some suggestions for an elegant solution. Bear in mind that there are eight admin color schemes and any solution should take that into account. I have created ticket #28599 to work on this issue. A WordPress Accessibility Team shirt to the person who comes up with the adopted solution!

    • jebswebs 5:02 pm on June 20, 2014 Permalink | Log in to Reply

      Just wonder if one of the eight admin color schemes could be called High Contrast and use a yellow on black color set. I have been battling the gray on white and gray on black fight with multiple theme developers in multiple CMSs for several years. It would be curious to know how many users ever take time to change from the Default admin color scheme.

      • esmi 7:12 pm on June 20, 2014 Permalink | Log in to Reply

        Helen and I have talked briefly about this before. The idea was that, as the admin skinning system matured, there would be more opportunities to provide low and high contrast admin skins via plugins, if necessary. It’s certainly something I’ve been wanting to do for years.

    • esmi 7:08 pm on June 20, 2014 Permalink | Log in to Reply

      I’m a big fan of reversing background and foreground colors, so in the example screenshot you posted above, I’d want to see something like a blue background with black/dark grey text.. It’s got to really “pop” for sighted keyboard navigators. triangle indicators are very nice as added features for onhover but I’d argue that they’re too subtle for focus highlighting. Ditto for underlines. General rule of thumb: if you have to visually hunt for the currently focused element, then you need something else.

      • Joseph Karr O'Connor 9:35 pm on June 20, 2014 Permalink | Log in to Reply

        So you and @jebswebs support a high and a low contrast admin color scheme which is a different path from devising a solution just for the left navigation that persists through all color schemes? I’m very interested in this idea, wonder if enough people will discover the feature. I think we still need robust focus indicators throughout admin, but support additional accessibility color schemes.

    • David A. Kennedy 2:35 pm on June 25, 2014 Permalink | Log in to Reply

      As I’ve said in our previous team meetings, I’m in favor of a suitable baseline for all color schemes. Although, I love the idea of specialized high contrast themes in addition to that.

  • Jen Mylo 12:16 am on June 13, 2014 Permalink
    Tags: , wcsf,   

    WordCamp SF 2014 

    Howdy, accessibility team! We’re getting ready to publish details about the plans for WordCamp San Francisco this October (which includes the opportunity for a mini team meetup), so if you’re thinking of attending, please read the post at http://make.wordpress.org/updates/2014/06/12/wordcamp-san-francisco-travel-contributor-days/ and take the short survey linked at the end of it so I’ll know how many team members to plan for. Don’t worry, this isn’t a commitment or anything, I just need to get some rough numbers for budgeting purposes (we’re doing a travel assistance program this year, if that makes a difference). Thanks!

    • Joseph Karr O'Connor 12:26 am on June 13, 2014 Permalink | Log in to Reply

      Thanks very much for the alert. It’s excellent that there is a travel assistance program. Thanks also for all the thinking and doing you are putting in to make WCSF a wonderful event.

  • Joe Dolson 8:52 pm on June 12, 2014 Permalink  

    Theme Review Accessibility Guidelines Update 

    In anticipation of WordPress 4.0, I’ve been working on revising the Theme Review accessibility guidelines. With the release of WordPress 4.0, the theme review accessibility guidelines will no longer be considered “draft” guidelines.

    My goal is two fold: first, to make them easier to understand by adding examples, and second, to reorganize them so that the most commonly encountered issues in themes are listed first.

    Additionally, I’m adding a section for “recommended” guidelines.

    Please review the draft of the updates and make comments on this post. Thanks!

    • bobeaston 11:34 am on June 13, 2014 Permalink | Log in to Reply

      This guide just keeps getting better and better. It hits the big issues, yet stays concise enough to be approachable. In a previous life, I watched a guide like this grow from a few pages that were useful to one with nearly a thousand pages that no one wanted to open. You’re on exactly the right path for keeping it useful.

      I imagine you might have plans for the following, but if not, I suggest:
      Add a very liberal sprinkling of reference links throughout the guide. People who work with accessibility issues day in and day out know where to quickly find many of the things mentioned in the guide, but your target audience may not. Help them find the quickest route to things like ” the W3C alt text decision tree,” ARIA techniques, etc.

    • Joe Dolson 2:55 pm on June 13, 2014 Permalink | Log in to Reply

      There should be a link for the alt text decision tree; I failed to copy that over from the current version. Whoops! I’ll get that fixed.

      Liberally sprinkling links is definitely an aim; I’ve started on that, but specific suggestions of resources are always welcome. I don’t want to overwhelm with links, either, of course.

      Thanks for your comments! Keeping it short and understandable has been one of the major goals from the beginning.

  • Joseph Karr O'Connor 3:57 am on June 12, 2014 Permalink  

    Accessibility Team Update: June 11, 2014 

    New Accessible Theme

    Joe Dolson is working on a new accessible theme for the Cities series using an innovative modular approach for accessibility by gathering up accessibility concepts into separate files.

    Joe says:

    “I’m explicitly placing all the accessibility-specific code into a11y.php and a11y.js, to make them easy to find. This is intended to be a useful resource for theme developers, so I want everything to be easy to find.”

    Also of note is skiplinks.js which fixes a bug in WebKit. Simply using an anchor link for the skiplink isn’t enough for WebKit, because keyboard focus will not follow visual focus without Javascript. Joe will be presenting this new theme in a session at WordCamp Chicago this weekend.

    Accessibility Theme Check Process Enhanced

    We are aware that a few themes that are not accessible have arrived in the theme directory with the #accessibility-ready tag. Perhaps the theme creators misunderstood the tag or copied it from another theme without thinking. We got a message from someone who knows accessibility that he bought a theme based on the fact that the free version has the #accessibility-ready tag. Expecting it to be accessible, he was disappointed. Contacting the theme creator he found out that they will be uploading a new free version without the tag.

    Joe Dolson on the process:

    “We’re still struggling with themes getting through the process without getting audited, but we have a recourse for this now. The official policy is to give the author notification that their theme needs to go through the accessibility-ready review to keep the tag, and that they have 72 hours to begin rectification – either by uploading a new version without the tag or by uploading a new version that will begin the process of meeting the accessibility-ready requirements. After 72 hours without a response, the theme will be suspended from the theme repository.”

    Unification of Visual Focus Indication

    It is essential to provide a visual cue to sighted keyboard-only users letting them know where they are on the page. There is no standard look for visual focus indicators. The issue is made more complex because user agents approach this in different ways. @helen talked with us last week and this week again about the fact that the visual look of focus indicators is not unified, and in some instances is not perceivable. For example, on the Media Library screen this is a screenshot showing “apply” button with dotted line focus indicator active and it is not perceivable. One tab press to the right of the “apply” button is the “All dates” select menu selected with a screenshot showing “All dates” select menu with blue glow and dotted line.

    The base look might be the approach taken by WebKit, a blue glow. A base look with more than one element is what we seek. Even if the color blue cannot be perceived there is still the glow. This week we have a goal of organizing the approach to the UI in such a way that the visual focus indicators are unified and perceivable.

    • _Redd 8:37 pm on June 18, 2014 Permalink | Log in to Reply

      Hi, everyone, regarding the Unification of Visual Focus Indication, and the meeting today (June 18), I found an example of what I was talking about with using icons to demonstrate a change of focus in the left-hand nav menu.


      Here, the icons “reverse” dark and light areas, and also have additional visual indicators that show the item has received focus. A picture is worth a thousand words, and this example says it far better than I could.

    • _Redd 8:53 pm on June 18, 2014 Permalink | Log in to Reply

      Whoops! Follow Up!

      These icons undergo changes when hovered over, not when receiving focus. The idea of course is that we could develop css to perform similarly when the item receives focus.

  • Joseph Karr O'Connor 8:53 pm on May 8, 2014 Permalink  

    Accessibility Team Update: May 7, 2014 

    Global Accessibility Awareness Day

    I will be talking about WordPress accessibility here in Santa Monica at Yahoo! to celebrate Global Accessibility Awareness Day (GAAD) on May 15. There are many events happening all over the world, perhaps there’s one close to you. If you want to celebrate GAAD but don’t have an event nearby, then here’s a suggestion from Deborah Edwards-Onoro, a front-end WordPress web developer and user experience pro: use only your keyboard for navigation for one hour.

    Automated Accessibility Testing

    It is necessary for me to point out that the very best enterprise-strength automated accessibility checking environments can only accurately report out about thirty percent of the errors. Nonetheless, automated testing, especially command-line testing, will be a valuable addition to the test environment, and we need to explore this. The Netherlands has a commitment to making sure that government sites are accessible, so they are supporting the development of Quail an open-source, MIT-licensed suite of tests that assess web page structure and content. The library is currently developed against WCAG and Section 508 accessibility standards. Accessibility team member David A. Kennedy wrote a great post, “WordPress needs automated accessibility testing” in which he mentions Quail and another tool, pa11y, and I recommend reading what he has to say on the topic.Thanks to David for creating a discussion on this vital topic. David was interviewed by WP Tavern this week and we look forward to seeing that posted soon.


    Karl Groves, another accessibility team member, is working on tenon.io, which is in beta now and promises to be a very powerful accessibility checking tool. While Tenon will be proprietary, Karl tells me that: “We are going to have a Free for Open Source program. As long as the project using Tenon is open source, the account is free.”


    While there is no doubt that the accessibility team can and must improve collaboration with other WordPress teams, we are also interested in creating ways to expand our reach through innovation and also by collaboration with people doing similar work outside of WordPress. Automated testing is one way to innovate. We saw that the Quail project has created an accessibility module to work within Drupal so we invited Mike Gifford, a Drupal 8 Core Accessibility Maintainer, to our meeting this week to learn about the Drupal accessibility operation. According to Mike “Just to be clear about the automated (accessibility) testing & Drupal. It will be a great addition in the future, it’s found some interesting bugs when we have applied it, but it really has only been marginally useful thus far.” Mike agreed to share info and join forces with us where our interests are similar and we look forward to collaborating with his team and with accessibility teams for other projects.

  • David A. Kennedy 6:11 am on May 2, 2014 Permalink

    WordPress needs automated accessibility testing 

    The Make WordPress Accessibility Team needs help wrapping its arms around WordPress Core as new features get created while helping refine the existing codebase to make it more accessible to people with disabilities. Our small team can’t be everywhere and test everything, but we’re working to gather an accurate picture of what needs our help the most.

    Once we have a better idea of what needs our attention the most, how do we maintain a good grasp of it? Automated accessibility testing can help in a big way here, and I’d like to start working to incorporate it into Core. I brought this up in our last Accessibility Team chat.

    What’s automated accessibility testing? Similar to unit testing, this would allow developers to run a set of tests during their local development workflow of patches for WordPress via a command line tool. These tests would output results that would alert developers to potential errors and help them fix things like missing alt attributes or unassociated form fields and labels. Automated accessibility testing isn’t perfect and it won’t help us overcome all of our challenges, but it can help us find simple, easy-to-fix errors, alert us to large trouble spots within the codebase that need more manual testing and allow us cover a bit more ground. It’s a nice compliment to the manual testing and education we’ve done so far.

    What do we need to consider when selecting a tool?

    WordPress Accessibility Team member Karl Groves has a nice blog post about this. He says you should consider three things:

    1. Flexibility and Freedom. These tools exist for one reason only: to work for you. Every single second you spend learning the UI, figuring out how to use it, or sifting through results is a second of development time that could go into actually improving the system. The tool must be flexible enough to offer the freedom to use it in any environment by any team of any size in any location.
    2. Accurate. Developers of accessibility tools want to find every single issue they possibly can. This unfortunately often includes things that are, in context, irrelevant or of low impact. They also may require an additional amount of human effort to verify. This is a disservice. Tool vendors need to understand that their clients may not have the time, budget, or knowledge to sift through false positives. The user should be able to immediately eliminate or ignore anything that isn’t an undeniable issue.
    3. Understandable The user of the tool needs to know exactly what the problem is, how much impact the problem has, where it is, and how to fix it. Overly general, overly concise, or esoteric result descriptions are unhelpful. If a tool can find a problem, then it can make intelligently informed suggestions for remediation

    I think these are good goals to try to hit. Ideally, we want something that will have little to no impact on a developer’s workflow, allow us to select different test criteria and deliver accurate results we can act on.

    As research, I’ve spoken to Jesse Beach. She’s a Senior Front End Engineer at Acquia Inc., a Drupal contributor, a contributor to QuailJS (a tool Drupal uses for automated accessibility testing) and a member of the Drupal Accessibility group. She’ll help us look at QuailJS as a possible automated accessibility testing approach. And hopefully, we can share accessibility knowledge between these two awesome open source projects! We talked about what we (WordPress Accessibility Team) want to accomplish with automated testing, how a tool might fit into a WordPress developer’s workflow, the future of QuailJS and a bit about accessibility in our different open source projects.

    One other possibility on the short list of tools besides QuailJS includes Pa11y. We will likely look at others as well.

    Next steps

    • Firm up a list of requirements for a tool
    • Experiment with some tools
    • Meet with Core team members to discuss
    • Develop test criteria

    Your ideas and feedback are welcome!

    • Aaron Jorbin 5:55 pm on May 5, 2014 Permalink | Log in to Reply

      I like the idea of expanding our automated tests. For each of the possibilities (QuailJS, Pa11y possibly others), I think it would be good to lay out the requirements, benifits and costs.

      Personally, I would like to see whatever tool we use fit into our existing testing flow. This means that it could be run from the command line so that we can run the tests on travisCI and as a part of the grunt precommit command.

      • David A. Kennedy 3:24 pm on May 7, 2014 Permalink | Log in to Reply

        Integrating into the existing testing flow is a high priority, probably only below selecting a tool that has accurate, configurable tests.

        Do we have guidance on selecting or integrating with tools that may not be fully open source. For instance, maybe the tests we write/modify are all open source, but we hit a third-party api to actually get results that isn’t open source.

        Selecting something that’s fully open source/GPLV2 compatible has preference of course, but I thought the question is worth asking.

    • Matthieu Faure 8:10 pm on May 9, 2014 Permalink | Log in to Reply

      Hi David,

      I’m interested in accessibility, WordPress and testing. I’m a follower of @WPaccessibility and I’ve read the last “Accessibility Team Updates” on the blog. Here are a few information you might find helpful for the topic.

      You could find some help with Tanaguru, an opensource accessibility checker (disclaimer: I’m its creator). Tanaguru offers different kinds of audit like page and site-wide audit, but for the expressed need to test the backoffice of WordPress with ATAG, you could use the “scenario audit”. For short, you record a scenario a user could follow (e.g. creating a post, adding an image, modifying the alt, publishing), and send it to Tanaguru, that in turn replays it. Scenario can be replayed when you want. (Technically speaking, it is based on bricks of Selenium.)

      For the needs of automation, you can also plug it with continuous integration tools. We are actually playing with our own Jenkins (that we use for building Tanaguru).

      Here are a few links (hope they’re ok for comments):

      We know a bit WordPress as it runs our corporate site and our blog. I’d be really happy to contribute to “Make WP Accessible”.

      Hope to exchange with you soon on the subject


      • David A. Kennedy 2:15 am on May 13, 2014 Permalink | Log in to Reply

        Hi Matthieu,

        Thanks for your comment and for filling us in about Tanaguru. It definitely sounds like it should be on the list. I’ll add it and we’ll take a closer look once we get to that point.

        My contact info is on my site. Feel free to reach out.

  • Joe Dolson 6:24 pm on April 28, 2014 Permalink

    Update on WordCamp accessibility planning 

    I had a great conversation with Andrea Middleton at WordCamp Minneapolis this weekend, and we’re making some plans to work on the core accessibility features that WordCamp organizers will need to pay attention to in building their sites.

    Some of the key tasks will include working through the accessibility issues in the base themes available for WordCamp organizers to build from, providing some documentation to help organizers know what design standards they need to meet, and doing some basic training on checking their work.

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