Noteworthy Admin CSS changes in WordPress 5.3

WordPress 5.3 will introduce a number of CSS changes in WordPress admin. While the necessity to improve wp-admin accessibility was previously raised in several Trac tickets, Gutenberg’s recent interface improvements made it necessary to improve the whole interface as well.

Background: in April 2019, WP-Campus conducted an accessibility audit of the new editor interface, made by an independent contractor, Tenon LLC. This audit raised issues in the editor but also in the media modal, which uses wp-admin styles. Fixing these issues on Gutenberg and on the media modal but not in the whole wp-admin interface would have been very inconsistent.

Some tickets were milestoned to the 5.3 release cycle to start backporting Gutenberg accessibility improvements to the whole admin interface. These first tickets aim to improve:

  • Color contrasts on form fields and buttons
  • Focus styles on form fields and buttons
  • Content behavior on text zoom

Backporting some of Gutenberg’s styles to fix these issues introduced some visual issues with the interface elements hierarchy. Therefore, Design and Accessibility teams worked on the overall visual hierarchy:

  • darker tables and metaboxes borders were introduced for a better hierarchy between interface elements

Note for plugin authors and WordPress developers

These changes are only CSS changes, and not structural changes, so the HTML markup is exactly the same as before, with the same class attributes on each element.

In short, your styles should align with these changes if interface elements are not overridden by custom CSS. If you are overriding WordPress Admin CSS on form elements, you should test your plugins or your custom developments against WordPress 5.3 RC 1.

If you are a plugin author, there are different use cases:

  • Plugins that are using default Admin CSS styles should work just like before.
  • Plugins that are using custom Admin CSS styles by overriding default Admin CSS should be checked against 5.3.
  • Plugins that are using fully customized Admin CSS styles should not be concerned by those changes.

In general, plugin authors and WordPress developers are encouraged to:

  • remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes).
  • remove any custom top and bottom padding values.
  • remove any custom line-height values.
  • update their CSS code to override new focus/hover buttons colors if they use custom colors on this type of element.

In the next section of this dev note, you’ll find some noteworthy CSS changes coming in WordPress 5.3.

Main things that are changing in 5.3:

  • Forms fields: 
    • text inputs
    • textareas
    • selects
    • checkboxes
    • radiobuttons
    • both primary and secondary buttons
    • colorpickers
  • Tables, notifications and metaboxes

Known issues

Available for testing in WordPress 5.3 RC 1, these changes have been tested in various use cases and no breakage situation was identified during the tests. Please check the report for full information about the testing panel.

This is a work in progress, just like anything in WordPress Core. These usability improvements were implemented during summer 2019 then tested and iterated on September and October. After 5.3 is released, the idea is to iterate on wp-admin design to make it fully consistent with the editor interface, and to provide a great and accessible editorial experience for websites administrators. The next minor releases will fix small issues with 5.3 changes and the next majors will improve the consistency of user experiences between Gutenberg and WordPress administration.

Changes related to form fields

Text inputs

Legacy CSS code:

/* Legacy styles */
input[type=text] {
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
input[type=text]:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;
}
Legacy input style
Legacy focused input style

New CSS code:

/* New styles */
input[type=text] {
    padding: 0 8px;
    line-height: 2;
    min-height: 30px;
    box-shadow: 0 0 0 transparent;
    border-radius: 4px;
    border: 1px solid #7e8993;
    background-color: #fff;
    color: #32373c;
}
input[type=text]:focus {
    border-color: #007cba;
    box-shadow: 0 0 0 1px #007cba;
    outline: 2px solid transparent;
}
New input style
New focused input style

Textareas

Legacy CSS code:

/* Legacy styles */
textarea {
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
textarea:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;
}
Legacy textarea style
Legacy focused textarea style

New CSS code:

/* New styles */
textarea {
    box-shadow: 0 0 0 transparent;
    border-radius: 4px;
    border: 1px solid #7e8993;
    background-color: #fff;
    color: #32373c;
}
textarea:focus {
    border-color: #007cba;
    box-shadow: 0 0 0 1px #007cba;
    outline: 2px solid transparent;
}
New textarea style
New focused textarea style

Selects

Legacy CSS code:

/* Legacy styles */
select {
    padding: 2px;
    line-height: 28px;
    height: 28px;
    vertical-align: middle;
    border: 1px solid #ddd;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.07);
    background-color: #fff;
    color: #32373c;
    outline: 0;
    transition: 50ms border-color ease-in-out;
}
select:focus {
    border-color: #5b9dd9;
    box-shadow: 0 0 2px rgba(30,140,190,.8);
    outline: 2px solid transparent;    
}
Legacy select style
Legacy focused select style

