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.
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
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.
These issues may prevent a user with disabilities from installing or using WordPress
New in 4.0:
- #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.
These issues may prevent a user with disabilities from using a specific feature in WordPress.
New in 4.0:
- #28822 Media Grid: Focus doesn’t change when tabbing through selected items
- #28857 Media Grid: Manage focus when toggling between the grid and an edit attachment modal
- #28892 Customizer – Widgets – Feedback for screen reader users when Moving widgets + other actions
- #28888 Customizer – Widgets – Screen Readers Don’t Announce Widget Names
- #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header
Add Media Experience:
- #23560 Keyboard Accessibility of Add Media Panel
- #28209 Links inside help tabs (help-tab-content) are not keyboard accessible
- #25103 Submit buttons on form fields in the Add Media panel
- #23562 Using Speech Recognition Software with the Add Media Panel
- #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.
- #20880 Keyboard navigation in Appearance > Header is broken
- #27592 Screen Reader Users Do Not Know Widgets are Expandable
- #27593 Widgets: Toggle arrows on focus need an indicator beside color alone
- #27555 Make tag post meta box more accessible
- #26600 Search installed themes input has no submit button
- #26550 Some anchor links should be buttons in media microtemplates
- #18801 Accessibility Enhancements to Settings API
These issue impact front-end user experience, and have enormous impact on the visitors to sites built with WordPress.
- #15926 Give header and background images alt tags
- #24148 Add aria-labelledby attributes to comment form
- #21221 Image title and alt attribute content should be texturized.
- #27402 Add aria-describedby to image gallery output
- #27645 MediaElement.js player & playlist not keyboard accessible
- #16433 Extend function to optionally include commenter name in comment_reply_link
- #18650 Make archives and categories widgets dropdown ada compliant
These issues should not generally prevent a user from using a feature, but will make it more difficult to use.
- #28976 Add Media Panel: Announce context of close button for screen readers
- #28867 Correctly label forms in wp_list_table
- #26552 Remove title attributes: default-widgets.php
- #26758 Edit Tags form on submission does not stay at the same page and gets redirected
- #25111 Keyboard focus does not stay within Full Screen Editor modal
- #26562 Remove title attributes: class-wp-admin-bar.php
- #26504 Semantic elements for non-link links
- #27609 change ‘<code>’ to ‘<pre>’ in wp-includes/comment-template.php
- #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
- #26601 Inappropriate content in heading on Themes page
- #26551 Remove title attributes: link-template.php
- #26560 Remove title attributes: rss.php
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.
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.
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.
To go along with the
accessibility-readyguidelines, 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!
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.
Visual Focus In Left Navigation
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)
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!
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!
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!
New Accessible Theme
“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.”
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.
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.