Accessibility team meeting notes 3/22/2019

Meeting notes on Slack

Update on Automated testing

  • Automated testing package now includes test cases for the accessible theme unit test data
  • Now has an interactive command line interface for creating new test cases
  • Added a postinstall script to copy required files into the theme directory automatically.
  • Requests help with https://github.com/wpaccessibility/wp-theme-auditor/issues/8
  • @greatislander will write up a post inviting people to test the package (will x-post to theme review team)

User Handbook

Still no updates. Still no movement on GitHub. Requesting updates for next week.

WordPress 5.2 tickets/5.3 planning

A total of 23 out of the 30 prioritized accessibility tickets have been committed by the deadline. 5.2 is now closed for new issues, so that’s where we stand for this release.

Team discussed strategies for the 5.3 release. Since we don’t know what the schedule will be like, this is necessarily limited.

We agreed that our tentative plan for 5.3 is to focus on three topics:

  1. Complete the 7 remaining prioritized tickets from 5.2
  2. Address issues from the Gutenberg a11y issue triage
  3. Plan what needs to happen in order for Uniform Search to land in WordPress 5.4.

Gutenberg A11y issue/5.3 planning

Pretty much addressed the planning elements during the previous discussion.

Eight issues from the triage list have been resolved.

We’re anticipating that the WP Campus accessibility audit of Gutenberg will be delivered soon, and may contain important information for us to absorb.

Updates to Theme Developer Handbook

At the end of last week’s meeting, @abrightclearweb delivered a list of accessibility issues to address in the content of the theme developer’s handbook.

These issues have been passed over to @jcastaneda, who will make the needed edits.

Some of the issues are more complicated, and are pending @joedolson writing up more detailed comments on how to resolve.

Open Floor

@afercia recommended everybody take some time to read The WebAIM Million Project over the weekend.

Call for Testing: wp-theme-auditor

Building on initial efforts at WCUS 2018 Contributor Day in Nashville, the Accessibility Team has continued to move forward with the development of automated accessibility testing tools for WordPress themes. The work so far is available in the wp-theme-auditor GitHub repository, and the Accessibility Team is now seeking feedback from the broader WordPress community in order to make this tool as useful as possible.

wp-theme-auditor is a Javascript package which includes end-to-end testing tools from the Gutenberg project and Deque Labs’ axe accessibility testing framework. It is meant to be installed as a development dependency in a WordPress theme, and includes a default set of test cases based on the Accessibility Team’s a11y-theme-unit-test-data. wp-theme-auditor can be run against a local development site (remote sites are theoretically supported but untested).

You can install the tool by running the following command (if the theme to be tested does not already include a package.json file, you will need to create one first by running npm init -y):

npm install --save-dev wpaccessibility/wp-theme-auditor

Installing the dependency also runs a postinstall script which copies the required Babel and Jest configuration files to the theme directory and copies required test files (including the default test cases) to a test folder within the theme directory.

Two scripts must then be added to the theme’s package.json file:

  "scripts": {
    "create-test-cases": "create-test-cases",
    "test:axe": "wp-scripts test-e2e"
  }

If you want to test your theme with these default test cases, you need to import a11y-theme-unit-test-data into your development site first. Then, running WP_BASE_URL=https://mytheme.test npm run test:axe (where the local development site URL is https://mytheme.test) will audit all the imported posts and pages using axe and provide detailed feedback about any violations. (The imported posts and pages from a11y-theme-unit-test-data have been crafted to ensure that content does not include any accessibility issues, so tests will catch accessibility issues in the theme itself rather than content.)

