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: https://github.com/wpaccessibility/settings-api-enhanced/issues/6#issuecomment-294011891

Gutenberg Editor Plugin


@afercia recommended that we install and test the plugin. Instructions are here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

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: https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/

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

Interesting reads this week

Next meetings in Slack

Week in WPa11y, March 29 – April 4 2017

New keyword a11y-task

@afercia created a new tickets keyword a11y-task. These tickets aim to start a discussion and spread awareness about a11y issues that maybe can’t be resolved so soon. It’s also a way of being able to find accessibility tasks that we aren’t actively working on.

Current work a11y team

Gutenberg: as soon as the featured plugin is released we will test it.

Tag Cloud adjustments (tag-cloud): #35566 #40187 #40186 #40184 #40138
@samikeijonen and @davidakennedy

Settings API plugin: @flixos90
Felix released the plugin on GitHub: https://github.com/wpaccessibility/settings-api-enhanced which at the moment does exactly the same as the latest patches on #39441
We can work on this plugin to iterate to the one-column layout we aim to have for admin forms.
The advantages of developing in GitHub are:

  • Users can easily test the latest changes without us being required to do extra work.
  • Better diffs (because of individual commits) so that we can easier see what has changed over the last “patch”.
  • Easier collaboration (more people are familiar with git).

Once we get to a first version of the one-column layout that is ready for testing, we should consider also adding the plugin to the wordpress.org plugin repo and formally announcing it as a feature project. This will allow us to hopefully get more voices on the honestly quite drastic changes and also to ask for user testing.

Colour contrast in the Admin: @adamsoucie

Required fields @rianrietveld

Non-link links: @cheffheid

Remove title attribute in the Admin: any volunteer

To be worked on later

Test requests (keyword a11y-feedback)


Test the patches for

  • #35497: List tables: Post format links improvements
  • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php

Test the plugin Settings API Enhanced

Interesting reads this week

Next meetings in the Slack #accessibility channel