This week in WPA11y – June 27, 2017

WordCamp Europe

For discussions and plans see: Takeaways from Paris.

New structure handbook

We agreed on the following new structure: Per topic short explanations, then links to good articles and examples. The resources do not need to be WordPress specific.
We’ll need some method for ensuring the currency and accuracy of resources listed, if we’re going to list specific resources. So probably restrict the resources to the most authoritative ones. And we need to check the resources regularly.

Order of things:

  • make a list of topics
  • add an intro per topic
  • add resources to it

@samikeijonen and @rianrietveld will start with a spreadsheet gathering the topics, everyone can add possible resources to that later, so we can see what we can use for the handbook.

Test Gutenberg

Now Gutenberg is available as plugin we want to install it on our test server and give it to the test team this week. With a clear description on what it does and a link to the issues already reported on GitHub.

@arush already gave her review: Gutenberg With A Screen Reader: Initial Thoughts And Reactions

Adjustments Accessibility Coding Standards

@joedolson is working on a new draft, work in progress.

New Settings API

The plugin Settings API enhanced is now an almost complete prototype, but still needs refinements and design. It’s a prototype though, many things could change. We would like feedback from more people before moving on.

And what else happend

Next meetings

Next New Setting API meeting: July 3 ,2017 at 16:00 UTC in the Slack #core channel
Next WPa11y meeting: July 3, 2017 at 17:00 UTC in the Slack #accessibility channel.


Takeaways from Paris

So the community summit, the contributor day and WordCamp Europe happened in Paris. And this is what we learned from all the discussions we had during that warm week in June:

Education instead of taking over

The accessibility team must not try to do everything themselves. Like raise and solve all accessibility trac tickets themselves. What we should do is add to the tickets how they should be solved and let other developers do the patches (or ask them to do). Hopefully this will attract more developers to do accessibility tickets. That way the developers will learn instead of handover to us. Now the team is like a proxy, everything needs to go though us, slowing the process down. What we need to accomplish is that the developers solve the issues themselves, and we just help them if needed.


The handbook must be replaced by a list of resources, good examples and test tools, with short explanations. We don’t need to write everything ourselves, but make list of links with a short intro per subject. Focus on education and point to good info. In other words: help and educate the developers instead of fixing ourselves.

Testing and research

We need to ask more a11y experts from outside the WordPress community to assist us with the testing and research. For this we can reach out to companies specialised in accessibility, ask them if they can sponsor time to do research on WP core and featured projects.

So this defines 3 tasks for the a11y team

  • Teach: Provide easy to use overview of resources for developers
  • Research: Test and research current and new functionality for accessibility
  • Help: Review and raise accessibility tickets and provide developers with info on how to solve the issues

This doesn’t mean we won’t be working on tickets and issues on GitHub, we want to move our team focus to research, education and support.

This week in WPA11y – June 5, 2017

WordCamp Europe

Topics Community Summit (CS):

  • New developments for the the Editor, and how to safeguard it’s accessibility – (Core)
  • Technology version support policies – (Core)
  • How to involve more developers in helping with the accessibility tickets
  • How to proceed with the handbook
  • Addition: Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding standards

@joedolson will write up a draft for the updated coding standards, for us to discuss on the CS.

Contributor day:
All plans are in the Google Doc: List of goals for Contributors day in WCEU.
And the is also a list of a11y tickets to pick from.


After June 26th we will start testing again. For this patches and plugins will be installed on our test server and given to the test team.

To test:

Next meetings

There won’t be a meeting or bug scrub on June 12th (due to WordCamp Europe).



X posting Proposal WordPress Community Conduct Project

X-posting Proposal: WordPress Community Conduct Project
Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

This week in WPA11y – May 22, 2017


  • Tickets for 4.8
  • A11y Tasks tickets
  • Testing Gutenberg (and others?)
  • Tickets for Future Releases
  • WCEU Contributor’s day