New CSS code:

select {
    font-size: 14px;
    line-height: 1.28571428;
    color: #32373c;
    border: 1px solid #7e8993;
    border-radius: 3px;
    box-shadow: none;
    padding: 4px 24px 4px 8px;
    min-height: 30px;
    max-width: 25rem;
    vertical-align: middle;
    -webkit-appearance: none;
    background: #fff url(data:image/svg+xml;charset=US-ASCII,<svg image>) no-repeat right 5px top 55%;
    background-size: 16px 16px;
    cursor: pointer;
}
select:focus {
    border-color: #007cba;
    color: #016087;
    box-shadow: 0 0 0 1px #007cba;
}
New select style
New focused select style

Radiobuttons

Legacy CSS code:

/* Legacy styles */
input[type=radio] {
    border: 1px solid #b4b9be;
    border-radius: 50%;
    background: #fff;
    color: #555;
    clear: none;
    cursor: pointer;
    display: inline-block;
    line-height: 0;
    height: 16px;
    margin: -4px 4px 0 0;
    outline: 0;
    padding: 0!important;
    text-align: center;
    vertical-align: middle;
    width: 16px;
    min-width: 16px;
    -webkit-appearance: none;
    box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
    transition: .05s border-color ease-in-out;
}
input[type=radio]:checked:before {
    content: "\2022";
    text-indent: -9999px;
    border-radius: 50px;
    font-size: 24px;
    width: 6px;
    height: 6px;
    margin: 4px;
    line-height: 16px;
    background-color: #1e8cbe;
}
Legacy radio buttons styles

New CSS code:

/* New styles */
input[type=radio] {
	border: 1px solid #7e8993;
	border-radius: 50%;
	line-height: .71428571;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	height: 1rem;
	margin: -.25rem .25rem 0 0;
	outline: 0;
	padding: 0 !important;
	text-align: center;
	vertical-align: middle;
	width: 1rem;
	min-width: 1rem;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=radio]:checked::before {
	content: "";
	border-radius: 50%;
	width: .5rem;
	height: .5rem;
	margin: .1875rem;
	background-color: #1e8cbe;
	line-height: 1.14285714;
}
New radio buttons styles

Checkboxes

Legacy CSS code:

/* Legacy styles */
input[type=checkbox] {
	border: 1px solid #b4b9be;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	line-height: 0;
	height: 16px;
	margin: -4px 4px 0 0;
	outline: 0;
	padding: 0!important;
	text-align: center;
	vertical-align: middle;
	width: 16px;
	min-width: 16px;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=checkbox]:checked:before {
	content: "\f147";
	margin: -3px 0 0 -4px;
	color: #1e8cbe;
}
input[type=checkbox]:focus {
	border-color: #5b9dd9;
	box-shadow: 0 0 2px rgba(30,140,190,.8);
	outline: 2px solid transparent;
}
Legacy checkbox styles
Legacy focused checkbox style

New CSS code:

/* New styles */
input[type=checkbox], input[type=radio] {
	border: 1px solid #7e8993;
	border-radius: 4px;
	background: #fff;
	color: #555;
	clear: none;
	cursor: pointer;
	display: inline-block;
	line-height: 0;
	height: 1rem;
	margin: -.25rem .25rem 0 0;
	outline: 0;
	padding: 0!important;
	text-align: center;
	vertical-align: middle;
	width: 1rem;
	min-width: 1rem;
	-webkit-appearance: none;
	box-shadow: inset 0 1px 2px rgba(0,0,0,.1);
	transition: .05s border-color ease-in-out;
}
input[type=checkbox]:checked::before {
	content: url(data:image/svg+xml;utf8,<svg image>);
	margin: -.1875rem 0 0 -.25rem;
	height: 1.3125rem;
	width: 1.3125rem;
}
input[type=checkbox]:focus {
	border-color: #007cba;
	box-shadow: 0 0 0 1px #007cba;
	outline: 2px solid transparent;
}
New checkbox style
New focused checkbox style

Buttons

Legacy CSS code:

/* 
 * Legacy styles for buttons
 */

/* General */
.wp-core-ui .button, .wp-core-ui .button-primary, .wp-core-ui .button-secondary {
	display: inline-block;
	text-decoration: none;
	font-size: 13px;
	line-height: 26px;
	height: 28px;
	margin: 0;
	padding: 0 10px 1px;
	cursor: pointer;
	border-width: 1px;
	border-style: solid;
	-webkit-appearance: none;
	border-radius: 3px;
	white-space: nowrap;
	box-sizing: border-box;
}

