Accessibility Team Meeting notes: March 1, 2019

Health Check pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party a11yAccessibility 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)

@clorith shared the Health Check plugin with the team for review
Some 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) issues have already been identified, but there do not appear to be fundamental problems with the plugin
@audrasjb noted that there are still some graphics and user interface contributions to come, so accessibility review will need to take these into account
The plugin is targeted for 5.2; 5.2 betaBeta 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 is scheduled for March 14, 2019 (two weeks from now)
@joedolson suggested that the team should be able to form an opinion as to whether the plugin is ready for merge at that time
Team members are encouraged to review the plugin on GitHub and provide accessibility feedback

@joedolson was in contact with @chanthaboune; @dryanpress had been occupied with running WC Phoenix, but is now back to work on the User Handbook
More news to come in the near future!

@greatislander has been in touch with the Javascript team about the timeline for publishing the NPM packages required to run front-end accessibility tests against themes; pending a review of the package release process, they should be published soon
Once this happens, @greatislander will work on an post and documentation for adding the accessibility testing framework to any theme, which @joedolson suggested could be cross-posted on Theme Review
There’s also the possibility of adding the accessibility testing framework to wp-cliWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/’s scaffold command, as per @joemcgill‘s GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue: https://github.com/wp-cli/scaffold-command/issues/193

The team has held several bug triages over the last week, totalling 5 hours, to identify priorities for Gutenberg
The team produced a triaged list of 55 items; there’s a tab for 5.2 and 5.3 so that issues that don’t make it for 5.2 consideration, or more complex issues which can’t be addressed in time, can be assigned to 5.3
@joedolson proposed additional triage and the assignment of responsibility for various issues, with the understanding that responsibility for an issue is not necessarily doing the work, but shepherding the process
@karmatosed asked that further triage sessions be announced ahead of time so that they can be shared with the Gutenberg team; this could help get more people working on Gutenberg activated on accessibility issues; @afercia also noted that this will help address the issues as many require some development expertise
@afercia will try to coordinate another round of triage, with sensitivity to the two-week window before 5.2 beta 1; @joedolson suggested prioritizing issues that affect content output and focus management, considering whether issues have pull requests already, and trying to address issues with smaller size to get them out of the way
The spreadsheet now has a “group” column for single-word keywords so that issues can be more thoroughly categorized, and a “size” column to identify the scale of work needed to address individual issues; @afercia and @joedolson added keywords to all the issues

@afercia asked that team members read and respond to this Gutenberg ticket, in which @tinkerbelly requested feedback on Gutenberg’s <RangeControl>component: https://github.com/WordPress/gutenberg/issues/14166
@joedolson expressed the opinion that range sliders should only be used when precision isn’t critical, whereas many of the Gutenberg uses of the component are for very granular options, e.g. choosing between 2-4 columns

@greatislander offered to write notes for the meeting; @afercia offered some guidance on how to approach this, and shared the Post & Comment Guidelines