Editor chat summary: May 8

This post summarizes the weekly Editor meeting on Wednesday, 8th May 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Volunteers for Note-Taking Requested

As there are not very many folks who are taking notes for the chat at the moment, volunteers were requested. @nosolosw, @andraganescu, and @jorgefilipecosta offered to help out.

WordPress 5.2

WordPress 5.2 was released! Thanks to everyone who helped!

@youknowriad noted that he wasn’t sure why all of these things weren’t highlighted in the release post, but updates include:

  • No more TinyMCE in blocks
  • Block Management UI
  • Performance more than doubled in async mode
  • All widgets ported to blocks
  • A lot of improvements to existing blocks (cover block with inner blocks, focal point picker,…)
  • Stability improvements
  • Zero-config scripts to help authors create blocks

Accessibility Audit

The accessibility audit has been published. This is a great resource to improve the accessibility of the editor. Thank you to everyone that worked on it!

@andraganescu, @karmatosed, and @mapk attended the Accessibility chat to collaborate (recap was posted on the agenda post).

Design has done two triage sessions focused on the report (the next is on Friday, May 10, 2019 at 14:00 UTC), and development has already started in fixing some of the issues found.

The project board can be found here, and issues are also being grouped into labels (like [a11y] Keyboard & Focus). There’s interest in solving all validated issues that were found.

Several folks expressed interest in an a11y focused WordPress release, with the note that it would need to be a broader conversation with core + leadership.

@bemdesign mentioned, and others agreed, that while automation can help, a11y should ultimately be built into the process. Tenon, the company that ran the audit, provided documentation on how they tested.

Some recommended next steps included:

  • Aim for closing the project board by the end of May
  • Focus all triages until that can happen
  • Consider adding a column for deeper conversations / focuses and make issues for those
  • Dev-triage session focused on the board next week (Monday)
  • If you’re looking for an issue to tackle, take a look at this board first 🙂

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

Open Floor

@karmatosed asked if anyone would be interested in working with them on more detailed RC notes to be included in calls for testing.

@aduth raised a question about merge permissions.
“Is there a good sense of criteria for this to be granted? Or similar to core committer status, at discretion of leadership?”

Folks present seemed to be in consensus that this should be clarified, even if it’s only in terms of documenting general expectations.

Recommendations on criteria often included a number of contributions (committed PRs or other activities), ranging from 3-10 — with a note from @gziolo that Gatsby automatically adds access after one.

In closing, a quote from @andraganescu, “The thing with merge access is that as long as we have the triage/review/automated testing process the only thing you need is to prove some kind of good faith I guess”

Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on 15 May 2019 at 13:00 UTC, is here; please add anything that you want to discuss.

#accessibility, #core-editor, #editor, #gutenberg, #meeting-notes

Dev Chat Summary: May 8th

Announcements

WordPress 5.2 was released yesterday! Thank you, everyone, who was involved in any aspect. @chanthaboune has some learnings from this release to take into handbook updates.

Global WordPress Translation Day is coming up on Saturday!

Planning next releases

@chanthaboune outlined a proposed plan of one small scale point release in a few weeks and then 5.3. The suggestion was mid-August. This sparked a discussion on what could be added to the next release. It was noted component maintainers and teams are over the next few weeks going to decide what they want to achieve. @jeffpaul added that it’s worth checking which of our 9 focuses could be the star of 5.3.

Some of the suggested things to include:

  • Fine tuning recovering mode (@pbiron)
  • Anything else which gets us closer to bumping min PHP version (@pbiron)
  • Modernizing our CSS base (@marybaum)
  • Revisiting responsive images (@kadamwhite)

@youknowriad mentioned there is some are still some uncertainties that need to be figured out about the widgets screen + Customizer, but it would like to be in 5.3.

Regarding the mid-August timeline, it was noted a lot of Europe shuts down for extended holidays and it is common vacation time.

@mapk noted if there was no later release a lot of the bigger ticket items for Gutenberg wouldn’t make it in, so there would need to be a later one. December having a release would fit into the end of year version bump for PHP minimum to 7.x.

@chanthaboune noted to keep an eye out on make.wordpress.org/core for a post and discussion.

5.2 Retrospective post

There will be one and a call for volunteers to manage was made. This will be a post on make/core asking 3 questions. @marybaum volunteered to help with that.

Calls from component maintainers

