Accessibility Meeting Notes for 19 April 2019

Meeting transcript on Slack

Welcomed new contributors

Welcomed and got introductions from Enrique Sanchez & @nataliemac; gave them an introduction to the Accessibility Team purview and operations.

1) WordPress 5.2 Accessibility Team work statement

@joedolson didn’t know what the intent behind this agenda item was, so tabled for next week.

2) WordPress 5.3 Goals

Reviewed goals for 5.3. @nataliemac will review & update spreadsheet of priorities. Enrique Sanchez volunteered to help with planning on Uniform Search.

3) Update on Automated Testing

@gziolo has made a pull request to incorporate Axe testing into Gutenberg e2e suite. Pending review.

4) Update on User Handbook

Discussed whether we should publish @abrightclearweb‘s documentation into our Handbook, since it’s now mid April and we still have no updates on user documentation.

Laid out scope of what this would take, which is significant.

@karmatosed will follow-up to try and get something moving next week. It would be preferable to not have to reduplicate this work, but we feel strongly that it needs to be published.

5) Continuing Discussion: W3C alt decision tree

Tabled due to shortage of time.

6) Update on Accessibility Team/Contributors Badges

All badges have been updated per discussion last week.

Accessibility Meeting Notes for 12 April 2019

Continue discussion on WP.org profile badges

Reviewed criteria for Team/Contributor badges for the team:

1) Team badges:

  • Past team leads
  • Regular participation in meetings (at least once per month)
  • Leadership role
  • Writing documentation
  • Leading code contributions (project management for major tasks, significant code written, etc.)

2) Contributor Badge:

  • Occasional meeting participation
  • Code contributions on Github or Trac (bug reporting, testing, and patching)
  • Assisting in Accessibility Support forum
  • Performing A11y Theme Reviews

3) Update cycle

  • Badge assignments will be reviewed in mid April and mid October each year, and will be based on participation during the prior 6 months.

Additionally, we reviewed the badge assignments for the Accessibility team and contributors throughout the project. We believe that this is now up to date according to the above criteria.

If you’ve contributed to WordPress Accessibility and you do not have a badge assigned, please comment below and let us know! We assembled a lot of this from memory and searching through trackers, meta activity, and slack conversations. It was definitely not an infallible process.

If the reason you don’t have an Accessibility badge is because your contribution isn’t covered by the above criteria, please let us know that, as well! The criteria are open to changes.

Open Floor

@greatislander Wanted to address an small accessibility improvement that we could add to the Settings API immediately, since getting the complete API revamp is stalled at the moment. Team agreed that adding role="presentation" to make the settings tables presentational is probably a good choice, though we’ll want to test it.

Note

We got through only one item on our scheduled agenda for this week, since we spent most of the team getting our badges up to date. We’ve committed to a 6 month review cycle for badges, so that we never spend that much time on it again…

The rest of this week’s agenda will be addressed next week.

Accessibility meeting agenda for 12 April 2019

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

  • Continue discussion on WP.org profile badges
  • Update on Automated testing
  • Update on User Handbook
  • Continuing discussion: strategies for use of the W3C alt decision tree in translations.
  • Uniform Search
  • Open Floor

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

The Accessibility bug scrub will be held on Friday, April 12, 2019 at 14:00.

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

Accessibility Team Meeting Notes for 4/5/2019

Meeting notes on Slack

Profile badges

  • We have not been keeping up to date on these for some time.
  • We don’t have a consistent plan for granting badges.
  • @audrasjb will create a spreadsheet to share among the team where we will document badges
  • @joedolson will figure out who needs to be notified about new badge assignments
  • The team will jointly figure out who needs to be awarded badges.
  • Tentative policy agreed on:

1) Team badges:
– Regular participation in meetings
– Leadership role
– Writing documentation
– Leading code contributions

2) Contributor Badge:
– Code contributions on Github or Trac
– Assisting in Accessibilty Support forum
– Performing A11y Theme Reviews

Update on Automated Testing

  • @greatislander has been in communication about getting added to WP Rig
  • Some feedback on documentation improvements
  • No response from Underscores yet

Block Editor User Handbook update

  • No new information.

Should we copy the alt text decision tree for translations?

  • @audrasjb feels strongly that we should make our own copy and provide all translations in handbook/HelpHub.
  • Reviewed licensing for W3C docs, which will permit this as long as we credit them appropriately.
  • @audrasjb volunteered to take on copying the tree over.
  • Will finalize decision in next meeting; want @afercia to be present for the final conversation.

Uniform Search

  • No progress made. Nobody has yet stepped up to share the process of figuring out what this will entail.

Open Floor

@luke_pettway reported that the Navigation block is going into development very soon. His interactions with the team working on that exposed a number of accessibility blind spots, so hopefully the development process for this will work well to iterate through those issues.

See this comment on the Navigation menu block for revised information on the proposal.

See the prototype for more information on proposed interactions.

Luke will write up notes and post to the channel for comments; he wants some second opinions in some areas.

Accessibility meeting agenda for 5 April 2019

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

Please note the change of time for the meeting; this may or may not impact you depending on how and when your timezone handles daylight saving time.

  • Discuss how we handle WP.org profile badges for the team.
  • Update on Automated testing
  • Update on User Handbook
  • Continuing discussion: strategies for use of the W3C alt decision tree in translations.
  • Uniform Search
  • Open Floor

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

The Accessibility bug scrub on Friday, April 5, 2019 at 14:00 is cancelled for this week.

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

Accessibility meeting agenda for 3/29/2019

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

  • Update on Automated testing
  • Update on User Handbook
  • Use of tables in Site Health screens
  • Should we copy the alt decision tree into the Handbook for translation?
  • Open Floor

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

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

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

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.