a11y update week 34 2016

Summary team meeting WPa11y team, August 23

Focus for WP 4.7

@davidakennedy suggested: “Since new user experience will be a focus: maybe there’s a11y items we can improve related to that? First-time installs, theme activation, etc.”. And we agreed that this is a good idea.

Some suggestions that came up:

  • let the test team do the famous 5-minute install with different AT
  • focus exclusively on the experience with default themes
  • plugins: only install, active, deactivate, remove
  • check for and address any existing problems
  • see whether there are any major changes proposed for WP 4.7 and test those
  • hashtag #a11y-firstinstall for tickets

@trishasales and @rianrietveld have time for this.

Theme reviews

@joedolson completed a couple reviews in the last two weeks. Robert Jolly (@iamjolly) is joining Joe and David in reviewing themes for the accessibility-ready tag.


Robert Jolly is also going to help Trisha and Rachel Vasquez (@rachievee) with a high level overview and some Project Management for the handbook. The goal is to reinstate the hierarchy that started at WordCamp US and build/modify as needed. There will be a Google hangout next Thursday to get this started.

Open floor

Joe brought up the following:

“We have a list of accessibility related plugins. These are not all of the accessibility-related plugins in the repository. Some plugins are not helping accessibility and a few are even harmful. Do we, or should we have a specific policy governing which plugins we’ll list there?”

We agreed on not having an official certification/approval system for plugins like we have for the accessibility-ready themes.
Joe, Robert and Rian are going to look at the plugins tagged for accessibility and investigate if there are plugins that claim to improve a11y but are actually harmful or doing things that are really not beneficial.
Also we can extent the list with plugins on Useful Tools we think are good.

Bug scrub

This week there was no bug scrub, someone needed a holiday…

And other news that came by during this week

  • Modern Tribe is now sponsoring time for Trisha Sales to spend on work for the accessibility team.
  • Rachel Carden (@bamadesigner) published a nice plugin wa11y , for testing a website for accessibility with e.g. WAVE and Tota11y.
  • @michael.heuberger is working on a plugin using JavaScript to integrate a video in a form submission. This way deaf users can submit their response in sign language.


WP a11y update week 31 2016

Summary team meeting WPa11y team, August 1

Team meeting in Slack.

Retrospective and looking ahead

In @afercia’s words: Since the release cycle is now in RC time this would probably be a perfect time to think at the past months activities, what went well, what could be improved, do you feel there’s anything that makes contributing difficult for you, is there anything you feel it should be done differently? Maybe also start thinking at (realistic) plans for the next release cycle and check time and resources availability for the next months. Maybe we could introduce this kind of “retrospectives questions” after each release cycle.

What went well?

  • We’re alive, more or less in good shape, we improved a bit accessibility on WordPress
  • Having a focus each release went well, like heading structure, colour, title attribute
  • Introducing the bug scrubs – even if it doesn’t directly fix tickets it does bring order to the madness
  • Attending and speaking at WordCamps was useful
  • Accessibility tables and workshops on contributor days at WordCamps

And from our sponsors:
WP Site Care sponsored Andrea and Rian to go to the community summit and WCUS15. Yoast sponsors 25% of Andrea’s time to do a11y core work. And (spoiler alert) Rian will be sponsored too for 25% as from mid August.

What can be improved on

  • We don’t have time resources, people, and skills to start managing accessibility projects. We work on the existing issues but need to start thinking at bigger plans. Patching and patching is someway expected in a so large project with outstanding accessibility issues, at the same time it would be great to start bigger projects.
  • Accessibility is not part of new features since the initial development steps, but something added at a later stage

Do you feel there’s anything that makes contributing difficult for you?

  • Everyone: lack of time
  • Some of the new features, like Shiny Updates and Twenty Sixteen and Fields API, were initially developed on GitHub, that makes things more difficult to follow different things on different places
  • The difficulty of monitoring accessibility is that it involves every part of core development. Maybe we need to focus on training the developers, and not in fixing stuf ourselves.
  • A couple more coders would help too
  • The lack of proper screen reader accessibility of Slack makes it difficult for @arush to contribute.
  • There are accessibility issues on the form to create new tickets and to comment on tickets in Trac, which makes it difficult for people using assistive technology to contribute.

Plans and ideas

  • Spend more time on WPa11y core work and documentation
  • Focus on education developers and designers
  • Training for theme reviews accessibility-ready tag
  • Extend and improve the pattern library
  • Give more workshops on WordCamps
  • Do more a11y audits on core, with recommendations to fix (and not fix ourselves)
  • A monthly or quarterly or whatever worldwide a11y contributor day, like the translation day, use also the global a11y awareness day
  • A11y audit on the Trac templates
  • Involve more assistive technologies users on trac, but before that the Trac issues must be solved
  • Start a featured project (the Media maybe?)

Open floor

Maybe we need a statement on Make/Accessibility that the accessibility team is independent and not connected to any company for assistive technology or test software. This to prevent to be claimed by companies for our voluntarily work on open source.

Bug scrub, August 1

We discussed tickets labeled accessibility and with status awaiting review.

Bugscrub in Slack.

#37513: Admin bar sub menu items dashicon and screen readers and
#37511: Dashboard activity widget: hide the “No activity yet” smiley from assistive technologies
Screen readers behave differently with CSS generated content, for example VoiceOver gets CSS generated content icons as “text” element. The W3C spec says is that something is probably going to change in the next future and CSS generated content, including dashicons, will be probably announced as content by assistive technologies. We should monitor this as a general issue for all the CSS generated content used in WordPress.
Set both tickets to 4.7-early

#37486: Make emojis accessible
Andrea opened this ticket mainly to start a discussion about Emojis. This needs research, Rian will have a go on this.
Set to Future release.

#36925: Media views: introduce a “Heading” view for better accessibility
Set to future release, there is already good work in progress for this ticket.

#36474: Revamp meta boxes
A ticket for the UI/design team to handle, the label accessibility is only added to keep informed about relevant UI changes.

#36447: Responsive preview icons in Customizer need tooltips
We agreed that tooltips are necessary. Best = Icon + text and Second best = Icon + aria-label/tooltip. Good example is GitHub handles the icons with aria-label and tooltips. @arush mentioned grease monkey script  to help those who aren’t power users deal with them on the NVaccess Github
Set to Future Release and assigned @iamjolly as owner

And other news that came by during this week

Josh Pollock, the plugin author of Caldera Forms, started working on fixing accessibility issues in his plugin. You can follow his progress for Caldera Forms in GitHub. Feedback is welcome.

#accessibility-team-meetup, #bug-scrub