Accessibility Team Meeting Notes: September 18, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Update on WordPress 5.6 goals

Updating coding standards to WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.1

The team quickly discussed about the formulation of the WordPress accessibility coding standards.

All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.0 at level AA.

As it doesn’t imply the Community needs to revise the entire WordPress codebase before upgrading from WCAG 2.0 to WCAG 2.1, the team agreed that the first step could be to simply change the number. Such change would be matched by a post on the Make blog with a quick explanation about the implications of such a change. @joedolson opened a pull request on the WordPress Coding Standard repository to upgrade to WCAG 2.1.

The scope of accessibility related documentation will be broadened and will include:

  • an introduction about accessibility guidelines, including links to normative and informative resources by the Web Accessibility Initiative of W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/.;
  • a list of authoritative resources (in line with the indications from the documentation team about the external linking policy);
  • a list of anti-patterns that should be avoided inside WordPress;
  • a list of patterns that should be followed inside WordPress;
  • (optionally) a guide to test patches for accessiblity issues before merging.

Discussion about the new accessibility coding standards can continue in the #accessibility-docs channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (requires registration); feedback can be added to the new accessibility coding standards draft and to the new accessibility testing guide draft.

Twenty Twentyone

Development of the new WordPress default theme is ongoing. A discussion about the links style happened during and after the meeting in a thread on Slack, the menu hasn’t been worked on yet.

The GitHub repository for Twenty Twenty One was made public in the week after the meeting and some members of the team are working on it and looking for possible accessibility issues.

Accessibility statement feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

Developement of the accessibility statement pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is underway. As reported by @sarahricker, at the moment there are two versions of the plugin.

  • The first version generates an accessibility statement using the exact same questions from the W3C accessibility statement generator and stores answers in the WordPress database, so that the statement can be regenerated with ease every time it needs to change.
  • The second version (which is currently at a Minimum Viable ProductMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia stage) aligns more closely with the acceptance criteria and mimics the Privacy Policy functionality currently in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The accessibility statement plugin repository is public and all people interested can give their contribution.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project board

A couple of days before the weekly meeting, the WordPress 5.6 milestone in the Gutenberg repository was deleted in favor of a GitHub project to track WordPress 5.6 must haves and all issues in the milesone have been moved to the new board.

To ease the workload from the few team members with triage status in the Gutenberg repository, the team agreed to ask those permissions for @sarahricker, @joedolson and @ryokuhi, given that they are already bug-gardeners or committers to WordPress core.

Sidebars accessibility in Gutenberg

Following last week’s discussion, further considerations about sidebars in Gutenberg were made. Here is a summary of the key points.

  • A sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. is a layout model, not an interaction one: an element can be described as a “sidebar” because of its visual aspect, but not because of how users interact with it. A direct consequence is that there is no suitable, expected, semantic pattern that can be followed to implement all sidebars: each of them should be considered case by case.
  • It might be helpful to create a document collecting all the interface sidebars, so that issues and progresses related to each of them can be tracked more easily.
  • The complementary role and the aside element define landmarks: these are navigational tools that can be used to navigate easily between fixed sections of a page. As such, the complementary role can’t be used for components that slide in and out.
  • A possible alternative to sidebars might be to add more alternative modes, like the current “Edit” and “Select” ones. For example, to reorder blocks there could be a “Reorder” mode that transforms the editor canvas in a simplified list with mover buttons.

#meeting-notes