@afragen raised that if theme compatibility testing were desirable, at some point, #meta3781 needs to progress.

Open floor

Component maintainers

@afercia would like to see an audit of component maintainers and try and get new contributors involved there. @garrett-eclipse suggested a flag that could automatically be raised once someone has consistently contributed to a component, or create a potential shortlist of candidates. @jeffpaul noted this is what should happen with component maintainers. It was also noted by several people this wouldn’t help those who don’t contribute via patches.

@jeremyfelt added some thoughts on component maintaining. He noted inactive doesn’t mean unavailable and there is something to be said for historic knowledge. That said, fresh maintainers are great. Some components are just not active enough right now, which also isn’t a bad thing.

The discussion moved to talk about establishing an emeritus role and @chanthaboune linked to her post about this. It would be good to identify right now what components are in “maintenance mode” and what are “accepting features”, to get a clear picture. @jorbin noted in core we have precedence for this emeritus status.

Other open floor

@bgermann wanted to raise #21022 as something that needs a review and decision on whether a candidate for 5.3.

@clorith mentioned 5.2 hasn’t had many reports yet in forums. Some hosts have a few more than usual. There are some reports of theme updates failing after 5.2 that need investigating.

@jorbin suggested for next week getting a report of PHP versions that people using 5.2 are running. Checking back on this every month after would be great in lead up to changes end of the year. @azaozz recommended adding to the stats page and @melchoyce linked it.

@afercia wanted to discuss the a11y audit by WPCampus / Tenon and spoke on behalf of the accessibility team. The team is glad to see the aggressive triage, but the report outlined broader, fundamental, issues in the overall design of Gutenberg. Next Friday (May 10th) there will be a discussion on this and everyone is welcome at 15:00 UTC in #accessibility.

#5.3, #devchat#summary

#5-2-1

Editor chat summary: 1 May 2019

This post summarizes for the weekly editor chat meeting on Wednesday, 1st May 2019, 13:00 UTC held in Slack.

Gutenberg 5.6

The release candidate was published Monday. No issues have been reported in the interim. The process for publishing the final release to the plugin repository begins today (done). A pull request for the version bump was opened, in case anyone would be so kind as to grant me an approval.

Updates

WPCampus finished the final report of the Gutenberg accessibility audit as of last night. After finishing communications prep, it will be release (done!).  This is a third-party report; additional context can be found here.  The report hasn’t yet been published, but there’s already a number of issues opened in the repository resulting from this audit. While immediate attention could help knock out basic issues, it may be wise to coordinate a joint meeting with the #accessibility team to view the report and identify next steps. The main takeaways are:

  1. – The GB team wants to make a concerted effort at addressing issues exposed by the audit
  2. – We’d like the accessibility team to help point our efforts in the right direction.

The GB team are unanimous is taking a dedicated timeframe to concentrate on the issues specifically reported in GitHub would which will provide the ability to make a significant contribution in a short amount of time. @getDave will attend this week’s #accessibility team meeting on 3 May at 15:00 UTC to connect with the team.

The ability to group multiple blocks together is in development Screencast here. Assistance is requested to test the UX and expert guidance on writing suitable tests to cover the new logic.

Progress is being made migrating the Gutenberg handbook into DevHub (developer.wordpress.org)  https://github.com/WordPress/gutenberg/pull/15254This will be a staged approach where we generate two manifests for a short time, put redirects in place on the legacy handbook, then ultimately go back down to a single manifest. Once the initial work has been done we can look at further restructuring or other improvements,

Task Coordination

  • @nerrad is finishing work on refactoring effects as controls, and plans to start working on a new package to expose common controls.
  • @aduth has proposed improvements to documentation and build times, and is working to enhance the Column block to add resizable controls.
  • @getdave is continuing to work on a method to convert a selection of multiple blocks to a “Group” block.
  • @andraganescu is refactoring media blocks to have a consistent replacement flow and plans to attend the accessibility meeting.
  • @jorgefilipecosta has shared an early prototype that connects the widgets screen to new widgets endpoints (related to the Widgets RFC).

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

The agenda for the next meeting, 8 May 2019 13:00 UTC is here, please add anything you want to discuss.#meeting-notes, #core-editor, #editor, #gutenberg

Notable Accessibility Changes in 5.2

In addition to the semantic improvements to tabs in the admin area, there are a few additional accessibility changes developers should make note of in WordPress 5.2.

Post Formats in List Tables

