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

Accessibility Team Update: February 11, 2015

Testing

We had a report by Rian Rietveld on testing results. Things are going very well. Rian said: “I’m getting test results back on the tab order of the post table, it seems to work ok, but they found a ton of other problems, I have to check the current tickets and open new if necessary.”

Pattern Library

David Kennedy told us that the repos are set up for contributions to the theme pattern library. See the Accessible Theme Pattern Library Update for February for more info.

Core Discussion

Andrea Fercia reported on a discussion he had with the Core team. He asked about menu bar admin focus and non-link links (28599 and 26504). Joe Dolson said “the link/button question really requires specific cases; I’m not sure how we could approach giving any kind of global comments on the topic.” Andrea said that he also updated the Core team about the first testing round on customizer theme switcher.

Theme Checking

Joe Dolson updated us on the state of checking themes requesting the accessible-ready tag.”We’re now up to 29 live themes carrying the accessibility-ready tag which have been tested and passed. There’s one outstanding theme live that does not pass (_tk); it’s undergoing the review process now, and will either be suspended or updated soon.I’ve got two pending theme reviews to do, and know of at least 1 theme that’s currently approved and waiting to go live.”
Joe has also trained two of the theme review team admins on reviewing for accessibility. Additionally Joe has shifted support for landmark roles into a required feature for accessibility-ready themes, rather than recommended.

Landmarks

Discussion turned to the over-abundance of landmarks. The current proposed code (#23089) outputs too many landmark roles. A theme may add numerous landmark roles without the ability to control where and how many there are. Andrea noted “currently, _s outputs one aside (mapped to complementary) for each widget, nested inside a general complementary area for widgets.” Jared Smith of WebAim recently said “Easy accessibility check: Search for “role” in source code. If 0 instances, probably bad. If 1-20, probably OK. If greater than 20, definitely awful.”

Other Items

Morten Rand-Hendriksen asked: “What is the best tool for computer voice control (in particular, voice controlled browsing) on both Windows and MacOS? Are there any workable free tools or are we confined to things like Dragon?” There is a demo mode in JAWS and NVDA is free. If there is a free way for developers and designers to experience things using voice control it will help them understand the issues better.Sam Sidler noted that “OS X has voice control built-in, so I’d call that free, but not open source-level free.”

We finished off by discussing Shiny Updates (see ticket 29820 now landed in core). According to Andrea Fercia there are two main accessibility issues:

    • focus handling
    • absolutely no feedback for screen reader users when an install/update action starts, ends, fails, etc.

About the latter issue Andrea said “I’d like to propose a solution based on Graham Armfield’s idea (see #28892) but done in a way that it would hopefully be a useful tool for developers.”

The entire conversation from February 11 is available in Slack archives for the #accessibility channel.

#accessibility-team-meeting, #team-reps

Accessibility Team Update: August 27, 2014

Weekly Testing Meeting

For the last two weeks we’ve been trying something new, a weekly accessibility testing meeting, 17:00 – 19:30 UTC. We meet in the wordpress-ui IRC channel to share our tests. If you want to join in or just see what we are doing just show up in the IRC channel. Read the logs for August 18 and August 25 to get an idea of what we are doing.

#accessibility, #team-reps, #weekly-updates

Accessibility Team Update: March 26, 2014

Meeting Time Change

We will be going back to a meeting time of 19:00 UTC next Wednesday, April 2.

Progress

The meeting this past Wednesday was interesting. Now we’re getting to the heart of the matter.

So far, we have compiled a keyboard-only report on most of 3.8 and have some data to rely on.

The first pattern we identified from the testing is poor visual keyboard focus in the Admin. Rian created a ticket dealing with keyboard focus. Better visual indication of focus on elements in the Admin (#27173). This ticket is now closed (fixed.) Thanks Rian!

Testing 3.9

We have to quickly change gears because 3.9 is due out in 18 days and we have to test and create tickets where we find issues. A list of items to concentrate on will help guide us.

Contact @AccessibleJoe for details if you want to help test 3.9.

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