This week in WordPress Accessibility, September 4th, 2017

Transcript of the meeting

Agenda

  • ARIA roles in Underscores theme.
  • CodeMirror.
  • Automated accessibility testing.
  • Gutenberg
  • Open floor / Go crazy.

ARIA roles in Underscores theme

We removed ARIA roles from Underscores theme couple months ago. But WAI-ARIA 1.1 and HTML 5.1 specifications have been updated. Here is good overview of the ARIA changes in Firefox. This is the biggest change for ARIA roles:

<header> and <footer> elements will now only be exposed as header and footer, and banner and ContentInfo landmarks respectively, if these elements are direct descendants of the body tag, and therefore are scoped for the whole page.

In _s header and footer are not direct descendants of the body tag, they are inside #page wrapper. Discussion about this continue in Underscores repo.

Codemirror

It’s hard to create 100% accessible code editing tool. With Codemirror we are happy with two main points:

  1. Avoid keyboard trap inside code editor.
  2. Easy way to disable Codemirror.

We also looked at how Help text section could be easier to find in the Additional CSS. Help text section is now auto-expanded when first opening the panel, when the CSS is empty or at its placeholder value.

We encourage everybody to test Codemirror, development is still in Github before Core merge.

Automated accessibility testing

Automated accessibility testing is a big topic. @joedolson proposed four ideas where we could start:

  1. How will core builds be mounted so the DOM gets tested.
  2. What method will we use to execute tests.
  3. What tests will we execute.
  4. How much manual testing will we continue to do regardless of passed tests.

Gutenberg

Before the meeting there was Gutenberg bug scrub. In the meeting we mainly discussed about landmark regions.

Open floor / Go crazy

Me and Joe went to sleep, Andrea had something to eat 🙂

#meeting-notes, #weekly-meetings

Accessibility work at WordCamp Nijmegen

@tacoverdo announced at the start of WordCamp Nijmegen that the Twitter hashtag #WCNMGN needed to be capitalised for screen reader users. And a lot of people did, thank you!

Work on the Contributors day

  • @choongsavvii worked with @jrf on the keyboard accessibility of the main menu in wordpress.org. @obenland pointed out that this part is not open source and it’s can’t be fixed by changing the CSS only. To be continued.
  • @travel_girl worked on the new Handbook
  • @rianrietveld was table lead and gave an intro to a group of people about the basis of Accessibility
  • @maartenleenders and @jaapwiering worked on trac tickets labeled accessibility. Finding it hard to choose a ticket, as most tickets are discussed for a long time and it’s difficult to get into this fresh in such a short time as om the contributors day.

Ideas from the Hallway tracks

Automated a11y testing

This topic came up again and again. @jrf (Juliette Reinders Folmer) gave a talk “The Biggest WP Core Patch Ever” about trac ticket 41057, upgrading core to the coding standards. And after that talk I had many discussions about integrating accessibility in all the automated testing we do. For core, but also for themes in the repository and for plugin and theme development in WordPress.

After the Handbook is in good shape, I think we need to pick this up as focus for the Accessibility Team. This will probably be begin next year. @jrf and @spacedmonkey want to help and there are probably more people and companies we can ask to help.

Which tickets are easy to pick up

Before a WordCamp contributors day we need a better list of tickets and issues for developers to work on. That have a very specific clear solution and not a debate of years without conclusion.

CTA

Help @boemedia with her research on the usability of the Admin by filling out her survey.

#wordcamp

This week in WordPress Accessibility, August 28th, 2017

Transcript of the meeting

Agenda

  • Handbook, progress so far
  • CodeMirror
  • Gutenberg
  • Open floor

CodeMirror was moved up in the discussion by request of @samikeijonen.

CodeMirror

CodeMirror will be incorporated into WordPress 4.9 in theme and plug-in editing, the HTML text widget, and the customizer CSS editor. Discussed how to provide access to Help for keyboard users who will need some instruction on how this will work from the keyboard. The plugin/theme editors and the CSS editor have logical places to provide information, but HTML widget doesn’t have a place for this information.

Conclusion: WordPress needs an inline help implementation. Lacking that, we’ll use the Help tab to hold the information for now, with the eventual goal to implement inline help and move the information.

Handbook