In attendance:
Andrea Fercia @afercia
Sami Keijonen @samikeijonen
Joe Dolson @joedolson
Trisha Salas @trishasalas
…and others possibly lurking

Tickets for 4.8

  • tag cloud widget
  • custom logo alt attribute fallback

Both of these tickets are very close to commit.

@flixos90 dropped in during the meeting to say 38768 is done! 🎉

@afercia is currently fixing the tests for the custom logo alt attribute, thanks to @flixos90

A11y-task tickets

@afercia helped to define the a11y-task tickets for us.

To summarize:

  • A11y-task tickets are more related to a11y “topics”. (infinite scrolling, proximity, placeholders, CSS generated content, etc)
  • A11y-task tickets have an educational purpose 😀
  • A11y-task tickets are something we don’t have the resources to address right now, but something we should talk about with other people, to increase awareness.
  • A11y-task tickets are something to point people to when they ask about big a11y pending issues… hey look, there’s this Trac report you can have a look at.
  • A11y-task tickets are something that should be brought to other teams attention (Design Team, for example)
  • A11y-task tickets can be used as tracking tickets for separate smaller tickets.
Current A11y-Task Tickets


Everything needs to be tested, from the most basic text operation to the most complex interactions. For example: navigation in text with the keyboard, select text, select all, etc.

Installing the plugin is very easy if you already use VVV and are familiar with GitHub

See instructions for installing the plugin here:

The plugin is not complete yet, but feedback should be given as soon as possible.

As a reminder: today is May 22nd and the Gutenberg deadline for a first 1.0 version is the end of June, as far as I know.

There are already several issues open on GitHub with the `accessibility` label.

Discussion about tickets for Future Releases will be put on hold until we are more comfortable with the state of accessibility in Gutenberg.

WCEU Contributor Day

The WCEU Committee has requested that each team come up with a list of goals due by June 9th for contributor day.

@sami.keijonen asked how we should prioritize and organize tasks given that we will have 30-40 people in attendance.

@joedolson mentioned “Training is frequently the most valuable part of contributor days – just trying to get people better educated about a11y. Getting a patch done is nice, but getting 40 people to know a11y better has more long-term value. I’d suggest segmenting the group according to experience, and have different plans for groups with more or less experience.”

The plan is to do both workshops and training along with identifying some simple tickets to have ready.

Homework for the team is

  • Have a list of goals ready for next week (5/29/2017)
  • Identify some ‘good first bug’ accessibility tickets


State of WP Accessibility

The following is a post by Adam Soucie (@adamsoucie)

Yesterday was Global Accessibility Awareness Day! In celebration, the WordPress Accessibility Team (WPa11y) would like to present the State of WordPress Accessibility for 2017. The WPa11y is always working towards making WordPress more accessible. We have several active projects, and are currently planning larger goals for future WordPress releases. Here’s a breakdown of what we’re looking at for both the present and future of WordPress.

Current Projects

The WPa11y has several active projects, ranging from small changes that the average user wouldn’t notice like color contrast in the admin or removing title attributes to larger projects like making sure the new Gutenberg editor is as accessible as possible before launch.

Tag Cloud Widget

Andrea Fercia, Sami Keijonen, and David Kennedy are currently reworking the tag cloud widget, as it has several accessibility issues. The tag cloud project involves not only reworking the widget, but updating the bundled themes as well. Each theme handles the HTML output slightly differently, and the team is working on standardizing them. This project was born at the first WordCamp US (Philadelphia 2015) and hopes to see release in time for 4.8.1.

Enhanced Settings API Plugin

The Settings API could use some work, so Felix Arntz and Andrea Fercia have created a plugin that ties all of the patches together for easier testing. This enhanced version of the settings API improves on the default render callbacks and proves a more accessible layout. The plugin is available on GitHub and is ready to be tested.


For more on our current projects, review the April 5th meeting notes where we unveiled all of our current projects.

Future Plans

The future of accessibility in WordPress is bright, but filled with work. Just like the rest of WordPress. We have a few big targets including: media, the Customizer, themes management, menus, and plugin management.

