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