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 …)

  • Jen Mylo 1:25 pm on September 8, 2014 Permalink | Log in to leave a Comment
    Tags: accessibility team meetup,   

    WCSF Tickets, Accessibility Team Meetup 

    Anyone planning to attend WCSF this year from the accessibility team, please read the post at http://make.wordpress.org/updates/2014/09/08/wcsf-tickets-and-stuff/ for information about WCSF ticket sales and the contributor days following the main conference. Please click the link and read that post *before* asking questions on this thread. :)

    If you are planning to attend the accessibility team meetup but I have not been in touch with you regarding hotels/travel dates, please ping me in IRC (jenmylo) or shoot me an email (same username @wordpress.org) so I can include you in the planning.


  • Joseph Karr O'Connor 6:08 am on August 30, 2014 Permalink
    Tags: , ,   

    Accessibility Team Update: August 27, 2014 

    Weekly Testing Meeting

    For the last two weeks we’ve been trying something new, a weekly accessibility testing meeting, 17:00 – 19:30 UTC. We meet in the wordpress-ui IRC channel to share our tests. If you want to join in or just see what we are doing just show up in the IRC channel. Read the logs for August 18 and August 25 to get an idea of what we are doing.

  • David A. Kennedy 7:47 pm on August 27, 2014 Permalink
    Tags: 4.0   

    WordPress 4.0 Release Candidate Testing 

    The first release candidate for WordPress 4.0 is out. If you’re interested in testing for accessibility, here’s what to focus on:

    New features in 4.0

    1. Oembed
    2. Insert from URL
    3. Plugin installation
    4. Editor scrolling
    5. Media Library Grid
    6. Customize Panels

    Regressions from 3.9

    We don’t have a definitive list for this, but keep an eye out for anything that’s not working that you know worked in the last version.

    If you run into bugs, follow the instructions from the WordPress.org announcement post:

    Think you’ve found a bug? Please post to the Alpha/Beta area in the support forums. If any known issues come up, you’ll be able to find them here.

    To test WordPress 4.0 RC1, try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”). Or you can download the release candidate here (zip). If you’d like to learn more about what’s new in WordPress 4.0, visit the awesome About screen in your dashboard ( → About in the toolbar).

    Things to Watch

    We want to keep things simple at this point. Look for any big blockers, like:

    • keyboard traps
    • confusing or non-existent tab order
    • content that can’t be accessed via keyboard
    • content that can’t be accessed via screen reader
  • Rian Rietveld 4:35 pm on August 27, 2014 Permalink  

    Weekly accessibility test session on Monday 

    Last couple of weeks members of the MWA team organized joint test sessions on Skype and IRC #wordpress-ui. We had a mixed team of users and coders, all with different experience with assistive technology (AT).

    We installed the trunk version of WordPress on a server everyone could access and discussed tickets, tested the accessibility of patches and of core functionality.

    The combination Skype (voice) and IRC worked well. On Skype we could quickly discuss what to test and what the problems where and on the IRC developers could join in. So this turned out to be a productive way of working.

    In the first session patches for ticket #28823 Plugin details screen is not given focus where tested. @ocean90 joined the conversation discussing a solution with @bramd. @ocean90 came up with a new patch. We tested that on different browsers and AT.  The patch worked. @ocean90 committed the patch and closed the ticket.

    During the second session we tested patches for the Add Media and Media Library functionality with screen readers and keyboard only. We were puzzled by the navigation with a keyboard in a logical way trough all the options. For example, how do you select two images using only a keyboard.  The relevant patch for ticket #29326 Improve accessibility of edit-selection mode, was tested and discussed with @adamsilverstein.
    As a result of this discussion @bramd opened a new ticket #29371 Media Library: Focus keeps jumping to URL field.

    We plan to continue these accessibility test sessions every Monday from 17:00 – 19:30 UTC  in IRC #wordpress-ui. Anyone wanting to join in on IRC and Skype is very welcome. Just contact @rianrietveld or @arush on Mondays in IRC.

  • Joe Dolson 8:58 pm on July 21, 2014 Permalink  

    Prioritization: Accessibility Tickets for WP 4.0 

    This is a list of current tickets with the accessibility focus in WordPress 4.0. So that we can get the most important issues done earlier, allowing for better iteration and testing, I’m prioritizing the tickets according to severity.

    Please don’t read this in any way as a listing of importance: all of these issues are important, but some issues have a greater impact and/or require more testing to make sure they’re done right, and these issues are getting higher priority.

    Group 1:

    These issues may prevent a user with disabilities from installing or using WordPress

    New in 4.0:

    1. #28858 New installation: Language Selector

    This should get very high priority, as this feature will be a new user’s first introduction to WordPress, and will set the tone for all further experiences.

    Group 2:

    These issues may prevent a user with disabilities from using a specific feature in WordPress.

    New in 4.0:

    1. #28822 Media Grid: Focus doesn’t change when tabbing through selected items
    2. #28857 Media Grid: Manage focus when toggling between the grid and an edit attachment modal
    3. #28892 Customizer – Widgets – Feedback for screen reader users when Moving widgets + other actions
    4. #28888 Customizer – Widgets – Screen Readers Don’t Announce Widget Names
    5. #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header

    Add Media Experience:

    1. #23560 Keyboard Accessibility of Add Media Panel
    2. #28209 Links inside help tabs (help-tab-content) are not keyboard accessible
    3. #25103 Submit buttons on form fields in the Add Media panel
    4. #23562 Using Speech Recognition Software with the Add Media Panel
    5. #28864 Cannot access edit menu options with keyboard inside Image Editor

    The Add Media panel and related experiences are a huge part of the day-to-day interaction with WordPress, so these should also get high priority.


    1. #27642 Keyboard Accessibility for TinyMCE image panel
    2. #27553 Make WP editor toggle focusable


    1. #20880 Keyboard navigation in Appearance > Header is broken


    1. #27592 Screen Reader Users Do Not Know Widgets are Expandable
    2. #27593 Widgets: Toggle arrows on focus need an indicator beside color alone


    1. #27555 Make tag post meta box more accessible
    2. #26600 Search installed themes input has no submit button
    3. #26550 Some anchor links should be buttons in media microtemplates
    4. #18801 Accessibility Enhancements to Settings API

    Group 3:

    These issue impact front-end user experience, and have enormous impact on the visitors to sites built with WordPress.

    1. #15926 Give header and background images alt tags
    2. #24148 Add aria-labelledby attributes to comment form
    3. #21221 Image title and alt attribute content should be texturized.
    4. #27402 Add aria-describedby to image gallery output
    5. #27645 MediaElement.js player & playlist not keyboard accessible
    6. #16433 Extend function to optionally include commenter name in comment_reply_link
    7. #18650 Make archives and categories widgets dropdown ada compliant

    Group 4:

    These issues should not generally prevent a user from using a feature, but will make it more difficult to use.

    1. #28976 Add Media Panel: Announce context of close button for screen readers
    2. #28867 Correctly label forms in wp_list_table
    3. #26552 Remove title attributes: default-widgets.php
    4. #26758 Edit Tags form on submission does not stay at the same page and gets redirected
    5. #28873 JavaScript code for adding bookmarklet Press This is hard to access with keyboard only
    6. #25111 Keyboard focus does not stay within Full Screen Editor modal
    7. #26562 Remove title attributes: class-wp-admin-bar.php
    8. #26504 Semantic elements for non-link links
    9. #27609 change ‘<code>’ to ‘<pre>’ in wp-includes/comment-template.php
    10. #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
    11. #26601 Inappropriate content in heading on Themes page
    12. #26551 Remove title attributes: link-template.php
    13. #26560 Remove title attributes: rss.php
  • Joseph Karr O'Connor 6:02 pm on July 11, 2014 Permalink  

    Accessibility Team Update: July 9, 2014 

    WordPress 4.0 Beta 1

    In our meeting this week, Sam Sidler gave us the heads-up that 4.0 Beta 1 was about to be released and told us that it is “incredibly important that you test it and all of its new features.” In her post WordPress 4.0 Beta 1, Helen Hou-Sandi announces the release and talks about new features.


    This Saturday, July 12, some of us will be testing 4.0 Beta 1 for accessibility and other issues. If you want to get involved the start time is 15:00 UTC. Log in to the #wordpress-ui IRC channel. Also refer back to and update this page for information about what has been tested and what needs to be tested.

    Test Environment

    Remember, we’re testing 4.0 Beta 1 so you’ll need an installation of WordPress with the WordPress Beta Tester plugin set to download and install “bleeding edge nightlies.” You don’t want to do this on your live site, so use a tool like DesktopServer by ServerPress to create a virtual server on your desktop computer.

  • Joseph Karr O'Connor 6:41 pm on June 25, 2014 Permalink  

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

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