DevChat meeting Summary – May 5, 2021

Agenda for the two meetings. Thanks to @peterwilsoncc and @jeffpaul for leading the 05:00 and 20:00 UTC devchats respectively.

Link to 05:00 UTC devchat meeting archive in Slack // Link to 20:00 UTC devchat meeting archive in Slack

Announcements and news

These posts need your feedback:

  • @ryokuhi published a proposal on Make/Accessibility about a new Trac workflow keyword that 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 would like to consider.  If you feel particularly opinionated or passionate about this, please comment on the post.
  • @jeffpaul and @desrosj published a request to Component Maintainers, Feature plugin authors, and the Gutenberg team to share plans / help needed for 5.8 (primary focus will be FSE).  Please comment on the post to help ensure we’re tracking the right work for the release.
    • @youknowriad noted that required Gutenberg changes in Core are made as filters/extensions points and brought to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as part of the 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/ merge that happens regularly
    • @mkaz shared the WordPress 5.8 Must Haves project board on GitHub as outline of Gutenberg work for 5.8

5.8 Review

  • Schedule confirmed including bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub schedule
  • @youknowriad shared that trunk is already on Gutenberg 10.4, @gziolo is working on updating it to 10.5 and the big changes (Global styles infrastructure in themes.json and FSE blocks) are coming in 10.6
  • Feature freeze on Tuesday May 25th (19 days from now) defined as “During the following two weeks, there will be no commits for new enhancements or feature requests. Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. will focus on defect work (aka outstanding bugs)
  • BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 on Tuesday June 8 (33 days)
  • RC 1 on Tuesday June 29 (54 days)
  • Release on Tuesday July 20 (75 days)
  • Current list of tickets that are on the 5.8 milestone, list of good-first-bugs tickets

Component maintainers and committers update

  • @sergeybiryukov shared Plugins update that Parameter names in 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. functions now use consistent terminology when referring to actions, filters, and callback functions via #50531
  • @sergeybiryukov shared Themes update that #49487 removes the “Featured” tab on Add Themes screen to match an earlier change in the Theme Directory
  • @webcommsat shared About/Help update that ticketticket Created for both bug reports and feature development on the bug tracker. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. continues with @marybaum
  • @audrasjb shared Menus update that #21603 is being reviewed
  • @audrasjb shared Upgrade/Install update that the last meeting recap includes a project for the next few releases

Open Floor

Props to @audrasjb, @webcommsat and @marybaum for reviewing this post.

#5-8, #accessibility, #dev-chat, #docs, #fse, #full-site-editing, #github, #learnwp, #summary, #updater

Discussion summary: Dropping support for IE11

As a follow-up to the very active discussion around the proposal to drop support for IE11, there is a majority agreement to move forward with dropping support. The next steps are to figure out a timeline and what it means for projects/teams to drop the support.

Regarding timeline, there are two upcoming milestones where support could be dropped: 5.8 and 5.9. The argument for dropping in 5.8 is to realize the change and improvement quicker, while others are inclined to wait until 5.9 to provide a longer window between the official announcement and the effective date.

The decision when will be left to the release team for WordPress 5.8; this team is not formed yet as it depends on the April go/no-go Full Site Editing merge.

This post was written in collaboration with @mkaz, @annezazu, and @youknowriad.

#accessibility, #browser-support, #performance

Discussion: Dropping support for IE11

After digging into data and reviewing previous decisions around browser support, this is a proposal to define a policy to stop supporting Internet Explorer 11 (IE11) now that usage has cumulatively fallen below ~1% across three metrics. 

Current state of IE11

As of February 25th 2021, IE11 usage has cumulatively fallen below ~1% according to three sources of metrics:

  • 0.71% from StatCounter’s GlobalStats.
  • 1.2% from W3 Counter.
  • 0.46% from WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.

For comparison, the numbers above are very close to the data used to make a decision in 2017 to drop support for IE versions 8, 9, and 10. It’s important to keep in mind that when viewing these statistics in the context of WordPress, these percentages represent tens (if not hundreds) of thousands of users that could potentially be left behind if support for IE11 is dropped. 

