Meeting notes on Slack
Update on Automated testing
@greatislander shared some updates about the automated testing project:
For ease of setup, a package can be installed directly from GitHub into any theme.
One of the first follow-up tasks would be expanding the test cases to include all the content from the current Theme Unit Test Data package.
Then users would be able to:
- Import that content into a development site You can keep a copy of your live site in a separate environment. Maintaining a development site is a good practice that can let you make any changes and test them without affecting the live/production environment.
- Install the
- Run the test command
The included tests would cover all the posts, pages and post types that are part of the a11y 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)-theme-unit-test data. Once some of these details get ironed out that would be nice to see these tests included in the
wp scaffold theme command.
The team agreed to:
- move @greatislander’s repo into the
wpaccessibility GitHub 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/ org repository
- recommend to adopt @greatislander’s effort result as a WordPress testing tool, and post about it on Make
@greatislander: There is also an end goal where this is part of a reusable CI configuration that any theme can use that:
- Creates a Docker environment running the theme
- Installs this test suite
- Installs the theme-unit-test content
- Runs a full suite of tests on all the content
That way any theme developer could put their theme through the paces with content that’s known to meet 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) guidelines and flag any issues that Axe finds with their theme itself.
Update on 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/ accessibility issues triage and prioritization
Both Accessibility team and Editor/Gutenberg team shared that they’re a bit short in terms of devs availability. So they’ve quickly discussed how to best handle the list of issues. Prioritization for categories would be good.
Also, proposing 3-4-5 issues per week during the editor’s chat would work. Every meeting, they will reserve some space for “task coordination” to address the most urgent issues.
WordPress 5.2 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 date is delayed to March 21, not March 14 as previously communicated.
The full list of 5.2 Accessibility tickets is available here.
Accessibility focused tickets is now down from 30 to 24 tickets, and there is some good progress on at least other three of the most tricky tickets.
Alt attributes on Media Library and 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. Editor
A while ago, for the ticket #41612 and Gutenberg G#1509 the Accessibility Team came up with the following description for the alt text field:
Describe the purpose of the image. Leave empty if the image is not a key part of the content.
The description in Gutenberg has been changed to the following:
Alternative text describes your image to people who can't see it. Add a short description with its key details.
An issue was created because the above is wrong. The intend was to clarify and improve the text, however it would be better to revert since it is not a description of the image but that is directly antithetical to the idea of the alt text.
@afercia proposed two possible improvements:
Functional replacement for the image. Leave empty if the image is not a key part of the content.
Functional replacement for the image. See the alt decision tree tutorial.
where “the alt decision tree” is a link to WAI Decision Tree page.
@audrasjb proposed to link to a similar page on HelpHub so it can be translated in the future.
@afercia also shared one part of the argumentation behind the change in Gutenberg. The previous text started with a verb “Describe the purpose…”, So users who are completely unexperienced may actually enter some text like “The purpose of this image is…”.