Accessibility team update – October 26, 2019

WordPress 5.3 accessibility focus

51 accessibility focused tickets were closed in milestone 5.3.

The biggest changes are related to Admin CSS. These changes were documented in a fully detailed dev note:

These changes were extensively tested by @audrasjb and a full report of his tests is available on Make/Core as well:

Widgets now use aria-current attribute to indicate if the current page in the concerned widgets:

aria-label is now used in Post and Comments navigations to add proper context to the related navigation systems:

Twenty Nineteen’s HTML structure was improved to avoid to generate invalid HTML:

wp_die HTML output was improved to avoid to generate invalid HTML:

There were also a number of accessibility focused changes in the block editor to handle Gutenberg Accessibility Audit issues.

The accessibility team also contributed intensively to the development of the new bundled theme, Twenty Twenty.

WordPress 5.3 was a key release for the WordPress accessibility team. Thanks to everyone involved in the accessibility focused Trac tickets and Gutenberg issues 👏

New accessibility team reps election for 2020

The new team reps will be elected on Friday 8 November 2019 at 15:00 UTC on Accessibility Slack channel.

For further information, see the related post on Make/Accessibility:

Accessibility table for WordCamp US 2019 contributor day

@nrqsnchz will lead the accessibility team table at WordCamp US contributor day. @rianrietveld and @nataliemac will help running the table. @nataliemac will also present an accessibility workshop.

#accessibility

Accessibility team update: August 4, 2019

WordPress 5.3 tickets

As of today, we have 75 accessibility focused tickets planned to ship with WordPress 5.3.

Therefore we have 38 open tickets without any owner. One of our main task next week will be to find owners for each ticket in the milestone.

Gutenberg accessibility tickets

As of today, we have:

The Accessibility Team need more persons able to follow that closely.

Besides the fact that we try to be more numerous to take care of this work, we also evaluate the possibility to find ways to have more sponsored contributors (even a couple hours a week would be a great sponsorship!).

WordPress Accessibility Day organization

By the end of July, the Accessibility Team decided to evaluate the possibility of organizing a dedicated WordPress global accessibility event, like polyglots do with WordPress Translation Day (WPTD).

The idea is to organize a 24-hour virtual event all around the world with some video conferences and focused on contributing to WordPress accessibility.

A couple of weeks ago, a spreadsheet was shared so Accessibility team contributors could sign up to be involved in this organizing team. A dozen of people signed up to the organizing team.

The next step is to discuss the main focuses of the event and to divide the roles between the organizing team.

For information, WP Tavern already published a blog post about this initiative.

Various other tasks

  • Usage of .screen-reader-text class in accessibility documentation: Theme Review Team contributors raised some concerns about the current screen-reader-text class documentation. We are going to take care of rewriting the related docs and will work with Theme Review Team to ensure the new documentation is clear enough for theme authors and WordPress developers.
  • Theme Review Team Accessibility requirements: The team was asked to perform Theme Review Team blog post copy review for new accessibility requirements about keyboard navigation.
  • Block Directory in WordPress Admin: the Accessibility Team raised some initial feedback for these early design. For reference, see first section of Meeting Notes from July 26 Accessibility team meeting.
  • Gutenberg: Support Navigation and Edit Mode: All meeting attendees agree that this is a good improvement. It would be necessary to be extensively tested by as many persons as possible, including users of assistive technologies. For reference, see first section of August 2 team meeting notes. The next Gutenberg Plugin release is planned for August 12th. The Accessibility Team will publish a call for testers with some testing scenarios to test this big improvement.

#accessibility, #accessibility-team-meeting

Accessibility team update for March 9, 2019

  • Health Check plugin review: 9 issues opened, 7 already fixed.
  • Accessibility automated testing tools: The project is close to be publicly released and the team is now moving it into the WPAccessibility GitHub repository.
  • Trac tickets triage:
  • Gutenberg accessibility issues triage: the accessibility team is going to give a triage document to the #core-editor team to help to prioritize the issues. However, both Accessibility and Editor teams are a bit short in term of developers availability so the idea is to handle 3-4 issues per week if possible.
  • Gutenberg User Documentation: awaiting feedback from Docs team.

Last meeting recap:

#accessibility

October 11th Support Team Meeting Summary

Quarterly Check-in

There was one special item that was Quarterly Check-in in which following questions are asked & discussed.

  • What is the team’s one-sentence top priority right now (and what’s the ETA)?
    • Preparing for the upcoming 5.0 release
  • What struggles is the team having?
    • Finding a good balance when being stonewalled by users seeking help and when to walk away, and avoiding escalated tempers in such cases.
    • Recruitment (always a crows favorite)
  • What is one thing you are all proud of this quarter?
    • With how well the team, on a global level, has managed to maintain a good flow of user engagement through support.


