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

This week in WPA11y – July 24, 2017

Transcript of meeting.

The discussion of the handbook was punted to the July 31st, 2017 meeting, as @samikeijonen was unable to attend this week’s meeting. As this discussion was originally intended as the primary focus of this week’s meeting, the entire meeting was open floor, with no agenda.

Topics discussed

Gutenberg: block output

@afercia recommended we set up a test to review the output of all Gutenberg content blocks, as many of the new block types generate different output than the equivalent in the existing editor, such as the image gallery block.

@rianrietveld requested that @afercia create a post for testing that contains all relevant options.

We determined that we need to first perform an expert review of the general issues, request modifications as necessary, then gather user feedback once any major errors have been worked through.

The team briefly discussed the reasoning behind creating content blocks that generate features that exist in the current WordPress ecosystem using different output HTML; further conversation on this topic should probably land in relevant Gutenberg issues.

Gutenberg: user testing

@nicbertino volunteered to manage moderated user testing for Gutenberg, to start with general user testing, then proceed to specific testing with users requiring assistive technology.

#weekly-meetings

Revising the WordPress Editor: Gutenberg and Accessibility

One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an accessibility perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its core mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

Fundamentals of Accessibility to Consider

  1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
  2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
  3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content block); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

Help develop the new editor

If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.

#gutenberg

WordCamp Europe Summary

The WordPress Accessibility Team at WordCamp Europe. Left to Right: Joe Dolson, Andrea Fercia, Rian Rietveld, Graham Armfield, Mike Little, and Morten Rand-Hendriksen

The WordPress Accessibility Team at WordCamp Europe. Left to Right: Joe Dolson, Andrea Fercia, Rian Rietveld, Graham Armfield, Mike Little, and Morten Rand-Hendriksen

On June 26th, the contributor day for WordCamp Europe, several of the members of the accessibility team were able to meet and address a variety of issues. It was a great opportunity to try and pin down some long-term problems and strategize for the future!

During the event, we:

  • Taught several theme developers and reviewers the process of testing themes for the accessibility-ready tag
  • Worked with the Design team to finalize solutions to a couple of nagging issues in communicating information formerly only available in title attributes
  • Discussed some of the problems in the theme review workflow that relate to the accessibility-ready tag and brainstormed ways of handling them
  • Discussed ideas for increasing the automation available for doing accessibility-ready testing of themes
  • Prepared patches and worked through a number of open tickets in the accessibility queue
  • Gave a great workshop on keyboard accessibility
  • Promoted increased participation in preparing subtitles for videos on WordPress.tv
  • Worked on improving the accessibility of the WordPress core tags widget
  • Discussed improvements to Contact Form 7 with @takayukister
  • Met and talked to more people interested and excited about accessibility in WordPress!

The opportunities to work together at great events like WordCamp Europe are priceless; big thanks to the WordCamp Europe team for all their hard work!

Accessibility Wish List for 4.6 and beyond

Following the example from development on the WordPress Editor, the accessibility team is going to start posting our goals in wish list format. If you have an accessibility goal you’d like to see the team pursue on WordPress core, add it in a comment and let us know!

Current Accessibility Goals

  • Color Contrast: coordinate with the Design team to finish the colors. See #31713, #35659, #35596, #35622. (@afercia)
  • Settings API: collaborate with the team working on the Fields API to make sure they’re fabulously accessible. See #18801 for history, Fields API development (@joedolson, @afercia)
  • Uniform Search: Work to address the numerous different search interfaces within the WordPress admin so they offer the same experience through the admin. See #31818. (@cheffheid)
  • Develop libraries for Accessible Tabs & Accessible Modals
  • Accessible Video: improve the user interface and meta data relationships for captions & subtitles to make accessible video easier to manage. See #31177. (@rianrietveld)
  • Accessible Media Grid
  • Review usage of target=”_blank” in the admin. See #23432. (@trishasalas)
  • Finish headings improvements: remove controls from headings. See #26601. (@trishasalas)
  • start accessibility work on Select2. See issue 3744 on Select2. (@afercia)
  • Finish working on an accessible Tag Cloud Widget. See #35566.

#4-6, #goals, #wishlist

Team Meeting 3/21/2016

Our team meeting for today focused primarily on goal setting. As we’re nearing the release candidate stage for WordPress 4.5, it’s time to move our attentions forward to the future again.

Coming out of 4.5, we know that while we’ve made a lot of progress on our top issues for that release, there’s still a fair amount of work to do, so we’ll be trying finish off the top issues from 4.5: color contrast audits and resolutions and the continuing removal of title attributes. Most of these questions require some significant design decisions, so we’ll be working closely with the design team to get these accomplished.

Moving forward into 4.6, we want to start work on making the internal search functions inside WordPress more consistent. We also need to tackle a few thorny problems in the media management UI.

Looking further forward, we’re going to start developing some libraries to create accessible modal dialogs, accessible tabbed interfaces, and accessible tooltips for eventual inclusion in WordPress core. The goal is for these to be available for theme and plug-in developers to use as well as for use within the core, so that everybody developing in WordPress can easily generate these types of user interfaces easily and accessibly.

Review the meeting at Slack

#4-6, #goals, #meetings

Accessibility code standards for WordPress in draft

The accessibility code standards for WordPress have been added to the core handbook and are open for feedback over the next two week. Also see the Core blog announcement and the draft standards themselves!

#core-2, #development, #standards

Updates to WordPress theme accessibility guidelines

The accessibility-ready guidelines for WordPress themes were updated today. There are no explicit changes to the requirements, but the order of the guidelines has been changed so that it corresponds more effectively to how it makes sense to run tests on the guidelines.

Additionally, I’ve added some information on how to run tests for each guideline into the guidelines, so that theme developers are more easily able to find information on how to self-test when they’re creating an accessibility-ready theme.

Review the guidelines.

#accessibility-ready, #themes-2

Congratulations to Andrea Fercia on gaining guest committer…

Congratulations to Andrea Fercia on gaining guest committer privileges for the WordPress 4.4 release cycle! This is great news for WordPress and accessibility!

Accessibility Priorities for 4.3

For the development of WordPress 4.3, we’ve got a handful of major issues we want to work on to create a smoother and more predictable experience for users with disabilities.

Reconcile Heading hierarchy throughout admin & clean-up heading contents

#31650: Missing H1 headings in admin (fixed)
#26601: Inappropriate content in headings on admin screens.

Use Semantic elements for non-link links

Tracking ticket: #26504
Individual tickets (so far): #31487, #31476
Related: #26550

Reconcile search methods

WordPress incorporates 5 different search interactions in the admin. For usability, accessibility, and maintenance reasons, this should be made more uniform. We’d like to see this reduced to two basic interactions.

#31818 Uniform Search Form Display/Experience

List table issues

We gathered a ton of data on the List table navigation experience during 4.2, and those are being turned into tickets.

#32028 List table pagination: text improvements for screen readers (fixed)
#32150 List table: better indication for “no taxonomy” (fixed)
#32152 List table: Comments column accessibility improvements (fixed)
#32147 List table: headings for pagination and views links
#31654 List tables: Select All shouldn’t be a column header (fixed)

Color contrast issues in admin:

#31548, #31713, #28599

Improve editor experience:

The editor is the single most frequently used part of most WordPress installations – and the experience with this interface should be more consistent.

#29838: Editor focus order issues.

Throughout the cycle, we’ll also be picking away at the dozens of other smaller tickets we want to fix, but these are large issues that will have a deep impact on WordPress, and will require a community effort to make progress.

#4-3-early, #core-2, #priorities