Running npm run test:axe will load any files which match the pattern test/*.test.js, so if you need to exclude any of the default test cases, you can move them out of the test folder.

The other script, create-test-cases, provides an interactive command line prompt for creating new test cases for custom post or page templates. For example, if your theme has a custom page template for a contact page and you want to make sure that your contact form passes axe tests, you can use the interactive prompt to specify the post type (post or page), slug, and label for that test:

npm run create-test-cases
Creating test cases...
? What is the post type? page
? What is the slug of the post or page? contact
? What is the title of the post or page? Contact
Test case created at /var/www/wp-content/themes/mytheme/test/contact.test.js.

Theme developers are encouraged to try wp-theme-auditor and share feedback via the project’s GitHub repository. Future goals for the tool include the ability to add it to themes using the wp-cli scaffold command and the ability to run tests in a Docker container as part of a continuous integration (CI) environment.

While all automated accessibility testing has limitations and there are many accessibility issues it cannot catch, wp-theme-auditor could be an exciting new tool to guide WordPress theme developers towards accessibility best practices.

Accessibility meeting agenda for 3/22/2019

This is the proposed agenda for the weekly accessibility team meeting on Friday, March 22, 2019 at 16:00.

  • Update on Automated testing
  • Update on User Handbook
  • Update on WordPress 5.2 tickets / planning for 5.3
  • Update on Gutenberg accessibility issues / planning for 5.3
  • Update on Theme developer handbook fixes

If you have any additional topics to propose, please comment below.

Accessibility Bug scrub will happen on Friday, March 22, 2019 at 15:00.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

Accessibility team meeting notes: 3/15/2019

Meeting notes on Slack

Update on Automated testing

No updates this week on automated testing.

User Handbook

Still no updates. Still no movement on GitHub. Requesting updates for next week.

WordPress 5.2 tickets

Accessibility tickets are down to 16 pending tickets (from 30 in the original list.) Several are very close, and hope to get 4-5 more into the release. Beta 1 is Thursday the 21st, so all patches should be ready for commit on Monday or Tuesday at the latest, to allow time for committer reviews.

Update on Gutenberg issues

5 issues from the original list are fixed, plus one that was added after the triage.

@afercia has categorized all issues by priority, based on personal judgement. Grouped into ‘normal’, ‘high’, and ‘omgbbq’.

No progress on 13663, one of the keystone items we want addressed.

We’re passing specific issues to the Editor team as priorities, to get their focus on specific concerns.

Open Floor

@abrightclearweb has gone through the Theme developer’s handbook looking for accessibility issues. Provided @joedolson with the list of issues; @joedolson will follow up to get these changes made.

Accessibility Team meeting agenda: March 15

This is the proposed agenda for the weekly accessibility team meeting on Friday March 15, 2019 at 16:00.

  • Update on Automated testing
  • Update on User Handbook
  • Update on WordPress 5.2 tickets
  • Update on Gutenberg accessibility issues

If you have any additional topics to propose, please comment below.

Accessibility Bug scrub will happen on Friday March 15, 2019 at 15:00.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

X-post: Strengths and Challenges: Organization

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Organization

Accessibility Team Meeting notes: March 8, 2019

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
  • Install the wp-theme-auditor package
  • Run the test command

The included tests would cover all the posts, pages and post types that are part of the a11y-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 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:

  1. Creates a Docker environment running the theme
  2. Installs this test suite
  3. Installs the theme-unit-test content
  4. 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 guidelines and flag any issues that Axe finds with their theme itself.

Update on 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

WordPress 5.2 Beta-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 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:

  1. Functional replacement for the image. Leave empty if the image is not a key part of the content.
  2. 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…”.

Accessibility Team meeting agenda: March 8

This is the proposed agenda for the weekly accessibility team meeting on Friday March 8, 2019 at 16:00 UTC.

  • Update on User Handbook
  • Update on Automated testing
  • Update on Gutenberg accessibility issue triage and prioritization
  • Update on WordPress 5.2 accessibility Trac tickets
  • Open Forum

If you have any additional topics to propose, please comment below.

Accessibility Bug scrub will happen on Friday March 8, 2019 at 15:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

X-post: 5.0 Release Retrospective Kickoff

X-comment from +make.wordpress.org/updates: Comment on 5.0 Release Retrospective Kickoff

Accessibility Team Meeting notes: March 1, 2019

Meeting notes on Slack

Health Check plugin a11y

  • @clorith shared the Health Check plugin with the team for review
  • Some 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 beta 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

Update on User Handbook

  • @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!

Update on automated testing

Gutenberg a11y issue triage and prioritization

  • 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

RangeControl component: request for feedback

  • @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

Open Floor