These are the weekly notes for 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 meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.
Review of the team activity for WordPress 5.5 Beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 release
As first topic of the meeting, we reviewed the team activity for WordPress 5.5 Beta 1 release and looked for possible improvements to the workflow, in particular regarding tickets and issues shared with other teams.
There are a few remaining tickets in the 5.5 milestone with the accessibility focus keyword: specifically, they are tickets #49715, #50512 and #50416. Moreover, the team is in charge of writing a few dev notes.
It was pointed out that cross-team collaboration and co-dependancies are slowing the progress of the software in general and not only for accessibility related tickets, so a discussion about possible improvements should probably happen on a higher level and in a broader context.
For what concerns specifically the accessibility team, there was a very rich discussion with many proposals on how to improve the team work. Here is a list of takaways from the discussion.
- For tickets shared with other teams (especially with the design team), contributors to the accessibility team should be bolder and propose changes, instead of waiting for feedback and only reacting to changes proposed by other teams.
- To better track blocking issues, it was suggested to add a
blocked-by keyword/label, so that it’s easier to generate lists of issues that are currently blocking other issues and that the team can triage them more effectively. - The team should start to focus on bigger projects, instead of mainly fixing small bug. Given the limited number of contributors and the constantly changing available time and level of commitment of single team members, the team agreed to make a broader use of the
good-first-bug keyword for easier and self-contained tickets, so that more new contributors can possibly solve them. The team will organize a formal pre-alpha triage session happening around RC1 or RC2 (RC A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. stands for Release Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.) to identify such tickets at the beginning of the release development cycle. If tickets with the good-first-bug keyword are still unfixed after four months, they get slated for the next release they’re eligible for.
The most complex aspect to address as a team is following Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ development. At the moment, team members don’t have enough time to trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. both WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Gutenberg and have the feeling that they are constantly too far behind to be able to participate effectively.
@joedolson proposed to create two subcommittees within the team, one focused on WordPress core and the other focused on Gutenberg. During weekly meetings, both subcommittees will share what they’ve focused in the previous week and can ask for advice on selected issues. This way, each individual team member will be responsible for tracking only one system. At the moment, the accessibility team probably doesn’t have enough people to do that effectively, but such proposal will be discussed during one of the next meeting.
Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. movers and “Transform to” button in Gutenberg
Second item in the agenda was a follow-up to last week’s discussion on the Gutenberg issue about recent changes to the block movers and the “Transform to” button and a discussion about the related Gutenberg issue to improve the usability of the parent block selector button.
First, the team made a quick summary of issues that were already pointed out during last week’s meeting:
- small size of mover controls (while the target area was increased in the latest iteration, the buttons are still too tiny, especially for people with motor impairments, or for people with low vision and using larger-than-standard pointers);
- different size of movers on mobile and desktop;
- movers button are wrapped inside the control surface used for drag-and-drop and get a draggable cursor (but there’s an open pull request to remove the drag cursor about this);
- caret icon is used in the same context with two different meaning (moving blocks and opening dropdown menus).
Since during last week’s meeting the team agreed to consider the new interface as an accessibility regression and given that the new interface will be included in WordPress 5.5, the discussion focused on the following points:
- what it would take from the accessibility point of view to consider the issues resolved;
- whether the team should push for a revert or not;
- if yes, what should be reverted;
- how to get the reversion.
The accessibility team agreed that, at the very least, controls for moving the block and changing the block type should be separate and possibly all other new issues should be solved in time to be shipped with 5.5 (e.g. buttons size is not a new issue).
As is, the new interface should be reverted, unless the above points are addressed. In case the solution to pointed out issues can be reached by small improvements, the team is OK with shipping the new interface with WordPress 5.5; but in case of major changes (especially from the design point of view) the team strongly suggests to take more time and make the interface better: it would be very bad if a new version of the toolbar is released, only to release another new version of the toolbar in WordPress 5.6.
The scope of reverting should be considered carefully, since changes to the movers are part a bigger Gutenberg issue about advancing the block interface and they were decided in the first place because of other interface interferences.
Regarding how to get the reversion, all above points will be added to the Gutenberg issue and, in case, a Trac ticket will be created.
aria-label removal from links opening in new tab in Gutenberg
The third item in the agenda, about the Gutenberg pull request that removed aria-labels for links opening in new tabs, could not be discussed because of lack of time: this item will be moved to one of the next meetings.
Open floor
For open floor, @ryokuhi informed the team that he had a quick chat with @alexstine about documenting accessibility features in Gutenberg. He asked if someone can help to put down a list of these features, so that he can test them, give feedback and draft some documentation. If anyone is interested in volunteering for this task, they can leave a comment to the meeting notes.
#meeting-notes