A Media Rework

The WPa11y’s biggest future priority is a rework of the media system, particularly the Media Library. To be blunt, it’s a mess. It really needs to be rebuilt from the ground up with accessibility in mind, instead of having the team try to graft on accessibility to what’s already there. Because this will be such a labor-intensive project with input and assistance from nearly every group involved in contributing to WordPress, it will take months of planning to accomplish. Still, media is a vital part of WordPress and a vital part of the web experience in general. We’re committed to making it as accessible as possible for a future release.

The Customizer

Like the Media Library, the Customizer needs a lot of work. With the Customizer getting more and more focus, now is the time for the WPa11y to be making sure that future updates are accessible while improving what’s already there. It is clear that the Customizer is the future of WordPress. It needs to be accessible.

How You Can Help

Accessibility can be scary. It seems like a foreign, complex concept. It isn’t. Testing for accessibility is as simple as using your browser’s inspector to check font sizes and color values or using browser settings to make sure fonts resize. If you’d like to learn more and help contribute to making WordPress more accessible, join the WordPress Accessibility Team for our weekly Slack meetings at 1pm EST on Mondays. We’ll show you the ropes and have you up and contributing in no time!


If you’re a developer who already knows accessibility, even better. There’s a lot of code that needs to be written or refactored to make each of these projects an accessibility success, and you have an opportunity to impact a large part of the internet, from a user as well as a development perspective. You have the opportunity to create code other WordPress developers can and will learn from. The core WordPress Accessibility Team is very small, and the number who are developers is even smaller. Add to this that every one of us are further constrained by the amount of time we have available to devote to WordPress, and you have a recipe for glacially slow accessibility improvements.


To be sure, we’re not asking for all of your free time. But wouldn’t it be excellent if everyone who is a developer, already knows web accessibility, and uses WordPress either in their side projects or as part of their business contributed five percent of their working time, or code, back in order to make WordPress more accessible, faster? Right now, there are one hundred and thirty-four accessibility ready themes available for free in the WordPress theme repository, and reviews for the accessibility ready tag can take months, because there’s more demand for the tag than there is supply of reviewers. Imagine how many themes we could have for people to build accessible sites with if there were no cue?


Please consider contributing to the efforts of the WordPress Accessibility Team if you are able. If you’ve written accessible components for WordPress themes, consider contributing them to the WordPress Accessibility pattern library on GitHub. If you know of a translation of WCAG and its associated documents in a language other than English, send links our way so we can spread them around. And if you can help with any of the projects listed above, please do so.

#gaad, #global-accessibility-awareness-day

The Last 3 Weeks in WPa11y!

Accessibility Tickets in 4.8

These are the current accessibility related tickets slated for the 4.8 release:

  • #35566 removes the title attribute in the tag cloud widget
  • #38768 adds the site title as the alt attribute to the custom logo

WordPress 4.8 introduces a few new media widgets as well as the ‘Nearby Events’ widget. Testing should continue to be sure that new accessibility issues aren’t introduced.

Future Releases

If you would like to have an impact on future WordPress releases join us during our bug scrubs! During bug scrubs we go through the “awaiting review” and “future release” reports.
Gutenberg Editor

The Gutenberg Editor is slated for a big reveal at WordCamp Europe.
Let’s keep testing for accessibility related issues as development continues.

You can find installation instructions here:

Note that it is not a conventional plugin so there are some specific steps to follow.
Accessibility Tasks

There are several ongoing tasks with the goal to improve accessibility in the Admin area.

  • Proximity
  • Add widgets screen
  • Menu screen

Widgets and menu screen

It’s not a secret that there are many issues in the Add Widgets and Menu screens. What to do? @juliemoynat has suggested some improvements in this ticket:


In web design, the principle of proximity states that related items should be placed close together. By the same token, if things are spaced farther apart they appear to have less relation to one another.

This principle is so powerful, that it overrides similarity of color, shape, and other factors that might differentiate a group of objects.

