This week in WordPress Accessibility, October 24, 2017

Transcript in Slack

Please note: the times of our meetings have changed.

Handbook

Because of work and holidays, the last month not much work was done on the handbook. But as from now we will pick up writing again. The goal still is to have the handbook finished mid March 2018 (with all the text ready for review around mid January).

Tickets/Issues for contributor days

We need a page to refer to on contributor days with a list of tickets and issues to work on. Preferable tickets without a long history of discussion. Like “good-first-bugs” or keyword related tickets or Gutenberg “Good first issue”. @afrecia provided a list and Rian will create the page.

Our focus for 5.0

For the WordPress 5.0 release we will focus on the accessibility of Gutenberg. There are still a lot of Gutenberg a11y tickets open and discussions to be held and testing to be done.

HTML5 landmarks

Marco Zehe published recently: Firefox 57 will be less chatty to screen readers in some situations. FireFox will treat HTML5 landmarks differently. This has implications for the changes just made in the Underscores theme. @samikeijonen is researching this.

Also Apple VoiceOver doesn’t announce the footer if no role="contentinfo" is added. This seems like a bug.

We will wait until FireFox 57 is officially out and will test this with FF/NVDA and Safari/Voiceover.

Good reads

#accessibility-team-meetup

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

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

The Last 3 Weeks in WPa11y!

Accessibility Tickets in 4.8

These are the current accessibility related tickets slated for the 4.8 release:

  • #35566 removes the title attribute in the tag cloud widget
  • #38768 adds the site title as the alt attribute to the custom logo

WordPress 4.8 introduces a few new media widgets as well as the ‘Nearby Events’ widget. Testing should continue to be sure that new accessibility issues aren’t introduced.

Future Releases

If you would like to have an impact on future WordPress releases join us during our bug scrubs! During bug scrubs we go through the “awaiting review” and “future release” reports.
Gutenberg Editor

The Gutenberg Editor is slated for a big reveal at WordCamp Europe.
Let’s keep testing for accessibility related issues as development continues.

You can find installation instructions here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

Note that it is not a conventional plugin so there are some specific steps to follow.
Accessibility Tasks

There are several ongoing tasks with the goal to improve accessibility in the Admin area.

  • Proximity
  • Add widgets screen
  • Menu screen

Widgets and menu screen

It’s not a secret that there are many issues in the Add Widgets and Menu screens. What to do? @juliemoynat has suggested some improvements in this ticket: https://core.trac.wordpress.org/ticket/40677

Proximity

In web design, the principle of proximity states that related items should be placed close together. By the same token, if things are spaced farther apart they appear to have less relation to one another.

This principle is so powerful, that it overrides similarity of color, shape, and other factors that might differentiate a group of objects.

Proximity is especially critical for users with low vision. It will even be addressed in the next draft of the WCAG guidelines! https://w3c.github.io/low-vision-a11y-tf/requirements.html

An initial ticket has been created, feel free to join in! https://core.trac.wordpress.org/ticket/40822

#weekly-meetings

Team Chat Summary August 10, 2015

New Structure Proposed

Rian Rietveld wrote a proposal on how to structure our work better and plan ahead longer and we discussed it. What follows is examples from the proposal.

Goals and Issues

This will be a separate page on make/accessibility and also a main menu item. It gives an overview of our goals for the accessibility of WordPress, the work we (want to) do, how this is organized, how we test, a roadmap for the next year and how we track the progress of issues we are working on. An example of the roadmap for release 4.4:

Release 4.4 (December 2015, Scott Taylor)
  • Finish still open issues focus from 4.3
  • Semantic heading structure Admin
  • The customizer
  • Handbook
  • Twenty Sixteen (?)

Central Ideas

Some central ideas also included in the proposal are keyboard focus, work on the handbook, color contrast, system to better follow tickets including splitting up tickets among team members on which to concentrate, and continue to develop code pattern library. Much more is included in the proposal and for now we will continue to work on the proposal to make it a more formal document to cover our activities over the next year.

We also talked about the fact that having a planning document to refer to does not obviate the need to address all new features since there is a tight turn around towards the end of a cycle because that’s when the features going into the release are announced. If we don’t follow all new features we might miss one or more that advance to release at the very end.

When we have it shaped up we will add the planning documentation to this blog in the form of pages and sub-pages to make it a community resource.

#accessibility-team-meetup, #team-reps, #weekly-meetings

Accessibility Team Meeting July 6, 2015

H1 in the admin

For 4.3 there will be an H1 in the admin. #31650: Missing H1 heading in the admin. Assistive technology users look for the H1 for way finding. Though there is the page title, when AT separates out elements such as links, lists, and headings, the info needs to be there too. Two weeks ago we ran this by Mika Epstein @Ipstenu and she helped us understand heading levels and plugins. Mika spot checked some plugins and it showed that they are using H2 and her opinion is that “we can post about that in make/plugins to try and spread the word.” Thanks Mika. More work will be done on the rest of the hierarchy.

Main Open Tickets

We also briefly discussed:

  • #31661: Quicktags: Can’t add them using just a keyboard in IE,
  • #26601: Inappropriate content in headings on admin screens,
  • #32152 List table: sortable column headers accessibility,
  • #26601: Inappropriate content in headings on admin screens, and
  • #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior.

#accessibility, #team-reps, #weekly-meetings

Accessibility Team Update: May 1, 2015

Weekly Meeting Change

This week during the Wednesday meeting we decided that the Monday testing meeting is now where the action is so we decided to stop having the Wednesday meeting. On Monday, May 4, we will all meet in the #accessibility channel in Slack at 18:00 UTC. We are also using Slack throughout the week to work on tickets and patches, ask questions, and discuss anything that comes up. First register for the WordPress forums and then follow the steps on the WordPress chat instruction page to get set up. Then find your way to #accessibility. See you there!

#team-reps, #weekly-meetings

I’ve only just realised that Admin Bar links…

I’ve only just realised that Admin Bar links contain tabindexes. That’s bad enough but they’re not really in an intuitive/logical order. Can they be removed in a future version?

WordPress 3.3 is coming up on RC1 meaning…

WordPress 3.3 is coming up on RC1 (meaning it’s close to launch). We tried to catch as many accessibility issues as we could, but chances are we missed things. If anyone would be willing to run 3.3 beta through the paces and report back on how it does/what fixes need to be made, that would be great. If you’re not set up with an svn install, you can download the beta tester plugin to put the beta on a test site.

#3-3

Changed a couple of settings Must fill in…

Changed a couple of settings:

  • Must fill in name and email, but removed the ‘must have previously approved’ setting so now comments go live immediately instead of waiting to be moderated.
  • Close comments on posts older than 14 days old. Comments go unnoticed, and no action gets taken. Hopefully discussions can get to agreement within 2 weeks (well before, if we’re lucky) and the resolution can make its way over to the appropriate trac ticket.