/* Primary buttons styles */
.wp-core-ui .button-primary {
	background: #0085ba;
	border-color: #0073aa #006799 #006799;
	box-shadow: 0 1px 0 #006799;
	color: #fff;
	text-decoration: none;
	text-shadow: 0 -1px 1px #006799, 1px 0 1px #006799, 0 1px 1px #006799, -1px 0 1px #006799;
}
/* Primary buttons :hover styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #008ec2;
	border-color: #006799;
	color: #fff;
}
/* Primary buttons :focus styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary:focus {
	box-shadow: 0 1px 0 #0073aa, 0 0 2px 1px #33b3db;
}

/* Secondary buttons styles */
.wp-core-ui .button, .wp-core-ui .button-secondary {
	color: #555;
	border-color: #ccc;
	background: #f7f7f7;
	box-shadow: 0 1px 0 #ccc;
	vertical-align: top;
}
/* Secondary buttons :hover styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button-secondary:hover, .wp-core-ui .button.focus, .wp-core-ui .button.hover, .wp-core-ui .button:focus, .wp-core-ui .button:hover {
	background: #fafafa;
	border-color: #999;
	color: #23282d;
}

/* Secondary buttons :focus styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button.focus, .wp-core-ui .button:focus {
	border-color: #5b9dd9;
	box-shadow: 0 0 3px rgba(0,115,170,.8);
}
Legacy style for primary button
Legacy style for focused primary button
Legacy style for secondary button
Legacy style for focused secondary button

New CSS code:

/* 
 * New styles for buttons
 */

/* General */
.wp-core-ui .button, .wp-core-ui .button-primary, .wp-core-ui .button-secondary {
	display: inline-block;
	text-decoration: none;
	font-size: 13px;
	line-height: 2.15384615;
	min-height: 30px;
	margin: 0;
	padding: 0 10px;
	cursor: pointer;
	border-width: 1px;
	border-style: solid;
	-webkit-appearance: none;
	border-radius: 3px;
	white-space: nowrap;
	box-sizing: border-box;
}

/* Primary buttons styles */
.wp-core-ui .button-primary {
	background: #007cba;
	border-color: #007cba;
	color: #fff;
	text-decoration: none;
	text-shadow: none;
}
/* Primary buttons :hover styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #0071a1;
	border-color: #0071a1;
	color: #fff;
}
/* Primary buttons :focus styles */
.wp-core-ui .button-primary.focus, .wp-core-ui .button-primary.hover, .wp-core-ui .button-primary:focus, .wp-core-ui .button-primary:hover {
	background: #0071a1;
	border-color: #0071a1;
	color: #fff;
}

/* Secondary buttons styles */
.wp-core-ui .button, .wp-core-ui .button-secondary {
	color: #0071a1;
	border-color: #0071a1;
	background: #f3f5f6;
	vertical-align: top;
}
/* Secondary buttons :hover styles */
.wp-core-ui .button-secondary:hover, .wp-core-ui .button.hover, .wp-core-ui .button:hover {
	background: #f1f1f1;
	border-color: #016087;
	color: #016087;
}
/* Secondary buttons :focus styles */
.wp-core-ui .button-secondary:focus, .wp-core-ui .button.focus, .wp-core-ui .button:focus {
	background: #f3f5f6;
	border-color: #007cba;
	color: #016087;
	box-shadow: 0 0 0 1px #007cba;
	outline: 2px solid transparent;
	outline-offset: 0;
}
New style for primary button
New style for focused primary button
New style for secondary button
Legacy style for focused secondary button

Darker borders on tables, notices, metaboxes and other similar elements

These changes introduce better contrast for borders for the following user interface elements:

  • Tables
  • Screen Options and Help
  • Admin notices
  • Welcome panel
  • Meta boxes (post boxes on classic editor or in edit attachment screens)
  • Cards
  • Health Check accordions and headings
  • Theme and Plugin upload forms

Legacy CSS code:

Depending on the related element, several CSS declarations were used.

border: 1px solid #e5e5e5;
border: 1px solid #e1e1e1;
border: 1px solid #eee;
border: 1px solid #ddd;
border: 1px solid #e2e4e7;
Legacy card with light grey border
Legacy table with light grey border
Legacy Screen options panel with light grey border
Legacy notice with light grey border

New CSS code:

All those CSS declaration are replaced with a unique color:

border: 1px solid #ccd0d4;
New card with darker border
New table with darker border
Legacy Screen options panel with darker border
New notice with darker border

