This week in WordPress Accessibility, October 2, 2017

Transcript in Slack

Labels when multiple same landmark roles in the same page

Related tickets:

  • #42056: Twenty Seventeen: role=”complementary” are missing labels
  • #42057: Add ability to pass a label for the element returned by get_search_form()

This issue applies only to roles that are also landmark regions. They’re reported by screen readers as navigational element and, when there are more then one of them, there’s the need to disambiguate them in the same way we’ve done for navigation menus.
@williampatton will respond to the tickets with the conclusion of our discussion and some examples.

screen-reader-text class check

Recently the screen-reader-text class has been updated, see #40970: Update and audit the screen-reader-text CSS class used in core. We discussed if this was the right CSS as some screen-reader-text is read out in reversed order by Apple VoiceOver. This is depending on the height to the element containing the screen-reader-text class. As this already was the case before we changed the class, we blame Apple and leave the class as is.
As soon as the screen-reader-text page is added to the handbook, we will update all instances of this class in the wp.org documentation, referring to that page.

Gutenberg frontend markup

@samikeijonen tested and reported the frontend markup of the blocks Gutenberg produces.

We discussed the results and saw issues with the semantics, the W3C and WCAG validation. At the request of @karmatosed, @samikeijonen will create an issue for this on the GitHub repo of Gutenberg.

Also the inline CSS that is added to the HTML was discussed.
Sami suggested an option add_theme_support( gutenberg ) to set inline styles to false or replace inline CSS with classes. Inline styles inhibit the ability of users to use their own custom stylesheets and create a barrier to tools that customise the view. Inline CSS is also not good for rendering performance and SEO added @Joostdevalk.
It also would be useful if theme authors could disable blocks or functionality like the adjusting the text and background colours.

Related issues on GitHub:

#weekly-meetings

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