In August 2020 Microsoft themselves announced that Microsoft 365 and Teams apps would stop supporting IE in the upcoming months. However, given that IE11 is a component bundled with Windows10, according to the IE Lifecycle it will still receive security updates as long as the Windows version it was shipped with continues to receive support. 

In terms of the current WordPress user experience, a flag was added to not recommend IE in BrowseHappy about 13 months ago, so by now, most WordPress users should be aware. Tied to this, the experience overall is not optimal in IE11 with a high cost of maintenance for developers.

Proposed Policy

The proposed policy for WordPress is to end Internet Explorer 11 support. This was discussed most recently in the February 24th Core Editor Chat and briefly during February 23rd JavaScript office hours in 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/.. More context and discussion have been shared over time in this original Trac issue that seeks to determine clear guidelines around what absolutely can’t be broken in order to help identify development and testing needs. 

Benefits

Dropping support would result in smaller scripts, lower maintenance burden, and decrease build times. For instance, a recent exploration by @youknowriad demonstrated that not transpiling the scripts to IE11 immediately resulted in a net reduction of nearly 84kB in the 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/ JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. built files, representing a 7,78% total decrease in size; these scripts have seen a size contraction up to 60%, with an average reduction of 24%. This is a result of heavily relying on transpilers, further explained by Jason Miller, Web DevRel at Google. Moreover, dropping support would ultimately make WordPress’ currently included polyfill script obsolete, decreasing the enqueued scripts size up to 102kB more.

The smaller downloads would positively impact all users, especially those on slower networks, or computing devices. We expect a result of dropping IE11 support to improve performance for the vast majority of users. 

Potential Concerns/Blockers

TLDR: The concerns are for those who are unable to upgrade, like financial institutions and education sectors, and those who rely on IE11 for screen readers. 

There are major institutions like banking, government, and education that are unable to control when they can upgrade sometimes due to legal requirements, depending on the country. This further underscores the need to determine a policy that takes into consideration both a data-informed approach and the impacted user bases while weighing the potential benefits for the wider web. 

According to a September 2019 WebAIM survey, IE11 is still used as a browser among screen readers with 11.5% share. This is an older survey and IE11’s global share was 2.9% at the time the survey was done according to the sources linked above. It takes time for screen reader software to support newer browsers and the latest versions of popular screen reader NVDA have continued improving and adding support for the Edge browser. As a result, this post embraces an assumption that IE usage among screen reader users has declined since the survey as the software improves and overall usage of IE11 has declined. Please let us know if this assumption is or if there is better data available to refer to.

Keep in mind that there are ways to patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. gaps in functionality that’s determined critical to maintain for a time. This post does not seek to go into technical implementation details though.

Share your feedback about this proposed policy change to drop support by March 18th

This is a tough decision to make and we want to solicit feedback from as many voices across the community it may impact. Please note, this post is not meant to go over any technical fallbacks at this time but to purely discuss the policy of dropping support. 

Once we’ve gathered feedback, the next step will be to consolidate and decide the policy. The actual technical implementation of the policy is most practical to pursue across the numerous WordPress projects. 

Thank you to @mkaz, @annezazu, @youknowriad, @desrosj for help writing and reviewing this post. 

#accessibility, #browser-support, #performance

Core Editor Improvement: Video Subtitles

While some people might think of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor as being focused on the writing experience, it’s so much more than that, especially with what’s now possible thanks to numerous core blocks and the future site editing world. This post is about one of these new content tools that you might have missed in the last few months of recent releases: the ability to add video subtitles. With more and more people venturing into the video space thanks to them being easier than ever to create, this new feature packs powerful capabilities for content creators and their viewers alike. 

To take advantage of this new feature, just upload a video and use the Text Tracks setting to upload your subtitles as shown below: 

The Text Tracks setting options now included in the Video BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience..

People viewing your site can enable captions through the settings of the video player. Here’s a screenshot of a video with captions on to get a sense of the experience: 