Report: Work on the Handbook has started. Trying to write at least one topic per week. Discussed how to handle some complex topics, and agreed that where applicable, we’ll refer directly to external examples and recommend the most official example for a given specification. E.g. tab panels.

Progress on Handbook

Gutenberg

Simply Accessible has offered to provide support for developers on Gutenberg. Discussed effectiveness of this and ability to help with solutions. Problems mostly have to do with gathering consensus then finding somebody to implement. Tried to generalize how Simply Accessible can best be leveraged. Suggested they focus on keyboard interactions with blocks.

Discussed labeling some Accessibility issues as high priority to try and focus efforts.

@afercia commented that one core problem is that technical solutions have gotten decided without a preliminary accessibility evaluation which have had significant impacts on accessibility.

Open Floor

@rianrietveld will be on holiday for the next four weeks, and asked for a volunteer to lead meetings during her absence. @samikeijonen volunteered for at least next week’s meeting.

#meeting-notes, #weekly-meetings

Accessibility work at WordCamp Brighton

Talks about Accessibility

Work on the contributors day

  • Maja worked on the new Handbook, setting up a page about dyslexia
  • @kau-boy (Bernhard Kau) created a patch for the menu in the Handbook Chapter menu
  • Bernhard and Rian a11y reviewed 2017.europe.wordcamp.org. As a result we also need to address some issues in JetPack (follow up Rian)
  • Rian did a Accessibility Q&A with about 5 people.
  • We had a discussion with @karmatosed (Tammie Lister) on how to know what to test for with new functionality in Gutenberg. Conclusion for now: follow the change log
  • The marketing team worked a checklist for writing accessible content. There was a discussion about PDFs, how they can be made accessible. This needs to be added to the new Handbook. The checklist will be send to the a11y team for review (follow up @anafransilva (Ana Silva))

Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

This week in WordPress Accessibility, August 14th, 2017

Transcript of the meeting

Handbook

The work for rewriting and reorganising the Handbook is in progress: @samikeijonen, @travel_girl and @rianrietveld are writing the first topics, @joedolson is reviewing them. We plan to write at least one topic per week. And the deadline for the first iteration of handbook is March 1, 2018. We enjoy the discussions on Slack: writing everything down makes us really think about what the best practices are.

SelectWoo

We send the SelectWoo demo pages to the testers for assistive technology testing and hope to get feedback this week. The testers will add their findings to the Github issue Review SelectWoo accessibility.

Codemirror for WP 4.9

Because the addition of Codemirror is planned for WP 4.9, we started the discussion with ticket #12423 again. On GitHub it’s available as a plugin, so we’ve opened an issue with our concerns of a code highlighter as default text editor. It’s not accessible for screen reader users. The plugin is also installed on our test server at wpaccess.org/codemirror/ for user testing if needed.

Gutenberg

We installed Gutenberg, from Git Master, on our test server and asked testers to test again, the first test we did was a few months ago and a lot has changed in the meantime. The results are collected and published by @karmatosed on GitHub, labeled feedback.

The next test should be a review of the output of all blocks on the frontend.

Next meeting

  • The next meeting will be at August 28, because too many people are on holiday the 21st.
  • On every Thursday we will informally discuss the handbook during the day.

Thanks @samikeijonen @travel_girl @joedolson @arush @nicbertino @zakkath @karmatosed @sergeybiryukov for joining the discussions.

#weekly-meetings

This week in WordPress Accessibility, August 7th, 2017

Transcript of the meeting

Accessibility of Select2

WooCommerce makes use of Select2, and has forked Select2 to create a more accessible version. Select2 has not been updated since the beginning of the year, and none of the accessibility pull requests made by @afercia had been incorporated into the repository. Because of this, WooCommerce elected to fork the project so that they could make better progress. The new fork lives at WooCommerce/SelectWoo.

Select2 was of interest to the accessibility team a couple of years ago as a possible solution to some significant performance problems relating to multisite networks and sites with many users. However, the project had a lot of accessibility issues that made it non-viable for core usage.

@claudiulodro attended our meeting as a representative from WooCommerce. He’s been working on integrating accessibility in SelectWoo. He will set up a test page with sample usages of SelectWoo and prepare a list of known issues that he would like assistance with so that the accessibility team can effectively provide feedback. Feedback should be provided via comments on the Accessibility review thread, as GitHub doesn’t allow people to raise issues on a fork.

