WordPress Accessibility Meeting Notes for 20 Sept 2019

Meeting transcript on Slack

Open Floor

There was no set agenda for this meeting.

The meeting opened with a discussion of ticket #30180. The ticket, while not of itself a crucial task, was a kicking off point for a deeper conversation about trying to work more effectively across teams.

This was a complicated conversation, so in this summary I aim to do my best to convey the essence of the conversation, primarily focusing on the experience from within the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team. For a detailed picture, please read the meeting transcript.

The overall point was the difficulty the accessibility team in specific – and all teams in general – have had in making progress on tasks that fall across other team’s responsibilities. This is particularly difficult in the more specialized areas of code, such as the Media Library, where specific knowledge of the inner workings are more rare.

The problem we would like to solve is, at root, the challenge of balancing goals with labor in a realistic manner. We, as a team, have very limited time that can be committed to any given task as well as having expertise primarily in accessibility, which may not benefit us mechanically when working in a specific idiosyncratic technology. To help meet goals, we have tried to work with other teams to delegate responsibility on tickets to people with more specialized experience, while remaining available to consult on the results.

The experience we have had with this has been poor, leaving us feeling that our only ability to accomplish goals is the technical tasks we have the bandwidth to complete ourselves. While many people do step forward and help, this doesn’t result in an overall feeling of forward momentum.

Among the challenges shared are the fact that many contributors to the project cannot plan their time effectively due to the lack of a structure release schedule. While employees of a company will have their hours structured such that they can dedicate the necessary time to a project after that project is scheduled, voluntary contributors inevitably have other responsibilities and commitments. Short notice of a release schedule does not allow those contributors to arrange their availability such that they can contribute in a healthy manner.

The meeting discussed four separate major challenges:

  1. Meeting specific goals for the accessibility tickets planned for WordPress 5.3.
  2. Communicate more effectively across teams.
  3. Component maintainence priorities.
  4. Release scheduling and the budgeting of goals over time.

It is important to us, as a team, to state that this is a problem we see throughout the WordPress project, and is not unique to this release or to our team. We don’t feel that these problems reflect individual failures; it’s the result of a systematic failure stemming from a lack of collaborative processes and insufficient opportunity to plan during the times between releases.

Better long-term planning and better release schedule pre-planning to set goals and define the capabilities across teams would be a critical step in making each team be more capable of meeting their individual goals.

The Accessibility Team would like to continue to move forward to work across teams to make this a better experience. We’re continuing to explore ways to improve the process through cross-team collaborations and shared meetings, and hope that we can all collaborate more effectively with improved processes.