When post formats were used prior to WordPress 5.2, icons representing the specific format were displayed beside the post title in the Posts list table. These icons served as links that filtered the list by the associated post format.

These icons have now been removed in favor of a dedicated dropdown select filter above the list table.

See: #35497, #46591

Admin Bar Submenu Link Markup

In the WordPress admin bar, menu items with nested items used arrow icons generated via CSS with a .ab-item:before pseudo element. Starting with WordPress 5.2 these arrow icons use a wrapper <span> element:

<span class="wp-admin-bar-arrow" aria-hidden="true"></span>

This change should only affect plugins that modify the admin bar using custom icons. Plugin authors are encouraged to use the new markup and adjust their plugin CSS accordingly.

This change is part of a broader effort—tracked in #40428—to progressively introduce best practices to make screen readers ignore CSS generated content when it’s not intended to be available for speech output.

See: #37513

Archive Widget Dropdown Improvements

To add consistency with the Categories Widget, and to improve contextual awareness for those using screen readers and other assistive technologies, WordPress 5.2 will now pre-select the currently viewed archive in the Archive Dropdown Widget.

This is handled through the addition of a new $selected boolean parameter in the get_archives_link() function. By default, $selected is set to true if the current page is the selected archive page. The new parameter is also available in the associated get_archives_link filter.

In addition, four new date-based parameters have been added to wp_get_archives(). By default, $year, $monthnum, $day, and $w are set to the their current date values, and are used to determine the value of $selected to pass to get_archives_link(), as noted above.

Developers utilizing wp_get_archives() may pass in different date values through these parameters to use as the comparison for the currently viewed archive page.

See: #40662

Other Changes of Note

  • A new media view, wp.media.view.Heading, was added to facilitate adding accessibility friendly headings to the media library/modal. This enables those using screen readers to quickly jump between sections of the interface. See #36925
  • Similarly, headings were added to the data tables on the Export Personal Data and Erase Personal Data pages. See #46041
  • Some minor adjustments have been made to the Alt text and URL fields in the media modals. The Alt text field is now the first field displayed, and it has an explanation below it to help educate on proper usage. The label for the “URL” field now says “Copy link” instead of “URL”. See #41612

#5-2, #accessibility, #dev-notes

Admin Tabs Semantic Improvements in 5.2

Some tabs in the WordPress Admin aren’t really ARIA tabs — they’re actually links wrapped in h2 headings and styled to look like ARIA tabs.

But since they’re just navigation menus, WordPress 5.2 changes their markup accordingly. That way, assistive technologies will react to them correctly.

With #43398, WordPress 5.2 includes the following changes:

  • changes the wrapping <h2> to a <nav> element. It’s worth remembering that <nav> elements also define ARIA landmarks.
  • adds an aria-label to the <nav> elements so they can be distinguished from other <nav> elements in the page
  • adjusts the headings level in the Credits page

Example of former markup in the about.php screen:

<h2 class="nav-tab-wrapper wp-clearfix">
	<a href="about.php" class="nav-tab nav-tab-active">What’s New</a>
	<a href="credits.php" class="nav-tab">Credits</a>
	<a href="freedoms.php" class="nav-tab">Freedoms</a>
	<a href="freedoms.php?privacy-notice" class="nav-tab">Privacy</a>
</h2>

New markup for this screen:

<nav class="nav-tab-wrapper wp-clearfix" aria-label="Secondary menu">
	<a href="about.php" class="nav-tab nav-tab-active">What’s New</a>
	<a href="credits.php" class="nav-tab">Credits</a>
	<a href="freedoms.php" class="nav-tab">Freedoms</a>
	<a href="freedoms.php?privacy-notice" class="nav-tab">Privacy</a>
</nav>

If your plugin or theme uses the same markup as Core, you’ll want to update it for consistency and to avoid future CSS incompatibilities.

Please note: if your plugin or theme uses items that actually toggle the visibility of in-page content instead of linking to another page, then they are not navigation items. You should not use ARIA tabs nor <nav> element in that case.

#5-2, #accessibility, #dev-notes

Dev Chat Summary: September 19th (4.9.9 week 6)

This post summarizes the dev chat meeting from September 19th (agenda, Slack archive).