Example of a paused video with subtitles enabled.

Now you can engage with your audiences so they can catch what you’re up to whether they might have limited hearing, don’t want to wake a sleeping baby/pet/person nearby, or prefer reading along while watching your video. Happy creating! 

If you’re interested in working on features like this, make sure to join #core-editor, check out the current focuses, and attend the Core Editor weekly meeting @ 14:00 UTC in core-editor. 

#core-editor-improvement #core-editor #accessibility

Core Editor Improvement: Text Only Icons for the Toolbar

A lot of work has been done to improve the infrastructure of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor and expand what’s possible technically. It is also important to pause and highlight improvements that make creating with the core editor easier than ever before. This post seeks to highlight one of those recent features that might have been missed in the flurry of recent releases: the ability to have descriptive text icons instead of an icon only view of the Block Toolbar. Since the Toolbar is currently one of the main ways we all interact with the Core Editor this is a big change that should have big benefits. Text icons unlock the ability for you to tailor your experience of the Toolbar and helps more people have the flexibility to create with the Core Editor. In particular, these icons improve settings from an 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) standpoint for those relying on tooltips.

To get a sense of just how much of a difference this makes, check out the following screenshots showing the different options available: 

Icon Only: 

Icon Only view in the Core Editor Toolbar

Text Only: 

Text Only view in the Core Editor Toolbar

How to find this option

Here’s a helpful GIF that illustrates where you can easily find this setting in the Options menu under the Appearances section:

Settings can be adjusted under the Options menu in the Appearance section by toggling “Display Button Labels”.

Try out both and see which works best for you. If you’re like me, you might find times when it’s helpful to use each. Perhaps you’re teaching someone about the Core Editor for the first time, and they find the text-based options easier to understand! Or, you are trying to write a lengthy post and find Icon Only to feel less distracting. No matter the circumstance, the option is there for you to experience the toolbar in the way that works best for whatever you’re trying to do. 

If you’re interested in working on features like this, make sure to join #core-editor, check out the current focuses, and attend the Core Editor weekly meeting @ 14:00 UTC in core-editor. 

#core-editor-improvement #core-editor #accessibility

What’s next in Gutenberg? (November)

This is a monthly update containing the high-level items that 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/ contributors are focusing on for November. Please join us in our efforts and let us know in the comments if anything is blocking you from contributing. 

Ways to follow along with Gutenberg development: 

Here’s an overview of ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development related posts and a Site Editing Milestone overview issue that breaks down the upcoming work into focus areas. 

Preparations for WordPress 5.6

The WordPress 5.6 Must Haves project board includes issues that need attention in preparation for the WordPress 5.6 release. Many contributors will be spending the month of November working on bugs and regressions to be fixed for inclusion in WordPress 5.6.

A number of issues have been labeled for Dev Notes. A dev note is a blogblog (versus network, site) post, published when a technical change that developers may need to know about will be included in the next WordPress release. Dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. are typically published along with the first Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). which is currently scheduled for November 17, 2020.

Full Site Editing

Work on this major focus for phase 2 is an ongoing effort and is expected to continue iterating over the coming months. For November, priorities are being evaluated in order to identify next focus areas for Full Site Editing.

Overview

  • The Full Site Editing overview issue #20791 can help to identify the major components that will be included in this effort.
  • The Full Site Editing project board is another good place to watch for more detail about the current status of this overall effort.
  • Site editing Infrastructure and UIUI User interface continues to be addressed in overview issue #24818.
  • An effort the ensure that Template tags are accounted for in Full Site Editing is underway in issue #22724.

Query BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.

The Query Block is an important focus area. This feature is being explored in the following issues:

  • An Overview issue aiming to identify and resolve any Missing Query block functionality can be followed in issue #24934.
  • Design work for the controls for the Query block is being explored in issue #25198.
  • The Pagination Block is a part of the overall Query Block effort with design being explored in issue #26557.

Global Styles