@claudiulodro will make a post about SelectWoo on the WooCommerce blog later this week.

If we determine that SelectWoo provides a viable mechanism to address issues in WordPress core, we will comment to that effect on pertinent tickets within Trac.

Accessibility Handbook and Documentation

@samikeijonen gave a report on the meeting to discuss accessibility documentation on WordPress.org and in the accessibility team handbook. See the WordPress Accessibility documentation meeting notes for details.

The documentation subgroup requested a native English speaker to review documents as they are completed, as the majority of the team are non-native speakers but writing in English. @joedolson agreed to do that.

Accessibility documentation that exists as specific guidelines for developers, such as the theme accessibility review documents, needs to stay where it is. In order to avoid duplication, the team handbook will link across to those documents when that content serves the purpose needed effectively.

Open Floor

@afercia encouraged anybody who’ll be in Europe in November to propose to talk at WordCamp Milano (Novermber 18-19).

WPa11y documentation meeting

Attending: @travel_girl, @samikeijonen, @sergeybiryukov and @rianrietveld

Goal of the meeting:

Kickoff meeting for rewriting and reorganising the documentation on WordPress.org regarding web accessibility.
We want the documentation set up so that it’s complete, without duplicates, easy to find and put it on places where people actually will read it.

What we agreed on:

  • We will start with our own handbook
  • In the topic spreadsheet we gather topics and assign ourself to write about them
  • We will add topics as we go
  • We will write in Google Docs (Sami opened a directory for this)
  • We can organise the topic later in a logical way before publishing them in the accessibility handbook
  • We report and discuss our work every Thursday in the #accessibility Slack channel
  • The goal is to write one topic a week per person
  • When the topics are added to the handbook, we will review the current documentation on wp.org to see where we can ask the teams to replace/add/modify text to prevent double info and to link to better information.

For the topics we want to keep a template, for example:

  • Topic
  • Short intro with:
    • Good Practice
    • Bad Practice
    • Why
    • Exceptions
  • Examples
  • Resources with links

We don’t want to copy all the info there already is on the web, but point to good info and examples.

If more people want to join in, you are most welcome.

#documention

This week in WPA11y, July 31, 2017

Transcript of the meeting

Handbook and Documentation

@samikeijonen , @travel_girl and @rianrietveld will work together to look at the current documentation on WordPress.org about accessibility and see how they can improve and extend that.
Rian will setup meetings for this.

Test output Gutenberg in the frontend

@afercia set up a page on our test server with all blocks from Gutenberg version 0.5.0. We need to test if this code is valid and accessible, as this will end up on all WP websites eventually. There was a discussion about the usefulness of testing now, as G. is moving and changing so fast at the moment. Also G. 0.6 is already out: Andrea will set up a page for that too. Especially galleries and other complex HTML constructions are imported to test.

We still need more developers who can work on the accessibility of Gutenberg.

Manage a11y tickets

We should be more vigorous about blocking implementation chatter during bug scrubs and keep the discussion about solving the issue with the ticket itself. This way we have more time to also look at the Gutenberg issues on Github.

Open floor

#weekly-meetings

This week in WPA11y – July 24, 2017

Transcript of meeting.

The discussion of the handbook was punted to the July 31st, 2017 meeting, as @samikeijonen was unable to attend this week’s meeting. As this discussion was originally intended as the primary focus of this week’s meeting, the entire meeting was open floor, with no agenda.

Topics discussed

Gutenberg: block output

@afercia recommended we set up a test to review the output of all Gutenberg content blocks, as many of the new block types generate different output than the equivalent in the existing editor, such as the image gallery block.

@rianrietveld requested that @afercia create a post for testing that contains all relevant options.

We determined that we need to first perform an expert review of the general issues, request modifications as necessary, then gather user feedback once any major errors have been worked through.

The team briefly discussed the reasoning behind creating content blocks that generate features that exist in the current WordPress ecosystem using different output HTML; further conversation on this topic should probably land in relevant Gutenberg issues.

Gutenberg: user testing

@nicbertino volunteered to manage moderated user testing for Gutenberg, to start with general user testing, then proceed to specific testing with users requiring assistive technology.

#weekly-meetings