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

Change of the day and time of the Accessibility Team Meetings

We picked a new time for the weekly accessibility bugscrub and team meeting, so more people can be present and less people will be very hungry:

During the daylight saving time (as in now):

  • Accessibility Bug Scrub: Wednesday 14:00 UTC
  • Accessibility Team meeting: Wednesday 15:00 UTC

We’ll adjust the time after the daylight saving period, so the meetings stay on the same local time.

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

#weekly-meetings

New time/date for the wpa11y meeting in Slack?

We want to set a new time and maybe new date for the wpa11y meeting in Slack.
Please add your suggestions in the comments below.

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

The WordPress project now has…

The WordPress project now has an official accessibility statement:
wordpress.org/about/accessibility/

Accessibility of Gutenberg, the state of play

TL;DR

How accessible is Gutenberg in its current state (version 2.4)? To answer this the Accessibility team set up a list of minimum requirement, did code reviews and research, gave recommendations and set up user tests.

The short answer is:

  • Gutenberg still needs extensive work to meet basic standards, like keyboard accessibility and semantics
  • Especially for screen reader users, Gutenberg as it stands right now is a dramatic step back in usability
  • We need to write a manual/documentation for assistive technology users

From the start

During development, almost from the start, Andrea Fercia (@afercia) did extensive a11y (accessibility) testing and research. He and others created issues labeled accessibility on GitHub to address the issues found (Andrea created more than 50 of them).

At the moment 70 a11y issues are open, 166 are closed. A lot has been addressed, but there are still very important issues open (like for keyboard accessibility, tab order and navigation).

User testing

When Gutenberg 2.3 was released, Tammie Lister (@karmatosed) considered it ready enough for a complete accessibility test.

We wrote a user test, that includes the basic functionality needed to publish a post. Like add a title, headings, paragraphs, a list, a table an image and a video, use the block options and publish.

On our testserver wpaccess.org we installed the plugin, version 2.3, and gave our a11y test team access. Joe Dolson also recruited accessibility experts for a test of version 2.4 at the CSUN conference. All results are reported in the Google spreadsheet Gutenberg a11y test results.

So far we’ve got good quality test results for

  • Keyboard only
  • Dragon Naturally Speaking
  • VoiceOver / Safari
  • NVDA / Firefox

Andrea created new GitHub issues from the reported problems or added extra information with the already reported ones.

Videos with user tests

Note: These users (Eric Wright and Sina Bahram) are leading accessibility experts, using their assistive technology on a daily basis and using WordPress for their work.

 

Minimum requirements before merge

To set a baseline, what should be fixed before merge we set up a list of requirements:

  1. Keyboard navigation through blocks needs to be greatly simplified and streamlined
  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. Block toolbars position counter intuitive for keyboard users, see issue #3976
  9. The Date picker must be keyboard accessible

Severe issues

One of the most severe issue is the keyboard accessibility. The keyboard tab order is unpredictable. The tab order for and backwards is not the same. Publishing a post is a puzzle and the date picker is unreachable with a keyboard only.

Another issue is the need for quick navigation tools, like shortcuts and better use of landmarks and headings. There are so much more actions to take for adding or modifying a block. Compared to the current classic editor, publishing a post with a screen reader takes much more time and effort.

Because the extensive use of icons, voice recognition users have to guess the accessible names for buttons to activate them. This needs a design decision.

Actions to take

  • Fixing the keyboard accessibility and screen reader navigation is a high priority. Andrea opened issues for this and we need to prioritize these
  • At WordCamp London and Europe we will do extra user testing with assistive technology and discuss the results with Tammie Lister and the Gutenberg developers present
  • The accessibility team needs to take responsibility for the manuals and documentation. This documents only can be written after the minimum requirements as listed above are met

#accessibility-usertest, #gutenberg

Accessibility team meeting, March 26, 2018

Gutenberg testing

@joedolson was at then CSUN conference last week and asked Léonie Watson and Sina Bahram to have a go at the Gutenberg test. Both are internationally recognized experts in web accessibility, WordPress users and highly experienced both at testing applications and coding.

Test results

Leonie Watson found the system extremely difficult to use. She currently runs her own WordPress site, and has for many years, so her starting assumption was to expect her past knowledge to be useful, and to attempt to use it as a standard page.

Sina Bahram immediately assumed that Gutenberg was an application, and should be operated as one, but found it frustrating that this turned out to only sometimes be true. Strongly suggested using the application role so that interactions would be more predictable. Video of Sina’s session (20 min)

One comment that both users made specifically was that they “didn’t trust” the focus management, and both elected to try alternate methods of navigation (link nav, heading nav, find in page) specifically because they didn’t trust that tabbing would take them where they expected. The most problematic issue there was the block menus having different forward and backwards action.

Both users also attempted to search for help at some point, feeling that there should be some kind of instruction to inform them how the interface worked, but did not find any.

Unpredictability is one of the biggest enemies Joe saw in these tests. Users got frustrated not knowing where their next interaction would go.

CTA

During the meeting we discussed use of role="application" and role="textbox" and we will do an A/B test on the test server to see if that makes the interface better usable for the combination Firefox & NVDA.

We will publish a post this week summarizing all test results and the work that needs to be done on Gutenberg before merge.

Underlining of links in the content

In new committed code, there is no underlining for links in text blocks. But according to WCAG: links must stand out in the text, not by colour alone. To prevent this from happening this should be added to the Accessibility Coding Standards for WordPress Core. This was also added earlier to the Theme Guidelines.

@afercia added the required underlining text to the Accessibility Coding Standards for WordPress Core.

#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

This week in WordPress Accessibility, February 26, 2018

Transcript of a meeting in Slack.

About placeholders

In ticket 40460 there is discussion should placeholders be added to wp_login_form(). @afercia have written good summary in the comments why in this case placeholders would not be a good idea.

Therefore we decided to close the ticket. But discussion can continue in the ticket and valid use cases are welcome.

Handbook status update

First of March was our first deadline. We are not going to make it but we are progressing OK. We have marketing plan what to do after basic articles have been written.

List of must-have accessibility fixes in Gutenberg for version 1

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

We need to start testing more and open actionable issues.

Open floor

We ALL love snow and gold weather! ☃️❄️🌬

#weekly-meetings