Proximity is especially critical for users with low vision. It will even be addressed in the next draft of the WCAG guidelines!

An initial ticket has been created, feel free to join in!


Week in WPa11y – April 24, 2017

Topics of Discussion

  • Settings API project
  • Gutenberg editor plugin
  • Browser support changes
  • Screen reader text PR
  • Tickets
  • New Widgets to test

Settings API

The current approach involves a redesign of the settings pages that is being discussed with some members of the design team.

The next step is to process the thoughts @helen gave use on the CSS naming conventions. See:

Gutenberg Editor Plugin

@afercia recommended that we install and test the plugin. Instructions are here:

Note that it is not a conventional plugin so there are some specific steps to follow.

@afercia has submitted a few issues based on the mockups but real (a11y) testing has yet to start.

Changes in Browser support

We discussed how the browser support changes would impact the screen reader text PR. @sami.keijonen said we should not use our time so much of finding things to remove at this point. But test new things like settings API and editor and make changes as needed.

Screen reader text PR

@ffood submitted a PR to update the screen reader class in the A11y Theme Patterns repo in Github.

There was some discussion about updating the class in core as well.

We agreed to merge the PR and also open a new issue in core to modernize the class. The changes in core should take into account end of support for IE 8-9-10


Two tickets were closed this week.


There are 2 new widgets to test

Next meetings in Slack


X-post: Nearby WordPress Events

Hello! Looking for feedback:

Week in WPa11y, April 5 -11 2017

Results Editor survey

Editor Experience Survey Results

105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.

Some quotes from the survey questions about accessibility issues with the Editor:

You need to add more notifications for screen reader when somethings change on the page.

I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.

@mapk gave @afrecia a list of all the accessibility related answers for him to take a closer look at.

WordCamp Torino

Andrea: There were a variable number of 6-8 participants at the a11y table during the day. That’s a huge number for a11y during contributor days. Most of them were beginners so we’ve spent most of the time on introducing to accessibility. Run some keyboard accessibility testing, followed by an introduction to screen readers basic principles. In the last part of the day we’ve discussed all together #35497 – List tables: Post format links improvements.

Dana Donato (@danuccia) joined the WPa11y meeting in Slack after joining the contributors day in Torino. She wants to help with tickets.

Summary of the discussion during the Settings API meeting

Notes by @afrecia:

  • use more settings sections to group fields that belong together (note: sections that group logically related controls should be fieldset elements)
  • GitHub flow: use distinct branches for design/layout changes and Settings API improvements
  • planning new GH issues to open
  • CSS naming conventions: the general issues here are trying to establish easy and maintainable patterns, taking into considerations the CSS Roadmap
  • keep selectors specificity as low as possible, avoid overqualified selectors
  • @helen suggested selectors should also provide a context:
    • “In an ideal world, you would have some baseline stuff for elements themselves, and then you scope upward to apply specific stuff based on context as needed”.
    • “The goal should be for people (devs) to not have to do anything involving class names or CSS the vast majority of the time.”
  • @helen will try to start a doc to dump thoughts on the best option we have for CSS naming
  • CSS classes to target stuff in JS: they should be separate from classes used for styling
  • CSS classes for state naming for JS (e.g. .is-active or .is-dismissible)


Proposal for a new a11y-task ticket:  CSS generated content.

We’ve discussed a few times the issue about font icons or other characters generated with CSS ::before and ::after. In some cases, they can be announced by screen readers. At the moment, the only way to make sure they’re not announced is using a <span aria-hidden="true"> element and target that with ::before and ::after rather than the main element. We should progressively introduce this as a best practice and also make people aware of the problem.

Andrea will write the ticket and @trishasalas will do research on how CSS content is used in core.

Note: a11y-task tickets are issues that should be addressed but we don’t have time and resources to tackle right now. Starting a discussion about them would be valuable though.

Current work a11y team



  • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php
  • Settings API plugin

Both are also installed on our test server at

Interesting reads this week

Next meetings in Slack