Following a discussion that started a couple of weeks ago, the accessibility 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 would like feedback about the possibility of adding a new workflow keyword to Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. Both the original discussion when the proposal was brought up and the related discussion during the last weekly meeting can be found in the #accessibility channel in the Making WordPress Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (requires registration).
The problem: asking for accessibility feedback too early
It’s very common to add the Accessibility focus to Trac tickets related to new features, in particular those which introduce new interfaces: for example, all tickets related to the About page of the last few WordPress releases have had the Accessibility focus. This allows the accessibility team to check new interfaces early in design and development and to fix problems as soon as possible: this saves a lot of time and energy, so we highly recommend doing this whenever needed.
The issue is that sometimes the Accessibility focus is added “too early”: some tickets with no mockups or where new features still have to be designed or implemented have the Accessibility focus, but they pop up during bug-scrubs week after week even if the accessibility team doesn’t really have anything to review.
This problem becomes very evident when these tickets don’t have an owner, when they are not correctly milestoned (for example, they stay in the Awaiting Review queue), and in particular when the Accessibility Team is not the main driver of design or development of the new feature.
The (possible) solution: adding a new workflow keyword
One of the proposed solution is to add a new workflow keyword to identify these tickets, so that they can be excluded from bug-scrubs until “real” feedback is needed.
A few options for the new keyword were explored.
needs-accessibilityneeds-accessibility-testingneeds-uipending-ui
The first two options should be actively added when feedback from the accessibility team would be needed, but that would almost be identical to adding the Accessibility focus. Using one of the the last two options, instead, would probably be better: such a keyword could be added to mark tickets that can be ignored until they are moved forward.
The accessibility team didn’t express strong preference for one keyword or the other, but a keyword starting with needs- might be preferable for consistency with the other workflow keywords.
The proposed solution is especially important for the accessibility team, where interaction with other teams happens on a daily basis. In fact, the issue we are trying to solve can be more general: whenever a ticket has several focuses, but only one team is responsible of moving the ticket forward, the same situation can arise. If we’re able to find a more general keyword that fits all these similar situations, it might be useful for all teams and can have an even greater impact.
The new keyword, together with proper bug-scrubbing and moving tickets out of Awaiting Review as soon as possible, might improve the workflow not only for the accessibility team, but for the entire WordPress Community.
We would like to hear your feedback regarding this topic: you’re invited to leave a comment below and let us know what you think!