Global Styles refers to the system that defines and manages global aesthetics allowing overall site styles, theme styles, and blocks to work well together.

  • An overview issue #20331 contains detailed information about Global Styles.
  • The Global Styles effort is being actively evaluated to identify next areas to focus on as well as areas to de-prioritize.
  • An effort will be made adjust for some things identified during testing with the blocks based version of the Twenty Twenty-One theme.

Ways to Get Involved

While the above items are our focuses, you can always help with triage, needs testing issues, good first issues and reviewing PRs.

If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

Meetings to Join

While you can view all meetings here, here are specific meetings to join depending on your interest. Remember that you need a WordPress.org slack account to participate: 

  • CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor weekly meeting on Wednesdays @ 14:00 UTC in #core-editor focused on all things Gutenberg. 
  • 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) weekly meeting on Fridays @ 16:00 UTC in #accessibility focused on wrangling accessibility related work across Core and the block based editor.
  • Block Based Themes meeting twice monthly on Wednesday @ 16:00 UTC in #themereview focused on preparing for Full Site Editing. 

Note: with daylight savings time related changes happening for many countries on different dates it may be helpful to double check on the times as some meetings may shift times to accommodate attendees preferences.

#gutenberg-next

CSS Chat Summary: 08 October 2020

Full meeting transcript here on Slack. @notlaura facilitated the meeting.

Housekeeping

@notlaura reminded attendees that she will be unavailable on 22 October and needs somebody to step in and run the meeting. If you’re up for it please let her know!