Related Trac tickets

  • #47153: Field boundaries have insufficient color contrast
  • #34904: The design of the focus outline on buttons/elements could be improved
  • #47477: Content overflows and is cut off at 200% text enlarge
  • #47498: Revise checkbox/radio button css for better compatibility with text zoom
  • #48101: Use darker table + card borders across WP-Admin

#5-3, #accessibility, #dev-notes

Report: WP 5.3 Admin CSS changes tested against top 20 plugins

In September 2019, the WordPress Accessibility team tested WP 5.3 Admin CSS changes against the Top 20 plugins on WordPress.org, to evaluate possible breakage on plugins admin screens and to iterate on the related changes.

This week, those tests were reproduced against 5.3-beta3-46471. This post is a report illustrated with screenshots of relevant admin screens for each plugin.

The idea was to test Admin CSS changes against various use cases to see what could happen and to fix as many found bugs as possible. Of course, not every use cases are covered in 20 plugins, but the Accessibility team assumes it will provide a general view on the robustness of the changes coming in WP 5.3.

A dev note will quickly follow this post, to communicate on all the CSS changes coming in WP 5.3 admin screens to plugin authors and WordPress developers.

To sum up, some plugins which use custom CSS that override WordPress Admin default CSS rules on form controls may have few minor visual glitches. Most notably: the input fields can be taller than before WP 5.3. There’s no breakage as the input fields are fully operable, but plugin authors and WordPress developers are encouraged to:

  • remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes)
  • remove any custom top and bottom padding values
  • remove any custom line-height values

For each plugin, screenshot are provided. You can click them to see the full media file.

Contact Form 7

This plugin uses default core admin styles. No breakage found.

Yoast

This plugin uses both custom styles and default core admin styles. No breakage found. One input and one button are too close to each other in the search appearance page. Looks to be due to incorrect use of margins.

Akismet

This plugin uses both custom styles and default core admin styles. No breakage found.

Classic Editor

This plugin uses default core admin styles. No breakage found.

Jetpack

This plugin uses custom styles. No change found on the screens audited. Further exploration could be needed on specific admin screens. Edit: Jetpack team is already working on some small CSS changes in a dedicated pull request. Worth a read to see how plugins could handle Admin CSS changes.

WooCommerce

This plugin uses both custom and default admin styles. Two misaligned labels were found in the installation screen. Some inputs have large vertical paddings/heights. No breakage found.

Note: WooCommerce team already worked on Admin CSS changes in a dedicated pull request. An interesting read to see how plugins could handle Admin CSS changes.

WordPress Importer

This plugin uses default admin styles. No breakage found.

Really Simple SSL

This plugin uses both custom and default admin styles. No breakage found.

Elementor Page Builder

This plugin uses both custom and default admin styles. Small misalignment in one (screenshot 6) of the dozen pages of settings, due to fixed margins. Pretty minor though. No breakage found.

Wordfence Security

This plugin uses both custom and default admin styles. No breakage found.

Duplicate Post

This plugin uses default admin styles. No breakage found.

TinyMCE Advanced

This plugin uses both custom and default admin styles. No breakage found.

All in One SEO Pack

This plugin uses both custom and default admin styles. No breakage found.

WP Forms

This plugin uses both custom and default admin styles. No breakage found.

Google XML Sitemaps

This plugin uses default admin styles. No breakage found.

Google Analytics Dashboard Plugin for WordPress

This plugin uses custom admin styles. No breakage found but the test couldn’t handle each screen of the plugin due to the some issues with plugin’s configuration on local installs.

All-in-One WP Migration

This plugin uses both custom and default admin styles. No breakage found.

UpdraftPlus Backup

This plugin uses both custom and default admin styles. No breakage found.

WP Super Cache

This plugin uses default admin styles. No breakage found.

Google Analytics Dashboard for WP

This plugin mixes custom and default admin styles. No breakage found.


Please note this report is only including Top 20 plugins from WordPress.org, but the changes were also tested on various others plugins, such as WP-Rocket, Advanced Custom Fields, Polylang… and dozens of plugins with less active installations.

#5-3, #accessibility, #testing

Use aria-label to ensure Posts and Comments navigation has proper context in WordPress 5.3

Many themes (including bundled themes) use previous/next navigation in single post and pagination links in the posts/comments archives.

The markup output is under the responsibility of core private function _navigation_markup, which prints out an unlabelled <nav> element:

<nav class="navigation post-navigation" role="navigation">