4.9.9 planning

  • @westonruter: highlighted this discussion about the scope of HTTPS support to target in 4.9.9
    • Looking for wider visibility on those items to get thoughts on what makes sense to include in 4.9.9
    • Relates to umbrella ticket #28521
  • @audrasjb: Accessibility team has a spreadsheet where we sort all the tickets on the focus a11y in order to facilitate lead’s work (see this week’s meeting notes)
  • Bug scrubs not scheduled yet, when they are it’ll be posted to Make/Core

Updates from focus leads and component maintainers

  • @kadamwhite from the REST API team wants to propose the inclusion #41305 in 5.0
    • This covers altering how we evaluate translation strings, originally with the intent of deliberating a performance improvement to the REST API. In discussions about how Locale can be applied to REST API responses for Gutenberg this issue resurfaced, because the current order of operations precludes evaluating string translations based on a passed flag (required to permit the API to provide translations in a user’s locale). To support these localization needs and to improve overall performance at the same time, we intend to milestone this ticket for 5.0.
    • @schlessera: There are two proposed solutions in the above ticket: one that fixes REST API schema translations only, and one that generally optimizes translations (REST API component team’s strong recommendation). The latter is highly preferable, but includes breaking changes for edge cases (as noted in the ticket), so might need a check against plugins first. We otherwise would like more eyes on the forthcoming patch to validate the approach and to help test it.
  • The Editor / Gutenberg team released v3.8 last week including “full screen” mode, improved mechanisms for styling blocks from a theme perspective, and exposes the custom post type used to store reusable blocks from the block inserter as a way to manage saved blocks in bulk.
  • The JavaScript team published notes from their last meeting including documentation of available Gutenberg scripts, reducing exposure of Moment.js in the `wordpress/date` module, and a couple announcements on introducing a formal asynchronous data flow as part of `wordpress/data` and the new `wp-polyfill` script added to Gutenberg.

General announcements

  • @psykro posted about alternate devchat options. Please give that a review and feedback, as ideally we get to a conclusion during next week’s devchat.
  • @whitneyyadrich & @dkotter looking for eyes on / update to Gutenberg issue#7762 as they are running into an issue where they need to be able to insert and manipulate media attachments within the Classic Block, but that’s not currently possible
    • Also imagine this being a bigger issue when migrating sites over to Gutenberg and all their existing content will be thrown into that block. There’s currently not a great way for them to modify/add to that content, if they need to do things with images.
    • Will review with Gutenberg team in next #core-editor weekly chat

Next meeting

The next meeting will take place on September 26, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-9, #a11y, #accessibility, #core, #core-editor, #core-https, #core-js, #core-restapi, #dev-chat, #gutenberg, #javascript, #summary

Dev Chat Summary: September 12, 2018 (4.9.9 week 5)

This post summarizes the weekly dev chat meeting held Wednesday, September 12, 2018 at 20:00 UTC. Agenda | Slack archive


4.9.9 Planning

We have a Road Map and she is gorgeous. Thank you @antpb and @schlessera for putting it together. Here’s a summary:

Suggested Timeline

We will reassess these dates after the three-week mark:

  • Beta : Monday October 22, 2018
  • Release Candidate : Monday October 29, 2018
  • Release Date : Monday November 5, 2018

Key Focuses

If you’re interested in helping out with these topics, hit up these Slack channels:

*Not real but should be.

Bug Scrubs

  • The plan is to run them weekly in the #core Slack channel across multiple timezones. Schedule 👏 Coming 👏 Soon 👏

Focus Lead and Component Maintainer Updates

Notes and Summary Posts

Additional Updates/Requests

  • From PHP Servehappy: More testers are needed for the WSOD protection on real-life, complex sites to reveal edge cases. A “complex site” is basically any site running locally with random plugins and random code.

If you’re thinking about get all up in these Focus and Component Maintainer teams, try attending a chat. Here’s the comprehensive list.


Open Floor

Tickets

Anyone can submit a ticket for the Open Floor. Send your submission to @jeffpaul or moi (@whitneyyadrich), or comment on the agenda for that week’s chat.

  • #12563: New action on body open – Submitted via @welcher. Will be discussed in the #themereview meeting.
  • #32326: Improve Support for Structured Data – This one pairs nicely with the ticket above, so the conversation should be happening in the #themereview room and scheduled chat.
  • #25280: wp_localize_script unexpectedly converts numbers to strings – Submitted via @adamsilverstein and Ivan Kristianto. Lots of words about code were had in the chat, and then the conversation was moved to the ticket itself.

General Announcements

