This week in WordPress Accessibility, May 4th, 2018

Bug scrub

We discussed issues marked for the Gutenberg merge proposal milestone:

Simplify and streamline keyboard navigation through blocks:
First: what if the block toolbar had only one tab stop and navigating through its controls would be possible with the arrow keys? Would users be able to get it?
Interaction modal: ARIA toolbar example
Conclusion: we are going to try this and let it test by some advanced keyboard / screen reader / VIM users

Second: the tab order
A good tab order would be for example: insert block, then editable area and then the rest. But should the visual order meet match DOM order? @afercia will try to investigate on the first two things in the next days

Constrain tabbing within popovers and similar components:
Alexander Botteram is working on a modal component that introduces a re-usable “constrain tabbing” feature.

Publishing Flow accessibility:
Nic Bertino did research on this and created a design proposal, that needs following up by the design and develop team.

Weekly meeting


We added new pages added about Test for web accessibility to the handbook’s Best Practices chapter. If there are people who want to review what is published, please do.

Sami Keijonen tweeted posts from the handbook in a series on Twitter. Nobody uses Facebook in the team, so we won’t start a Facebook campagne.


Summarised: Minor fixes went in, the bigger issues are still to solve.

We need to write a manual for AT users. We need people who are familiar with Gutenberg to be involved in writing the manual for AT users of Gutenberg. We can start outlining the processes and AT combinations to be documented. Rian will investigate what the best place is to publish this manual. Rian and Sami want to help writing.

We will dedicate our weekly bugscrub now on Gutenberg for now

We need to contact someone from Dragon about issue raised by Eric Wright: Can’t add a post title using speech recognition software.

Open Floor

Nicolas Steenhout has a podcast: A11y Rules. He’d love to speak to people that are NEW to accessibility, either working full time in it, or developers that are exploring #a11y.

So, if you think that’s you, please contact him, always nice to hear new voices


  • Write ATAG statement: Joe Dolson
  • Write about what WCAG 2.1 means for the WordPress project: Rian
  • Find the best place for the Gutenberg AT handbook: Rian




WordPress Accessibility Ticket priorities for 4.1 early

WordPress 4.1 development is just started. From an accessibility perspective, this means that we know almost nothing about what new features and UI changes will be taking place, but it gives us a great opportunity to work on resolving older outstanding issues or addressing concerns arising out of version 4.0.

This is a grouping of the tickets currently in the Accessibility Focus report; no new tickets were opened for the purpose of this list.

One general recurring topic in these tickets is the handling of focus in modals. This is something that could stand some global work: all WordPress modals should be initiated and closed in a standardized way: focus should be assigned to the first focusable item in the modal when it’s opened, focus should be restricted to within the modal while it’s open, and the modal should be closable using ‘Esc’. A thorough review of all modals would be valuable.

Group 1:

These tickets have an impact on the front-end use of WordPress. They are very unlikely to be relevant to any new features in development for 4.1, but are longstanding issues and improvements. Because they alter front-end code, they may require more time in trunk to address impact on plugins or themes.

  1. #15926 Add alt attribute support for Custom Header functionality
  2. #24148 Add aria-labelledby attributes to comment form (fixed)
  3. #21221 Image title and alt attribute content should be texturized.
  4. #27402 Add aria-describedby to image gallery output (fixed)
  5. JS #27645 MediaElement.js player & playlist not keyboard accessible (see Issue 1262 and Pull 1090 on MediaElement for reference)
  6. #16433 Extend function to optionally include commenter name in comment_reply_link
  7. #18650 Make archives and categories widgets dropdown ada compliant (depends on #29699)

#18650 is a particularly long-standing issue which has significant challenges due to the way the front-end HTML would need to change to make the feature accessible. Other features should all be able to be addressed without any major front-end impact.

Group 2:

These are areas that received a lot of attention in 4.0, but have outstanding issues. #26167 doesn’t directly relate to the plug-in work done in 4.0, but would be a good area to get resolved. It should be an easy fix.

  1. JS #28892 Customizer – Widgets – Feedback for screen reader users when Moving widgets + other actions
  2. JS #28888 Customizer – Widgets – Screen Readers Don’t Announce Widget Names
  3. #20880 Keyboard navigation in Appearance > Header is broken
  4. #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header
  5. JS #29371 Media Library: Focus keeps jumping to URL field
  6. JS #29455 Plugin Info Modal Close Button Does Not Announce for Screen Readers
  7. JS #29326 Improve accessibility of edit-selection mode

Group 3:

General issues relating to the author experiences, that can impact a user’s ability to author content.

Add Media Experience:

  1. JS #25103 Submit buttons on form fields in the Add Media panel
  2. JS #23562 Using Speech Recognition Software with the Add Media Panel
  3. JS #28864 Cannot access edit menu options with keyboard inside Image Editor


  1. JS #29838 Post editing area: keyboard accessibility, tab order and focus
  2. JS #27642 Keyboard Accessibility for TinyMCE image panel
  3. #27553 Make WP editor toggle focusable
  4. #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
  5. #29358 Remove the ‘accesskey` attributes from Quicktags buttons


  1. JS #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

Group 4:

Administrator/Designer experience:

These issues will effect a smaller number of users on fewer occasions because they primarily effect issues related to site set up and configuration. #18801 could really stand some major work; the settings pages in WordPress have a large number of miscellaneous accessibility issues, but I think that the ticket is too all-encompassing as is; we need to open some individual tickets handling specific issues in the settings pages or in the API, so that the issue is more readily addressed.

  1. JS #27592 Screen Reader Users Do Not Know Widgets are Expandable
  2. #27593 Widgets: Toggle arrows on focus need an indicator beside color alone
  3. #18801 Accessibility Enhancements to Settings API

These are issues that make features more difficult to use, but don’t prevent the usage of the feature.

  1. #26758 Edit Tags form on submission does not stay at the same page and gets redirected
  2. #28873 JavaScript code for adding bookmarklet Press This is hard to access with keyboard only
  3. #25111 Keyboard focus does not stay within Full Screen Editor modal
  4. #26562 Remove title attributes: class-wp-admin-bar.php
  5. CSS/HTML #26504 Semantic elements for non-link links
  6. JS #26601 Inappropriate content in heading on Themes page
  7. #26551 Remove title attributes: link-template.php
  8. #26560 Remove title attributes: rss.php

Group 5:

These are tickets we recommend for closure.

  1. #29475 Adding ARIA roles in wp_nav_menu
  2. #26553 Remove title attributes: comment-template.php

#4-1, #a11y, #tickets

Patches provided for #25459 – Meaningful links in Admin

I’ve added two patches to trac ticket #25459 which solve the meaningful links issue. They use a new function which employs the aria-hidden attribute to allow meaningful text for screen readers to sit alongside shorter text for sighted users, and allows both strings to be translated with correct grammar/spelling in all languages.

They work for me, but it would be great if someone else could test them on their own environment with a screen reader to double check. Maybe we could get this into 3.8.

#a11y, #accessibility, #aria-hidden, #i18n, #trac-2

Potentially useful accessibility plug in I learned about…

Potentially useful accessibility plug-in I learned about today at WordCamp Chicago:

#a11y, #alt, #images, #media, #plugins-2

Just submitted http core trac wordpress org ticket…

Just submitted: Comments welcome.

#a11y, #comment-form, #patch