Checking in with international liaisons

Members of the Swedish, Italian, Greek, Urdu, Dutch, Spanish, Brazilian, Russian and Serbian communities were there to let us know how things are going in the other corners of our lovely support community.

Open Floor

In open floor following stuff is shared:

  • Meta WordCamp team is planning to convert the WordCamp shortcodes into blocks.
  • The a11y team (#accessibility) has recently experienced some change-ups and we could use some more volunteers – if any of you have accessibility experience (or want to learn more) you’re more than welcome to attend our weekly chats.

Training Team Update – 3 May 2018

Contributor Day Onboarding

The information requested by the WordCamp EU Team for Contributor Day info can be found at https://docs.google.com/document/d/1Mh0vGq075pH-CqyUbMNdrOz9AVaEUm9ofli0YrNaFsg/edit?usp=sharing. It outlines how contributors can help the Training Team during a Contributor Day event, but it is also helpful for the team in general. The Marketing Team is also helping to create a handout specific to the Training Team that can be used to help people get started.

The learn.wordpress.org site

That site has always been the end game for the team’s lesson plans. So in this whole workflow revamp an attempt to reverse engineer our product/processes based on that being the end game was attempted. This Trello card (https://trello.com/c/ck3UjgcA) has a PDF with a few wireframes of what perhaps that site could look like. It has identified a couple of things missing from our lesson plans/workflow. We need to gather more information regarding the learn.wordpress.org site.

There was a big takeaway from that exercise: we need to be writing lesson plans with time constraints in mind. So we should be writing lesson plans that identify:

  1. Length: < 1 hour, 2 hours, 4 hours, 8 hours, possibly multi-day
  2. Audience: Speaker, User, Themer, Plugins, Developers
  3. Level: beginner, intermediate, advanced

Update on slides (Shower – show-er)

The Slides card on the Trello board has the original discussion regarding slides including the requirements and pros/cons of the various alternatives. The #accessibility team suggested https://github.com/shower/shower / https://shwr.me/

So we need to do some work on whether there are pros/cons to Reveal.js (which is what we had been considering as a solution) versus Shower (pronounced show-er). But HTML/CSS/JS still seems the best “official” alternative. Unofficial alternatives, such as Google Slides or PPT files, could be shared, hosted, used for drafting and linked to on the GitHub /slides/README.md files.

May not be the most friendly solution, but we can still allow people to create their slides using whatever tool they like best. Then one of the final tasks before publishing a lesson plan to learn.wordpress.com would be to convert the slides to Reveal or Show-er. Either way the actual slides are just HTML lists divided by sections and has the ability to “theme” the slides. Just like WordPress itself we can keep presentation separate from content.

It’s probable that it won’t be the authors creating these slides (but they can if they want to!), but perhaps a“specialized” role on team to do before “official” publishing.

Team members, roles, meetings

Random thoughts:

  • First random thought: There’s a feeling of a desperate need for a nearly all-day “summit” to talk through things and or make decisions.
  • Second random thought: A survey of members to see what their skills and interests are might be something we need to do.
  • Third random thought: Perhaps a few GitHub help sessions would be good to schedule.
  • Fourth random thought: Our meetings are a bit one-sided at the moment. It should be more of a team event.
  • Fifth random thought: We are missing quality control in our lesson plans – there’s wide variance in what we have.
  • Sixth random thought: We may need another Trello list/job description/step in our workflow to take care of that.
  • Seventh random thought: All these random thoughts reiterate the first random thought.

Accessibility team meeting, April 9, 2018

Agenda

  1. Accessibility statement
  2. Handbook
  3. Gutenberg, priorities for WordCamp London
  4. Contributor drives
  5. Open floor

Meeting notes

Accessibility statement

The WordPress project now has an accessibility statement. We still need to add an ATAG (Authoring Tool Accessibility Guidelines) statement to add to that page. @joedolson will write that, sometime in the near future.

Accessibility Handbook

At the moment @rianrietveld and @samikeijonen are writing pages about how to test for accessibility to add to the handbook best practices chapter, for developers, designers and content managers. This at the request of the Gutenberg team. The pages are in draft now, to be published this or next week.

Gutenberg, priorities for WordCamp London

@karmatosed suggested the following workflow for this:

  • sit down together at a11y table on the contributor day prioritising all a11y issues in a spreadsheet
  • create a solid few weeks plan for accessibility, get everything in milestones, get everything so we all know we’re on track
  • get a ‘hot list’ from that and give easy wins to developers present at  the contributor day
  • leave that clearly knowing what needs to be done for a11y and how help can get there
  • focus on a plan of tasks and that all tasks have enough information to be developed by anyone working on project

Contributor drives

Angela Jin asked us to write up content for their info pages about work that can be done for the different teams during a contributor drive (a bite sized contributor day). @rianrietveld also adjusted the page Getting Started at a Contributor Day for this too.
If a contributor wants to select an a11y task:

  1. Tell the #accessibility channel in WordPress Slack that you are hosting a Contributor Drive and request specific projects and direction.
  2. If you need assistance during the Contributor Drive, ask questions in Slack.

To avoid having to maintain a page with a list of tasks in the documentation of the contributor drive.

Open floor

  • @postphotos came with the idea of organising “contributor drives” in regions across the world, focused on a11y. Like the translation days. He will research this further. We agreed this is a fun idea (wpa11y day?)
  • @arush will publish her research on the screen reader accessibility of Gutenberg this week
  • We had a discussion about adding hreflang to links in translatable strings, like e.g. <a href="%s" hreflang="en"> . Adding the hreflang="en" in the translation triggers a warning
  • We discussed setting a new date/time for the meetings. There will be a separate post about this tomorrow.

 

#accessibility-team-meeting

Accessibility Team update, August 7th, 2017

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 (November 18-19).

#accessibility

Accessibility Team update July 17, 2017

0 Gutenberg

There has been some progress on minor issues.
Major issues still need to be addressed but those will require discussion and decisions.

One of the main issues reported in the first testing round is that there are too many tab stops.
Currently, navigation through all the interface works with tabs meaning ALL the controls are tabbable.

Considering how some of the Gutenberg UI parts are actually ARIA widgets, ideally, they should implement focus as recommended by the ARIA spec and the ARIA Authoring Practices. For example, toolbars and menus should be navigated with arrows only.

There’s definitely a need for more people to do testing and give feedback but we also need help with coding solutions.

The code can be confusing for those who are new to react. In light of this, it was proposed that we add an additional label to help React devs understand the expected outcome and make sure they know the end goal. Some possibilities are `[Type] A11y Task`, `needs React dev` or `has-a11y-feedback-needs-implementation`

To clarify the issue about too many tab stops, consider this example:

This is a Gutenberg “inline toolbar”. They change depending on the block.

All the controls in the toolbar are tabbable.

Instead, according to ARIA, if we want to treat this an ARIA toolbar, there should be just one tab stop on the toolbar and then all the controls should be navigated with arrows only.

That would greatly help to reduce the number of tab stops. The mixed tab/arrows navigation is a solid ARIA pattern borrowed by our operating systems.

1 Handbook

Sami Keijonen asked about the handbook: I actually really like the structure of theme handbook, can or should we use the same kind of format?

Also, the Breathe Theme is broken that we are using for https://make.wordpress.org/accessibility is broken:

  1. On mobile Genericon is missing on “hamburger” menu.
  2. Mobile menu doesn’t open at all.

We would like to do an a11y review on the theme for the theme handbook and fix the theme itself

2 Other a11y documentation in wp.org

We’ll start next week’s meeting with the handbook as well as other wp.org documentation.

3 Open floor

Joe Dolson shared some information about Keyboard Accessibility in Slack. You can find here: https://get.slack.help/hc/en-us/articles/115003340723 (new as of today)

Link to Slack archive of meeting: https://wordpress.slack.com/archives/C02RP4X03/p1500311213351043

#accessibility

Team Chat Summary August 31, 2015

Headings

More work is being done on headings in admin. Jeffrey de Wit created some tickets some of which are already patched and committed. Follow the headings discussion in #accessibility on Slack.

Handbook

Devised a strategy for building out the Make WordPress Accessible Handbook. Page leaders will help others build out the handbook.

Twenty Sixteen

Twenty Sixteen is on Github. Twenty Sixteen is also available in the theme directory. It’s not in trunk yet. According to David Kennedy ” I did a accessibility-ready review before it went on Github and the directory to make sure nothing was way off accessibility-wise. It’s solid. Takashi knows the drill.” We will ask the testers to test it. David Kennedy did an #accessibility-ready audit of Twenty Sixteen.

Select2

We continued a discussion about Select2 as an alternative to the autocomplete/tagging input field types. There are two main accessibility issues: it doesn’t do a good job of providing feedback to screen readers and it requires the ‘enter’ key to begin typing for autocomplete, a non-standard interaction. The testers have tested Select2 and it is not very accessible. Rian Rietveld will collect all the data and report next week.

WordCamp US

Several of us are submitting proposals for talks at WordCamp US and depending on funding assistance some of us will be attending. Today is the last day for submitting proposals.

#accessibility-team-meeting, #team-reps

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