Dev Chat Schedule

@psykro published his proposal for a second <dev chat> and it’s open for your comments. I’m sure we’ll touch on this during tomorrow’s dev chat, too. 

As always, anyone is welcome to join <dev chat> every Wednesday at 20:00 UTC. As I said in the chat, to sorta quote the late, great Notorious B.I.G.

I’m goin’ go call my WP crew
You go call your WP crew
We can rendezvous in <dev chat> tomorrow around two (or Wednesday at 20:00 UTC)

#summary, #4-9-9, #core, #dev-chat

Tag Cloud widget changes in 4.8

The Tag Cloud widget is still pretty popular and for a number of years, it has used title attributes to visually display the number of posts using a specific tag.

tag cloud in WordPress 4.7

Example of a title attribute displaying the number of items for a specific tag in WordPress 4.7

WordPress 4.8 removes these title attributes and replaces them with aria-label attributes with optional counts displayed in plain text.

Why it matters

Title attributes aren’t very accessible. Depending on the specific assistive technology and on user settings, they might be completely ignored. On touch devices, title attributes are a bit pointless.

The best option is not to rely on title attributes to convey important information to users. Information that is important enough should be available to all users.

In the last few releases, WordPress has been progressively removing many title attributes used in the admin screens (see: #24766). The same principle applies to the front end. The Tag Cloud widget is another step towards the progressive removal of title attributes in the front end where they’re used inappropriately.

What plugin or theme authors should know

There are no visual changes by default, other than the removal of the title attributes. There is a new option for developers though: tag counts can be displayed in plain text within the list of tags. Users will now find a checkbox in the widget interface, consistent with what other widgets already do (e.g., Archives and Categories widgets).

the tag cloud widget admin interface

The new option “Show tag counts” in the widget admin interface

Checking the “Show tag counts” option in the admin will make the Tag Cloud show the counts alongside each tag. The screenshot below compares the Tag Cloud with and without the counts displayed:
the Tag Cloud with and without tag counts

Themes can style the tag counts targeting the new CSS class tag-link-count. Also, note that wp_generate_tag_cloud() has a new show_count argument. Themes and plugins that filter the Tag Cloud arguments can use this new argument to force the tag counts to be displayed.

Theme authors are recommended to check how the tag counts look like in their themes and make small CSS adjustments if needed. And remember, the tag counts are not displayed by default! Users can enable and also disable them at any time.

Some technical details

The relevant changeset is [40816] and the related ticket is #35566. Behind the scenes, the tag cloud now attempts to determine whether to output the aria-label attribute, trying to respect the theme author’s intent.

By default, the Tag Cloud displays tags in different font sizes to visually represent how many times they’re used. When tags have a different font size, they visually convey important information that should also be available to assistive technologies.

Sometimes instead, theme authors set up the Tag Cloud to display all tags with the same font size. Twenty Sixteen, for example, displays all the tags with a “flat” styling. It does that by filtering the arguments passed to wp_generate_tag_cloud() and setting the smallest and largest arguments to the same value (note: this is the recommended way to output “flat” tags).

In order to always serve the same information to all users and try to respect the theme author’s intent, the aria-label that conveys the count information to assistive technologies gets printed out:

  • when tags have a different size
  • when the tag count is displayed in plain text (for example when users check the checkbox in the Tag Cloud widget), regardless of the tags font size

A quick update about title attributes

To give an idea of the progress done so far, here’s data from the WordPress codebase from version 4.0 to 4.7. Searching for occurrences of  title= (space-title-equal) only within .php files and only in the wp-admin directory:

WordPress 4.0: 157 results found in 37 files
WordPress 4.1: 156 results found in 37 files
WordPress 4.2: 146 results found in 35 files
WordPress 4.3: 101 results found in 30 files
WordPress 4.4: 97 results found in 32 files
WordPress 4.5: 21 results found in 12 files
WordPress 4.6: 19 results found in 11 files
WordPress 4.7: 17 results found in 9 files

Of the 17 title attributes in WordPress 4.7, four of them are legitimate because they’re used on <iframe> elements and most of the other ones are in files no longer used by core. Many of these occurrences were within loops so the number of title attributes actually output was higher, yet going from 157 down to a very few is wonderful progress.

As always, any comments and contribution to improving accessibility are welcome!

#4-8, #accessibility, #dev-notes

Enhanced Settings API: Where we’re at

As outlined in a recent post on the accessibility team blog, enhancing the Settings API is currently a high priority for the team. We have been working on this project for a couple months now, discussing goals and approach in a biweekly meeting on Mondays at 16:00 UTC. The main objectives have been to improve accessibility of the pages generated with the Settings API as well as making it easier to use and more flexible for developers. Over the time we have identified the following list of areas to work on:

  • The HTML table layout that has been present for most admin pages should be replaced with a modern, semantically more accurate markup. As the entire table markup is created by the Settings API, we should be able to change it without major backward-compatibility concerns.
  • We’d like to investigate moving from the current two-column layout to a one-column layout, as we agreed on that it would provide a more streamlined experience and overview. Furthermore the two-column layout makes it hard if not impossible to use fieldset (and legend) to group elements properly.
  • For common fields used in Core and plugins, such as a simple text field, textarea, dropdown, radio or checkbox, default callbacks should be provided so that developers do not need to write every callback for such simple UI components themselves. These callbacks should be flexible and accept a standardized set of arguments that can be passed to add_settings_field(). Furthermore each callback should provide accessible markup out-of-the-box, so that even plugin settings pages can be made accessible easily.
  • Eventually all settings pages that Core creates should be using the enhanced Settings API instead of rendering their markup manually. This ensures a more structured output and allows developers to modify the Core fields as well.
  • It should be a high priority to create a set of standardized patterns for class names, markup and design. Elements that need to be targeted in JavaScript must have classes used explicitly for that purpose only.
  • All markup we create should be generalized enough to not be specific to only the Settings API pages. Several other pages in the admin, for example the user profile or term editing pages could benefit from the improvements as well once they are polished.

This list may possibly be extended at some point, as there were some discussions about further developer-centric improvements, but for now we would like to focus on producing a clean and accessible markup with a better DUX being a side product of these efforts.

Prototype for WCEU

After starting development through patches on #39441, we soon realized that this project would be better off as a separate plugin. Therefore we created a GitHub repository for the project, where all development happens now. The plugin uses prefixed functions to not interfere with Core’s own Settings API, so it can safely be tested. While working on the layout, we identified the need for thorough user tests of the changes, and we set the upcoming WordCamp Europe as our target to get a first testable version of the plugin ready. While we still need more time to get to the point where we can propose it as an actual feature plugin, we would like to get feedback sooner than later to uncover eventual pain points.

We will be starting next week to discuss what needs to happen to get that prototype finished in time. If you’re interested, please attend the meeting, which will take place on Monday 16:00 UTC on Slack in the #core channel, or leave a comment on this post if you cannot make it.

cc @afercia, @rianrietveld, @joedolson, @karmatosed, @johnbillion@sc0ttkclark

#accessibility, #settings

Cleaner headings in the admin screens

One of the most common needs for accessibility is providing tools to effectively navigate through content. Users of assistive technologies use headings as the predominant mechanism for finding page information. Headings provide document structure. Assistive technologies can list all the headings in a page to help users navigate and jump to different sections, like in a table of contents. For this reason, headings should contain just the heading text.

For a number of years, the main headings in the admin screens have been used to contain extraneous content, most notably the “Add new” button. WordPress 4.8 aims to fix this.

This is a continuation of the work started in 4.3 on restoring the H1 (heading level 1) to the admin screens and continued in 4.4 with the introduction of a better headings hierarchy.

What plugin or theme authors should know

If your plugin or theme follows the previous WordPress pattern of adding extraneous content to the main heading, please update your plugin or theme to make the heading cleaner. All you need to do is move the extraneous content outside of the heading. WordPress 4.8 ships with new CSS rules to take care of the new markup structure and in most cases, no additional changes will be required.

Of course, it’s impossible to cover all edge cases. If your plugin or theme uses additional content in the area next to the admin screens main heading, please double check now and be prepared to upgrade your markup and CSS to account for the cleaner headings. The relevant area is highlighted in the screenshot below and it applies to almost all the admin screens.

example of a main heading in the admin screens

Need more details?

If you need more details about the markup and CSS changes, please do have a look at the tracking ticket #26601 and the first changeset [38983], followed by several other ones all listed in the main ticket.

Get ahead of 4.8 and update now!

The power of the Web is in its universality. Help us to make the Web a place designed to work for all people. Any feedback and thoughts are more than welcome, please let us know in the comments below.

#4-8, #accessibility, #dev-notes