Accessibility team meeting, April 23, 2018

Transcript in Slack

Meeting notes

Time for next meetings

We picked a new time for the weekly a11y bugscrub and team meeting:

During the daylight saving time (as in now):

  • Accessibility bug scrub: Wednesday 14:00 UTC
  • Accessibility Team meeting: Wednesday 15:00 UTC

Starting next week, May 2, so the meeting on Monday 30th will be cancelled.

Handbook

After the handbook is sort of finished we want to maintain it via GitHub. That way more people can contribute or file issues. @nicbertino will help migrating the content we have now to GitHub and we are looking for an easy way to push the GitHub pages back in the handbook pages on wordpress.org.

Kudos to WPTavern for publishing a post about the handbook and the need for help.
At the moment we don’t need writers, but we desperately need reviewers with knowledge of accessibility and native English speakers to go through the pages on Best Practice we have published or are in draft on Google Docs.

@samikeijonen will post a series of tweets on @WPAccessibility to promote finished content in the Best Practice section. Which already gave discussion on Twitter, so that works well 🙂

Gutenberg

AT WordCamp London @karmatosed joined the a11y table and we discussed the issues on GitHub that have priority.
They are 13 issues labeled Accessibility and Milestoned Merge proposal: Accessibility. Some are also labeled High Priority.
@abrightclearweb researched the blocks – keyboard interaction (Tab, Shift+Tab) and added that info to the issue Simplify and streamline keyboard navigation through blocks.

These issues need to be worked on. The team is worried those issues can not be addressed before the merge proposal.

#weekly-meetings

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.

 

#weekly-meetings

This week in WordPress Accessibility, March 12, 2018

We had four items on the agenda:

  1. Handbook.
  2. Gutenberg and accessibility requirements.
  3. Visual change on hover for a link.
  4. Open floor.

Read the full transcript in Slack.

Handbook

Accessibility handbook is going forward little by little. Here are couple of newest articles:

Next steps also include marketing plans for the handbook. The idea is that people would actually know about the handbook 🙂

Gutenberg and accessibility requirements

We have been talking about accessibility requirements in Gutenberg. We now have nine items in the list, last three was added todays meeting.

  1. Keyboard navigation through blocks needs to be greatly simplified and streamlined. See the experiment with navigation mode / edit mode.
  2. For some components, there’s the need to constrain tabbing within the component (i.e. they should behave like “modals”).
  3. The publishing flow needs to be simplified, currently its accessibility is terrible.
  4. Everything needs to live inside the landmark regions.
  5. Text mode: a simple textarea is the only guarantee to enable users to publish content, regardless of the device / technology they use.
  6. Write documentation for keyboard and screen reader users.
  7. Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick, see issue #3218.
  8. Use a `role=”textbox”` for all the Editable elements, see issue #3412 and issue #4074.
  9. Block toolbars position counterintuitive for keyboard users, see issue #3976.

We would like to get these implemented before merge proposal.

Update March 13: We also talked about the issue where adding a post title is hard using speech recognition software. There is PR for adding aria-label to post title, which needs testing.

Visual change on hover for a link

We discussed should links have visual change on hover. There were two use cases to investigate.

  1. Vanilla link: <a href="#link">This is link</a>
  2. Link with image: <a href="#link"><img src="test.png" alt="testing image inside link"></a>

For item one we already have a guideline that main content links needs to be underlined. Without CSS browsers only have cursor pointer on hover. See the screenshot below.

link have cursor pointer by default on hover

We agreed that there is no need for visual change on hover, as it follows browsers native behaviour. But from a usability point of view extra visual change can be helpful. For example removing the underline.

Item two (image inside a link) use cases are for example gallery or feature image linking to post. We agreed that images don’t need underline or border. But on hover change we recommend same styles as on focus, like outline styles.

There are couple of examples how to deal with feature image linking to post:

  1. Put image inside the same link as post title.
  2. Ignore some of the links at least for keyboard users.

We were also joking around as usual: Surround the image with marquee text “Click the image”.

Open floor

@postphotos (Leo Postovoit) had his first ticket and patch about what captions means for video. Congrats!

@afercia (Andrea Fercia) made the “Available Widgets” section operable with a keyboard. Also, the link to the “Accessibility mode” is now available to all users.

enable accessibility mode link visible

There should be a game called things you didn’t know about WP admin.

#weekly-meetings

This week in WordPress Accessibility, March 5, 2018

WPa1y team meeting

Transcript in Slack

Handbook

Work goes well. @samikeijonen is working on a post about SVG, @rianrietveld is writing about wp.a11y.speak().

Gutenberg

Requirements

We discussed the accessibility requirements for Gutenberg, before merging into core.
@afercia proposed

  1. Keyboard navigation through blocks needs to be greatly simplified and streamlined. See the experiment with navigation mode / edit mode.
  2. For some components, there’s the need to constrain tabbing within the component (i.e. they should behave like “modals”).
  3. The publishing flow needs to be simplified, currently its accessibility is terrible.
  4. Everything needs to live inside the landmark regions.
  5. Text mode: a simple textarea is the only guarantee to enable users to publish content, regardless of the device / technology they use.

We agreed on one extra:
6. Write documentation for keyboard and screen reader users.
Andrea opened a GitHub issue for this: User guide and keyboard shortcuts documentation

Testing

Andrea asks for more people to test the accessibility of Gutenberg.
Rian wrote a test set for this (Gutenberg accessibility testing) and she did an initial test with keyboard only.: Keyboard test Gutenberg, a first try.
The plan is to ask testers from the wpa11y test team to do this test too and so discover more issues. We plan to have a large a11y test session at the contributor day at WordCamp London.

Items on the To-do list

  • Add a page in the handbook about which screen reader / OS / browser combinations to use
  • A11y test Gutenberg (@everyone)
  • Investigate and screen reader test the use of a navigation landmark inside header landmark
  • Research screen reader performance for code short codes like [ php ] or [ html ]
  • ATAG statement (@joedolson)
  • WCAG statement (@rianrietveld)

Good reads

#weekly-meetings

X-post: Recap of WordCamp.org ticket scrub on November 21st

X-post from +make.wordpress.org/meta: Recap of WordCamp.org ticket scrub on November 21st

This week in WordPress Accessibility, November 20, 2017

Weekly meeting

Transcript meeting in Slack

The handbook

Things go well, we are adding new content every week on the handbook – best practices.
@mercime will help with the documentation, starting with forms.

Gutenberg

There are improvements made to the keyboard navigation, specifically the inserter. This is still work in progress. The top toolbar has now arrow navigation too.
@samikeijonen requested a review for his pull requests on GitHub.

Test server

Nimbus hosting sponsors our team with a dedicated server, where we can install trunk and patches using SVN and Git. At the moment we do not use this server much.
The question is: do we still need it and and will we use it in the near future?

After a discussion we concluded: Yes we need it and we will use it more for testing in the future. The team requests test and Rian will do the installs, mail the testers and report the results.

WCAG 2.1 AA

Rian will write a post this week about what is new in WCAG 2.1 AA for the designers and developers.

One of the new requirements is a minimum size for the a link/button.
@afrecia added new a11y keyword target-size on Trac.

Accessibility news / good reads

#weekly-meetings

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