CSSCSS Cascading Style Sheets. Audit (#49582)

@notlaura reported progress on her PR to add the HTML report to @ryelle‘s super CSS Audit tool which now adds support for a --format=html command line option.

There is a remaining issue with the property-values audit, and contribution is still needed towards improving the design and info formatting.

@notlaura also mentioned an issue she added about the need for property-value audit groupings. A short discussion about possible solutions followed, which gravitated towards adding support for .json config files. @ryelle offered to write up an issue to outline the format she envisages for discussion in githubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.

@notlaura clarified the approaching milestones of merging her PR, updating the tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker., and enabling more progress on styling the report which @danfarrow (me!) has started contributing to.

@notlaura pointed out a failing test (Colors › should ignore colors in non-color properties) which @ryelle confirmed she had left as an aide-mémoire for herself to fix the associated issue. @ryelle suggested that this issue might be a good self-contained task for a new contributor to tackle.

Color Scheming (#49999)

@ryelle reminded us of her demo site where people can appraise the reduced-colors testing tool – details in this Slack message. Some issues have already been added to the github repo but wider testing is required.

The plan is to post in #design and #accessibility with info on how to access the tool, how to submit new issues, and prompts to help fix the issues.

@notlaura put out a call for somebody to help with this small task, and offered her assistance to clarify what’s required & to review the message before it’s posted. @ryelle added that she can still write the post if nobody else volunteers (although she had mentioned earlier in the meeting that this month is super busy for her so please consider helping out!)

CSS links share + Open floor

@notlaura shared a link to this CSS-Tricks article about the widening responsibility of front-end developers. @Andrew Joyce added a recommendation for an earlier article by the author on the same theme, The Great Divide.

We reflected about a time when writing CSS involved just writing CSS, and on that poignant note the meeting was closed.

Thanks to everybody who attended!

#core-css, #summary

What’s next in Gutenberg? (September)

This is a monthly update containing the high-level items that 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/ contributors are focusing on for September. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so. 

How to follow along with Gutenberg: 

Here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development related posts and a new Site Editing Milestone overview issue that breaks down the upcoming work into more concrete next steps. 

Global Styles & Editor focused APIs

Global Styles refers to the system that defines and manages global aesthetics allowing overall site styles, theme styles, and blocks to work well together. Currently, the hope is that work on editor focused APIs can be wrapped up in the month ahead if all goes well. Some of this work will include the following:

Follow along:

You can follow the progress for this overall system in this overview issue. For more recent and immediate next steps, you can follow this issue describing the current state of work. 

WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Screen

After months of work, this new screen has been launched out of experiments in the latest Gutenberg 8.9 release. This should allow for plenty of time for feedback before the 5.6 release. With blocks firmly paving the way for the future, this work on the widget screen is meant to help modernize the experience outside of just site editing, ease adoption for everyone, and upgrade what’s currently possible by enabling third party extensibility. This vision can’t be accomplished without feedback so please test and share any bugs or enhancements on GitHub. Work this month will include the following along with the feedback received from users: 

Follow along:

You can follow the progress of this project on this project board.

Full Site Editing

As with the prior months, work on this major focus for phase 2 is ongoing and is expected to continue iterating over the next months. Keep in mind that much of this work relates to other areas like Global Styles & Editor Focused APIs! With that in mind, work this month will mainly focus on the following based on the Milestone 2 – Site Editor Navigation. Note that timing for this work will  likely need to be adjusted depending on progress made meaning this work might start in September but continue going forward.

  • Group document settings in the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.
  • Indicate current template and template part when in site editor.
  • Move templates and page navigation into the main W 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..
  • Allow browsing all templates and parts. 
  • Incorporate “Add New Page” Flow into “Add Template”.
  • Begin exploring missing functionality for the query blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. as part of milestone 5. 

We’re watching the Theme Experiments repo as well to see how themers are attempting to build block-based themes. Please continue to share there and know we appreciate it!

Follow along:

You can follow the progress of this project on this project board. To help break down this work more, a new overview issue with key milestones for site editing was also created. For each major milestone, there are related issues for each milestone that are recommended to follow if you want a more granular look at each next step (example from Site Editor Navigation).

As a reminder, if you’re interested in being a part of testing Full Site Editing, check out the experimental outreach program to learn more

Navigation Screen

Similar to the Widget Screen, efforts have begun to launch this new screen to the world in order to gather more feedback. Right now, this effort has a few blockers but, if you’re able to, testing this screen and reporting feedback would be a huge help (Install Gutenberg and head to Gutenberg > Experiments to enable this screen). The aim is that this new screen will help expand what’s possible with menus while bringing block functionality to yet another part of WordPress in order to allow for more adoption and to offer a more modern experience.  

Follow along:

You can follow the progress of this project on this project board, review the overview issues (Block Navigation, Navigation Screen) & join the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat.

Areas to be aware of:

Block & 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 Developers

Since the block directory is still a new feature in the WordPress world, the following includes the prior links once more along with two additional issues to chime in on: 

Theme Developers

Review the latest Gutenberg Themes roundup and, in particular, check out @tomjin’s PHP theme template compatibility proposal as it relates to Full Site Editing. Please chime in with your thoughts! Outside of this proposal, here are two other items that might be of interest:  

Ways to Get Involved:

While the above items are our focuses, don’t forget that you can always help with triage, needs testing issues, good first issues and reviewing PRs. Focusing efforts around Widgets and Navigation in particular this month would be very helpful as both screens are on their way to no longer being experimental features. 

If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

Meetings to join:

While you can view all meetings here, here are specific meetings that touch on Gutenberg development to join depending on your interest and availability. Remember that you need a WordPress.org slack account to participate: 

  • Core Editor weekly meeting on Wednesdays @ 14:00 UTC in #core-editor focused on all things Gutenberg. 
  • 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) weekly meeting on Fridays @ 15:00 UTC in #accessibility focused on wrangling accessibility related work across Core and the block based editor.
  • Navigation Sync weekly meeting on Wednesdays @ 07:00 UTC in #core focused on triaging and discussing Navigation screen work. 
  • Block Based Themes meeting twice monthly on Wednesday @ 16:00 UTC in #themereview focused on preparing for Full Site Editing. 

#core-editor #gutenberg-next

Accessibility improvements to Media component in WordPress 5.5

WordPress 5.5 introduced several improvements in 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) of the Media component.

Improvements in the accessibility of the status and error messages in the Image Editor

On previous WordPress versions on the Edit Media page, when activating the “Restore Image” button, a message was shown above the image while the Restore button itself disappears.

