Ready to get started?Download WordPress

Make WordPress Accessible

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

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

  • Joseph Karr O'Connor 6:17 am on April 26, 2014 Permalink  

    Accessibility Team Update: April 23, 2014 

    Authoring Tool Accessibility Guidelines Testing

    Jeanne Spellman (http://www.w3.org/People/jeanne/), W3C, joined us for the meeting to discuss the Authoring Tool Accessibility Guidelines (ATAG) testing we will be doing on trunk starting May 12. ATAG testing is, in part, useful for guiding development of accessible “software for generating websites, for example, content management systems (CMS).”

    ATAG Overview

    The Authoring Tool Accessibility Guidelines (ATAG) Overview explains how ATAG testing will:

    • help make authoring tools themselves accessible, so that people with disabilities can create web content, and
    • help authors create more accessible web content — specifically: enable, support, and promote the production of content that conforms to Web Content Accessibility Guidelines (WCAG).

    ATAG Testing Harness

    The W3C is developing an automated way to deliver ATAG test instructions and test result tracking and reports. It will also display WCAG test instructions and techniques, where applicable. In the the overall test instructions doc that was used when developing the tests there are general instructions at the top, followed by a table with the ATAG success criteria, and the test(s) for each one. As we are testing to WCAG level AA so will we be testing to ATAG level AA.


    Jeanne has about 15 volunteer testers. Thank you Jeanne! She explained the process: “We set up a page of accessible content, and a page of inaccessible content. Then we have a page of different types of content – video, audio, tables. Some of the ATAG tests check to see if WordPress breaks accessible content, while others see if WordPress fixes inaccessible content.” We discussed access to a test instance of WordPress trunk which is ready to go thanks to Rian Rietveld. There is no estimate as to how long the testing will take since it is a new process.

    Helping WordPress and the W3C

    This process will help improve WordPress and it will also help make ATAG 2.0 a finalized W3C standard. We are testing to WCAG level AA so we will be testing to ATAG level AA which will help the W3C process. Jeanne explained: “The writing is all done, and now we just need to prove to W3C management that there are 2 real world examples of every success criteria and 5 authoring tools have implemented ATAG level A.  AA is a huge bonus.”

    Accounts and Trac

    We noted that the volunteer testers will all need WordPress accounts. Aaron Jorbin very thoughtfully posted the core handbook link to working with trac and opening a ticket. Joe Dolson noted that: “It (testing) doesn’t have to be finished to be able to create tickets – we should be ticketing every discovery as we move forward.” The W3C team will be able to pull reports of all the errors from the testing harness tool which should facilitate the process.

  • Joseph Karr O'Connor 6:10 pm on April 18, 2014 Permalink  

    Accessibility Team Update: April 16, 2014 

    Team Member Thanks

    Thanks all the other teams who participated in making WordPress 3.9 happen and who reached out to the accessibility team for assistance. Many more people are asking us to check things than ever before. Special thanks to accessibility team members David A. Kennedy, Graham Armfield, and Joe Dolson who are mentioned in the 3.9 credits.

    Weekly Meeting Time

    There’s always confusion when the time changes and I regret that I compounded the confusion by being confused myself. I’m now using StatusClock.app by Pulsely for OS X set to GMT/UTC so I’ll be sure to call the weekly meeting to order at 19:00 UTC.

    Previous Test

    When the accessibility team did the last round of testing it was intended that it be done over a short period of time, but due to various factors it spread out over two months. That was a keyboard-only test because we were certain that, given our resources, we could not finish a full test. It turns out we could not finish even the attenuated test in a reasonable amount of time. This was not the intended outcome but I learned that we need many more testers to perform the testing in an effective manner. This is why I was very glad to make a testing plan with Jeanne Spellman of the W3C when we were at the International Technology and Persons With Disabilities Conference a month ago.

    New Test Round

    Jeanne Spellman of the W3C, the team contact for the User Agent Working Group and the Authoring Tool Accessibility Guidelines Working Group (AUWG), has committed to helping us test WordPress trunk using the Authoring Tool Accessibility Guidelines (ATAG). Jeanne has assembled a good number of volunteers to do the testing and they will file tickets or bump things up to me as soon as they have identified an issue. This time I feel confident that with current team members providing guidance the W3C team will be able to accomplish the task in a short enough period of time to be most effective. Testing is now scheduled to start the week of May 12, 2014.


    For those not familiar with ATAG, it is primarily for developers of authoring tools including software for generating websites such as content management systems. There are two areas of focus: making sure that the authoring tool user interface is accessible, and that the authoring tool supports the production of accessible content. Just as with WCAG 2.0, ATAG has three levels of success criteria in order of increasing compliance: A, AA, and AAA. We are testing to WCAG 2.0 level AA so it follows that the ATAG testing will also be done to level AA. ATAG testing will help us discover the issues we need to address next. ATAG at a Glance provides a short summary of the accessibility principles and guidelines in ATAG 2.0.

  • Joe Dolson 9:02 pm on April 15, 2014 Permalink
    Tags: ,   

    Update on accessibility-ready theme tag 

    We’re gradually working the kinks out of the process. There was an oversight in the automated process that added the accessibility-ready keyword to themes, so that only new themes were automatically getting the keyword, and not updated themes that added it. That’s been fixed, which will improve our ability to note themes that need to go through the review process.

    There’s a lot of support for the process, and the theme review team is invested in making this work, but I could use some backup in actually doing the reviews. Even if you don’t have the accessibility background, let me know if you’re interested: I’m happy to provide training to make sure you’ve got the knowledge it takes to do this review.

    • David A. Kennedy 4:00 pm on April 16, 2014 Permalink | Log in to Reply

      @joedolson I can help out with this once I finish up a few other projects. It’s a good place for me to contribute since it’s theme-centric. Feel free to reach out to me with details on how to get started.

  • Joseph Karr O'Connor 7:56 am on March 29, 2014 Permalink  

    Accessibility Team Update: March 26, 2014 

    Meeting Time Change

    We will be going back to a meeting time of 19:00 UTC next Wednesday, April 2.


    The meeting this past Wednesday was interesting. Now we’re getting to the heart of the matter.

    So far, we have compiled a keyboard-only report on most of 3.8 and have some data to rely on.

    The first pattern we identified from the testing is poor visual focus in the Admin. @RianReitveld created a ticket dealing with keyboard focus. Better visual indication of focus on elements in the Admin (#27173). This ticket is now closed (fixed.) Thanks Rian!

    Testing 3.9

    We have to quickly change gears because 3.9 is due out in 19 days and we have to test and issue some tickets if we want to catch any errors. A list of items to concentrate on will help guide us.

    Contact @AccessibleJoe for details if you want to help test 3.9.

  • Andrea Middleton 7:09 pm on March 24, 2014 Permalink
    Tags: ,   

    WordCamp Websites and Accessibility 

    Howdy, accessibility team! Currently, WordCamp websites are not reliably accessible across the board, which is sad-making. We want to change this; can you help?

    First, we’d like to make sure that the themes we make available for WordCamp organizing teams to customize with CSS are all accessible. The themes available for WordCamps to customize are:

    Twenty Ten
    Twenty Eleven
    Twenty Twelve
    Twenty Thirteen
    Twenty Fourteen
    WordCamp Base
    WordCamp Base Redux

    Can you tell us which of the above themes have accessibility issues, so we can make (or submit patches for) those fixes?

    Second, we’d like to create a guide of baselines for CSS accessibility (contrast, etc) so organizers can know what expectations we have for official sites.

    If you’re available and interested in helping WordCamp websites become more accessible, we’re incredibly grateful for your help.

    • Joe Dolson 7:28 pm on March 24, 2014 Permalink | Log in to Reply

      That’s awesome. At the moment, Twenty-Fourteen is the only one of those themes that includes really solid accessibility. Twenty-Thirteen and Twenty-Twelve are decent, but have some key problems that aren’t resolved. Some of these are getting dealt with along with the 3.9 release, however.

      The simple baseline for CSS accessibility is actually really straightforward: accessible contrast needs to have a luminosity ratio of 4.5:1 for normal sized text (e.g. below 18pt), or 3:1 for large text. That’s the minimum baseline. This also means that change states should meet the same requirements: e.g., :hover and :focus states or the contrast between linked text and neighboring text. Those contrast requirements can be minimized, however, if there are non-color indicators (such as a link underline), that make it obvious that the link is different from surrounding text.

      The major issue most common to the rest of these themes relate to keyboard accessibility — visible focus and access to drop-down menus, in particular.

      I’ve already provided assistance with some patches for Twenty Twelve, Thirteen, and Fourteen; but I’m happy to assist with whatever you need to make these themes more accessible.

    • jebswebs 7:38 pm on March 24, 2014 Permalink | Log in to Reply

      This is timely as we are planning the first Maine WordCamp this summer. Since it is all new to me, I am all ears. What can I do to help?

      • _Redd 5:31 pm on April 1, 2014 Permalink | Log in to Reply

        @andreamiddleton @jebswebs Absolutely awesome to have you here. Joe Dolson, and David A. Kennedy are drop-dead amazing, and you will find that is true of each and every other member of the Accessibility Team. As is true for Matt and the entire WordPress community; I’ve never met a better bunch.

        Do take David up on his offer to help. He, Joe, and the others have an amazing ability to put complicated topics in a clear, understandable manner that I personally find invaluable. Keep posting your requests; the experts will see that your questions get answered.

        Also, consider joining us in our weekly meetings on Wednesdays. Right now, they are at 1900 UTC.

    • David A. Kennedy 12:50 am on March 31, 2014 Permalink | Log in to Reply

      @andreamiddleton That’s great! And we’re glad to help! To supplement what Joe mentioned above, check out the accessibility guidelines for themes. That will be good for organizers to keep in mind as they work with themes and the content.

      I’m have a few side projects going right now that are keeping me busy, but would be happy to help wherever I can.

    • uklistingz 3:15 pm on April 5, 2014 Permalink | Log in to Reply

      I have used these themes infact whenever you install its there. I found twenty fourteen most useful and with much features. I did not find yet any accessibility issues. if i will i will definitely throw a message. thanks

  • Graham Armfield 5:46 pm on March 24, 2014 Permalink
    Tags: , , , , , ,   

    Digital Accessibility Centre Visit – Part 3: The Blind Perspective 

    This is the third post documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan BamberThe first post can be found here, and the second post here.

    Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

    In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.

    (More …)

    • ceo 6:19 pm on March 24, 2014 Permalink | Log in to Reply

      Looks like there’s lots to chat about. :-)

      It is important to let people know when a new panel or window is to open – eg Add Media.

      I’ve only been saying this for, well, ever. Though, to be fair, it was even worse before when these kinds of things popped up and you literally could navigate out of the window with the screen reader but still have it open. (At least, I don’t encounter the issue any more, personally. It might still be broken in some places.)

    • _Redd 8:09 pm on April 1, 2014 Permalink | Log in to Reply

      Graham, this is sheer gold. I hope we can chat about this in the next IRC meeting. Thanks again for everything you’ve done here.

  • Graham Armfield 2:40 pm on March 24, 2014 Permalink
    Tags: , colour contrast, , , text resize   

    Digital Accessibility Centre Visit – Part 2: Poor Vision 

    This is the second post (of three) documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan Bamber. The first post can be found here.

    Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

    In this post we take feedback from Gary who has poor vision.

    (More …)

  • Graham Armfield 11:48 am on March 24, 2014 Permalink
    Tags: , , , , voice recognition   

    Digital Accessibility Centre Visit – Part 1: Introduction, Keyboard and Dragon Testing 

    On February 25th 2014 I was honoured to visit the offices of the Digital Accessibility Centre in Neath, South Wales, UK. The trip was organised by fellow wpa11y team member Siobhan Bamber.

    This post is the first in a series of three which summarise the feedback we received on using WordPress from three users with impairments. Our first session was with Becs who uses Dragon NaturallySpeaking (voice recognition software) and does keyboard accessibility testing.


    (More …)

    • _Redd 5:58 pm on April 1, 2014 Permalink | Log in to Reply

      Graham, this is a drop-dead fantastic report. I have no doubt that there are many who will be grateful for the elegant manner in which you’ve described the problems, and made them visible to those who don’t use assistive technology.


      “In all cases, she felt strongly that tab order should follow what’s visible on the screen. She also felt it was confusing and not at all intuitive to have to reverse tab to reach the Add media button and the Change Permalink button in the Edit Post screen”.

      If you recall, I was confused for the same reason when conducting keyboard tests as to the reasoning behind tab order, but was only able to my confusion as frustration. It was said so much more elegantly here, in that tab order should follow what’s visible on screen. I fully agree. But I’m not sure the “skip links” may be coming into play here, and that actually, things were working the way they should have.

      It has become a real puzzle as to why one has to “reverse tab” in order to bring focus to the Add Media button, even though it is a link. At first I thought it was a FireFox problem, but I find it present on all three browsers, just testing for tab order—nothing to do with Dragon Naturally Speaking. But this is a consistent problem. At first I thought it might be because of the span class wp-media-buttons-icon, but other areas within the screen, with the same class, receive focus when they should. Perhaps, this too, should be another action item.

      At any rate, I am again overwhelmed at how awesome your insights are, and I think it is safe to say we are all grateful for what you do.

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