This <nav> element defines an ARIA landmark by default: landmarks help assistive technology users to perceive the page main sections and jump through them. However, when a landmark is used more than once in a page, it needs to be distinguished from the other ones to let users understand what the landmark is about.

For reference, see ARIA Landmarks Example on W3.org.

To distinguish each context WordPress 5.3 will programmatically add specific aria-label parameter for each navigation menu. That parameter is being added to navigation menus generated by the following functions:

  • _navigation_markup()
  • get_the_post_navigation()
  • get_the_posts_navigation()
  • get_the_posts_pagination()
  • get_the_comments_navigation()
  • get_the_comments_pagination()

The following functions are also impacted as they are used to echo the result of the functions listed above:

  • the_post_navigation()
  • the_posts_navigation()
  • the_posts_pagination()
  • the_comments_navigation()
  • the_comments_pagination()

All these functions now implement aria_label parameter which can be used to pass custom value for the related HTML attribute.

For example:

the_post_navigation( array(
    'prev_text'          => __( 'previous: %title', 'text-domain' ),
    'next_text'          => __( 'next: %title', 'text-domain' ),
    'taxonomy'           => 'chapters',
    'aria_label'         => __( 'Chapters', 'text-domain' ),
) );

For reference, see the related Trac ticket: #47123

#5-3, #accessibility, #dev-notes

Improvements in Media component accessibility in WordPress 5.3

Form controls are still unlabelled in WordPress media views. Some don’t have associated <label> element, <aria-label>attribute or some have an empty label.

Properly labeling form controls is essential for a basic level of accessibility, as labels give form controls their accessible name. The name is then used by assistive technologies to inform users what the form control is about. Not to mention visible <label> elements are clickable and help users with motor impairments to set focus on the associated form control.

Also, the WordPress accessibility coding standards recommend explicitly associated labels (with for/id) attributes instead of implicitly (wrapping) labels.

WordPress 5.3 will now include some accessibility improvements of all the media views from controls:

  • Changes the media views form controls to have explicitly associated labels with for/id attributes
  • Adds a few missing labels / aria-labels
  • Improves a few existing labels / aria-labels
  • Improves semantics in a few places, by adding visually hidden headings, fieldset + legend elements, aria-describedby attributes
  • Improves the image custom size input fields and their labeling
  • Adds role=”status” to the “saved” indicator so that status messages are announced to assistive technologies
  • Swaps the columns source order in the image details template, to make visual and DOM order match
  • Swaps the “Replace” and “Back” buttons source order in the Replace Image view, to make visual and DOM order match
  • Gallery settings: move checkbox label to the right: checkboxes are supposed to have labels on the right
  • Merge similar strings, unified to “Drop files to upload” (removed “Drop files here”, and “Drop files anywhere to upload”)
  • Makes the “upload-ui” consistent across the media views
  • Hides the IE 11 “X” ::-ms-clear button in the Insert from URL field, as it conflicts with the uploading spinner
  • Adds comments to all the media templates to clarify their usage
  • Slightly increases the vertical spacing between form fields in the media sidebar
  • Removes some CSS selectors introduced as backwards compatibility for WordPress pre-4.4
  • Removes some CSS still targeting Internet Explorer 7 and 8
  • Fixes buttons group layout for Internet Explorer 11

The most important change to clarify is that the labeling changed from this (implicit labeling):

<label>
    My input
    <input type="text" />
</label>

to this (explicit labeling):

<label for="my-input">My input</label>
<input type="text" id="my-input" />

Simplified code sample


More details on these improvements can be found in Trac ticket #47122.

This note was drafted by @justinahinon and proofread by @afercia.

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

Core Widgets: new aria-current attribute in WordPress 5.3

When a page is created and users view it, its name appears in several widgets, however there is no visual or semantic indication that this link relates to the current page.

Since it’s possible for authors to create multiple posts or taxonomy terms with the same name, the lack of indication may cause confusion for users with cognitive disabilities and screen reader users.

Whenever the current page is reflected in a menu on that page, the applicable link should have aria-current="page" attribute to add an indication for users. It is also recommended to use this attribute to add a distinctive visual style to separate the applicable link from other links.

For reference, see the relevant standards in Web Content Accessibility Guidelines 2.0:

Concerned core widgets:

  • Recent Posts
  • Navigation Menu
  • Pages
  • Category
  • Archives

WordPress 5.3 will programmatically add aria-current="page" attributes to those widgets. For reference, see #47094.

Theme authors are encouraged to add a distinctive visual style to those links, using the following CSS declaration:

a[aria-current] {
    /* Your CSS styles for current link */
}

#5-3, #accessibility, #accessibility-docs, #dev-notes

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