Since the button would have been focused at the time when activated by keyboard, this causes the keyboard focus position to be lost and reset to the top of the page.

The message itself is also not announced by screen readers, and may not be visible to screen magnification users if it appears outside their current view.

WordPress 5.5 improved the behavior of notices inside the Edit Media page with the followings:

  • Improves the focus management by moving focus to the notices, if any, or to the first “tabbable” element: this avoids a focus loss and helps Braille-only and screen magnification users to be aware of the messages.
  • Adds an ARIA role alert to all the notices.
  • Uses wp.a11y.speak() to announce messages to assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology: this leads to all visual users seeing the messages while assistive technology users will get an audible message.
  • Uses wp.i18n for translatable strings in wp-admin/js/image-edit.js

Related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #47147.

Fix the Image Editor mismatching keyboard focus order and visual reading order

On the Edit Media page, the keyboard focus order and the visual reading
order were presented in a zig-zag pattern.

This was causing some accessibility issues for users who have a cognitive disability as they may be confused by an unexpected or illogical focus order.

WordPress 5.5 fixed that by swaping the DOM order of the two main columns within the adminadmin (and super admin) Image Editor.

See more details in the Trac ticket #47136 and the attached changeset.

Improve the appearance of image editor on small and medium screens

WordPress 5.5 added new CSS rules to improve the appearance of image editor on small and medium screens. The new rules prevent the main area of Edit Media screen from being pushed down too far.

See the related ticket on Trac: #47136.

Props to @afercia for proofreading.

#5-5, #accessibility, #dev-notes, #media

WordPress 5.5 Core Editor Accessibility Improvements

In an effort to better communicate the specifics of what’s coming to the editor in WordPress 5.5, this post is meant to list the various 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) improvements shipping with this upcoming release on August 11th. Going forward, the “What’s Next in Gutenberg” posts will have clearer accessibility-related callouts to make it easier to follow relevant issues more regularly. The work to improve WordPress is never finished, and with more releases will come more improvements, but it’s encouraging to see progress in so many areas. 

Thanks to everyone who worked hard to get these improvements in place in time for 5.5! 

In most sections, explorations are shared of specific high impact improvements. Please view individual issues for more details. 

New Editor Design

WordPress 5.5 brings numerous changes to the look and feel of the editor, informed by the goal of reducing complexity by simplifying iconography, color palette, focus, and general interface. As more features are added to the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, a simpler and clearer design allows the interface to scale more gracefully. Examples include: the effort to create a single toolbar to have fewer tab stops, work done to make the single primary toolbar bigger (more tappable with a larger touch area), and higher contrast. Some changes, such as removing borders around selected blocks, have inspired spirited debates, and it’s been great to see so many people involved. As always, discussion, iteration, and collaboration are our best tools for moving forward together.

Keyboard Navigation Improvements

Below is a screenshot highlighting the new keyboard option mentioned above that can be found in “More tools & options > Options” modal. Checking it will stop arrow keys from navigating between blocks in edit mode. You can also programmatically auto-enable it with this code snippet: 

if ( 
  ! wp.data
      .select(‘core/edit-post’)
      .isFeatureActive(‘keepCaretInsideBlock’) 
) {
  wp.data
    .dispatch( ‘core/edit-post’ )
    .toggleFeature( ‘keepCaretInsideBlock’ );
}
Screenshot showing the “More tools & options > Options” modal where the new option lives.

The following video shows a walk-through of arrow navigation between nesting levels while in Navigation Mode mentioned in the above section: 

Video showing a walk-through of arrow navigation between nesting levels.

Screen Reader Improvements

Focus Improvements

The following video demonstrates the roving tabindex across block toolbars. Of note, the APIs to achieve this improvement in wordpress/components are listed as experimental for now and should ship in 5.6 so third-party developers can use them as well.

Video showing the roving tabindex across block toolbars.

If you’re interested in improving accessibility in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor, check out the accessibility team, review the current open issues related to accessibility, provide accessibility feedback on issues, and help test 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/.

#5-5, #accessibility, #core-editor