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).

Cross-post: Video: Accessibility walkthough of navigation menu block designs

Accessibility Team meeting agenda: March 1

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

  • Health Check plug-in a11y
  • Update on User Handbook
  • Update on Automated testing
  • Review Gutenberg a11y issue triage to further prioritize
  • Open Forum

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

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

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

/h

Accessibility Team Meeting Agenda: February 22nd

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

  • Uniform Search Planning
  • Update on User Handbook
  • Prioritize Gutenberg A11y issues for WP 5.2
  • Search: Replace Placeholder with Label (https://github.com/WordPress/gutenberg/issues/13900)
  • Surface keyboard shortcuts visibly (https://github.com/WordPress/gutenberg/issues/13688)
  • Improve keyboard navigation between the block inspector and the block content (https://github.com/WordPress/gutenberg/issues/13663)
  • Open Forum

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

Accessibility Bug scrub will happen on Friday 22 February 2019 at 15:00

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

Accessibility Team Meeting Notes: February 15th

Meeting notes on Slack

Lack of Agendas & publishing of notes

  • We’ve struggled to get agendas and notes published recently, due to personal issues.
  • Will get all notes caught up with today (@joedolson)
  • Want to devise a better system for preparing agendas, that takes into account who will be present at any given meeting.
  • Last week’s meeting agenda contained numerous items where nobody present had relevant new information.
  • People anticipating attending a meeting should contact team reps if they have a topic they’d like to raise

Updates on Gutenberg user docs

  • Still no updates on Github or elsewhere
  • Mentioned in update chat with @chanthaboune; hope to get some information soon.
  • Should we publish the docs for assistive technology ourselves, or would that just create long-term confusion?

WordPress 5.2 Release schedule

  • Release schedule has been set for late April.
  • Time frame will not allow for Uniform Search
  • We believe it does give space for us to accomplish the 32 accessibility tickets currently slated for next release.
  • @joedolson will take ownership of the Uniform Search ticket so that we can begin planning, aiming to accomplish this in 5.3

Open Floor

  • From @afercia: note new proposal to systematically integrate animated micro-interactions in Gutenberg’s UI.
  • While we don’t have any fundamental problems with this in general, we should comment to ensure that the accessibility concerns with animations are raised.
  • From @afercia: Block specific responsive controls – very complicated and questionable semantics, particularly due to multiple controls that share the same label – labels should be unique. Topic will be discussed in design meeting, as well.

Accessibility Team Meeting Notes: February 8th

Meeting notes on Slack

Updates on WP 5.2 schedule and goal setting

  • No known schedule, nobody present has an update.
  • Discussed Uniform Search – what it is, what it would require, and what we need in order to have time for it.

Updates on Gutenberg user docs

  • Pinged @dryanpress for updates, no response.
  • Apparently no action on Github issue since January 15th.

Updates on Gutenberg phase II

  • Major discussions since last week’s meeting on the topic of navigating between blocks and sidebar (inspector)
  • Lots of promising ideas and engagement; working to reach a decision and implementation.
  • Work is developing on the Navigation menu block. Navigation menus are one of the more complicated and essential features, so accessibility should monitor this in an ongoing manner.

Open Floor

Discussed goals with @vossisboss to identify a good path for participation.

Post meeting follow-up:

@greatislander showed up shortly after the meeting with an update on automated testing:

  • Initial idea of packaging as a plug-in proved infeasible due to the size of the package.
  • Waiting on updates for the publication of axe-jest-puppetteer packages to NPM (anticipated around 5.1 release.)