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

Improving the Settings API for accessibility and ease-of-use

On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

Archives of the full conversations:

Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

First Meeting

The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

  • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
  • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

  • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
  • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

Second Meeting

@rianrietveld had four items on the agenda for the second meeting.

  • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
  • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
  • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
  • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

#accessibility, #settings

Improving accessibility of image alternative text in 4.7

WordPress 4.7 includes a change to the way image alt attribute values are generated. Formerly, any time WordPress created the markup for an image with an empty alt value, it would attempt to use either the caption text or the image title—in that order—as a fallback value.

In 4.7, we have removed this fallback behavior.

To ensure your images having meaningful alternative text, you should make sure to set a value for alt text in your media library.

How removing fallbacks improves accessibility

The intent of the fallbacks were to ensure each image included alternative text. In practice however, this fallback behavior often resulted in poor user experiences for people using screen readers. As counterintuitive as that may seem, let’s take a look at some common examples.

Consider a situation where we’ve uploaded an image named “edbc4ef7.jpg” without changing any additional information. WordPress will generate the image title from the file name as shown in the following screenshot of the insert media modal.

Attachment details for an image shown in the insert media modal.

Formerly, inserting this image in a post would result in HTML similar to this (simplified slightly for clarity):

<img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpg" alt="edbc4ef7" width="700" height="467" />

A person using a screenreader on this page would end up hearing the file name read to them, which is not the most helpful experience, and can be quite frustrating when the file name is lengthy.

For another example, setting a caption value but no alternative text would result in markup that looks something like this:

<figure id="attachment_1741" style="width: 660px" class="wp-caption alignright">
    <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpeg" alt="This is a caption." width="660" height="440">
    <figcaption class="wp-caption-text">This is a caption.</figcaption>
</figure>

Notice that the alt value and the figcaption text are redundant? WebAIM describes two ways of presenting alternative text:

  • Within the alt attribute of the img element.
  • Within the context or surroundings of the image itself.

The same article goes on to explain that an alt attribute value may be omitted when an identical figcaption is present, to avoid redundancy; but best practice when using a figcaption is to provide a separate and different alt attribute to describe that image to users of screen readers.

In each case, omitting the alt attribute entirely may result in screen readers reading the file name from the src attribute, so WordPress includes an alt attribute with an empty value, i.e. alt="", whenever the alternative text hasn’t been explicitly set—a technique that is common when an image is decorative.

This change will not affect content already published, but will be the expected behavior for any new content published after upgrading to 4.7. For more background on this issue, see ticket #34635.

#4-7, #accessibility, #dev-notes, #media

Dev Chat Summary: September 21 (4.7 week 5)

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

Reminders

  • Schedule: As of this meeting, we are 4 weeks from the final chance to merge in major features. This includes Twenty Seventeen.

Bug Scrubs

Components & Features

  • Twenty Seventeen (@davidakennedy, @melchoyce)
  • REST API (@krogsgard, @kadamwhite )
    • Latest update
    • API discussion is at 7 am Pacific on Mondays
    • Settings endpoints and meta support both have first-passes on them, which need internal review and some more testing before we ship
    • We have a path forward for passworded posts (password in the query string, eww, but only viable option), there really isn’t a way we can see to avoid sending them as a query param
    • Meeting tomorrow in #core-restapi at 21:00 UTC to go through open issues around non-trivial, conceptual issues in WordPress. REST API team will prepare summary of issues for component maintainers and/or lead devs to review, question, and help guide discussion towards consensus.
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Moving our weekly meetings up to Fridays at 17:00 UTC starting this week
    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – The main issue here was resolved, but there seems to still be some odd behavior affecting words being chopped off filenames with international characters. Could use extra eyes from anyone (along with @sergey) more versed in i18n. Regression on the attachment titles that we generate on upload all became URL encoded instead of reading like a normal title.
    • Media search doesn’t include file name (#22744) – Committed earlier this week. Please report any issues that come as a result.
    • Next step in improving the organization of the media library is to assess both the infrastructure and UI improvements that need to be made here. Prefer to include #design early in this process, rather than asking for UI feedback on development driven decisions, hope to be part of the #design chat agenda tomorrow
  • Customize (@westonruter, @celloexpressions)
    • Latest update
    • In this week’s meeting we developed a schedule for publishing make/core feature proposals/dev notes for the remaining primary 4.7 customize projects, working backward from anticipated time to commit after the proposal and current readiness:
      • Week of 9/19: Improving sliding panels UI (34391, @delawski)
      • Week of 9/26: A new experience for themes in the customizer (37661, @celloexpressions). Please review soon for any requested changes in direction or design.
        • Summary: The existing themes section in the customizer is replaced with a full-screen theme browser and installer… The UI is nearly identical to wp-admin/theme-install.php… The .org-based theme-install previewer is not accessible here because it is likely to cause confusion with its customizer-like interface and the resulting need to switch contexts back and forth… An overarching goal is to avoid switching in and out of the admin/frontend/customize contexts during theme installation and previewing, instead staying in the hybrid customizer context that provides a combination of frontend plus controls… On the technical side, this heavily leverages JS-templated customizer controls and scales nicely to hundreds of themes.
        • Visual:
        • Please comment on the ticket with your feedback as soon as possible, preferably with specific concerns/ideas and reasons.
        • @celloexpressions to check in with @karmatosed on user testing ahead of posting final feature proposal
      • Week of 9/26: Customize transactions (30937, @westonruter evaluating this week and might punt again)
      • Week of 10/3: Code-editing gateways, via CSS (35395, @johnregan3/@celloexpressions). Awaiting approval/feedback on the acceptability/ability to bundle the two proposed libraries in core, with feedback particularly needed from committers and anyone familiar with the Jetpack fork of CSSTidy.
      • Week of 10/10: Customizer browser history (28536, @westonruter)
  • I18n (@swissspidy)
    • User Admin Language (#29783) – almost ready, another review this week and will commit if no blocker pops up
    • Introduce a locale-switching function (#26511) – @ocean90 to do some benchmarking
    • Introduce some JavaScript i18n functions (#20491) – GlotPress side has a solid plugin for exporting translations as JSON files (assistance on testing would be helpful). Still tinkering with the WordPress side and would love to get some additional feedback there.
  • Editor (@azaozz, @iseulde)
    • No updates, but would love to figure out a way to get more user feedback that helps us set direction for the editor. Will look to add some Core questions to annual survey on WordPress.org. Otherwise will start with something in the beta tester plugin, biased audience but it’s one that exists, is more likely to opt-in, and will be more flexible.
  • HTTPS (@johnbillion)

Open Floor

  • @pbearne on Add filters to wp_new_user_notification and wp_password_change_notification (#38068) – added a set of filters to allow us to override email messages send by the wp_new_user_notification and wp_password_change_notification functions. @johnbillion to review as it relates to work on notifications.
  • @danieliser checking for interest for core in a set of reusable templates, models & functionality for forms, tabs & modals
  • @ericlewis on Bulk actions: Reactivate bulk actions hook + add hander hook for all admin screens (#16031) – could use a review of the latest patch, looking to commit sometime in the next week
  • @dshanske still working through the Pings and Trackbacks component

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

Categories and Tags screens changes in 4.6

In WordPress 4.6 the Categories and Tags screens (and all the custom terms screens that use the same edit-tags.php page) will change in order to make the visual order of the main elements match the tab order. This change is focused on helping people who use the keyboard to navigate the content or use assistive technologies such as screen readers.

If you’re a plugin or theme author and you’re providing custom functionalities in these screens, there are a few things you should check.

Why it matters

For accessibility, the visual order should always match the tab order. The main functionality in a page should just be the first thing in the source markup and other parts of the user interface should never be “skipped”.

The screenshot below illustrates the current Tags screen. The main content is split in two columns. The first element in the source is the right column with the table to list the terms followed by the tag cloud for the popular tags and the form to add new tags.

Tags screen visual order and tab order

The current order of the main content elements in the Tags screen.

On page load, the initial focus is set on the first focusable field in the form which is the third and last block of content in the page.

When using the keyboard or a screen reader, content navigation is a linearised process. Starting from the form to add new terms makes sense since this is the main task on these screens. But then users will move forward and they will find just the footer of the page. When relevant parts of content are skipped, it’s more likely for screen reader users to be confused or experience difficulty navigating pages. They just don’t have a clue there is something “before” their navigation starting point. Keyboard users will have to tab backwards to get to the previous content.

What is going to change

The two columns in these screens will be swapped. The first one in the source will be the left column, followed by the right column. Also, in the Tags screen, the tag cloud will be moved after the form. Visually, this change will make these two screens more consistent. From an accessibility point of view, the content structure and organization will be easier to understand and navigate.

The new categories screen

The new Categories screen.

The new tag screen

The new tag screen.

Things you should check

  • if you’re using CSS or jQuery selectors for your added functionalities, you should consider the order of the elements in the markup has changed
  • there are a number of action hooks and filters in these screens but basically just one will have a different order, see the related ticket for more details

Note: For more in-depth information see the related Trac ticket: Edit term screens: tab order should match visual order.

Get ahead of 4.6 and update now!

If you’re a theme or plugin developer: now is a great time to check your code! 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-6, #accessibility, #dev-notes

Headings hierarchy changes in the admin screens

For a number of years, the headings hierarchy in the admin screens have been setup without careful thought. WordPress 4.4 aims to fix this. This work is mainly focused on helping those users of assistive technologies such as screen readers, and is a continuation of the work started in 4.3 on restoring the H1 (heading level 1) to the admin screens.

If you’re a plugin or theme author and you’re providing custom admin screens for settings, etc., there are a few things you should check and update.

Why it matters

Headings provide document structure, which can directly aid keyboard navigation. Users of assistive technologies use headings as the predominant mechanism for finding page information. When heading levels are skipped, it’s more likely for these users to be confused or experience difficulty navigating pages.

Putting it simply, one of the first things screen reader users do in a web page to find relevant content is to press the 1 key on their keyboard to jump to the first <h1> heading and then they will try the key 2 to find the <h2> headings and so on. Thus, it’s extremely important for WordPress to provide a correct headings hierarchy, ensuring no headings levels are skipped.

How to fix your Plugin or Theme

Restructure the document headings hierarchy to ensure that heading levels are not skipped. The main heading should be a <h1> and any subsequent headings should (likely) be bumped one level up. There should be no skipped levels. Check your headings in the Admin, for example in settings pages, list tables, screen options, (dashboard) widgets, and meta boxes.

See for example the screenshot below, the first heading (Sharing Settings) should be a <h1> followed by a <h2> for Sharing Buttons.

main h1 heading example

Your plugin screens should start with a H1!

List Table headings

List tables (such as on wp-admin/edit.php ) have now additional headings added, though you won’t see them. These headings are hidden with the .screen-reader-text CSS class and are intended to allow users to jump to the relevant sections in these screens.

Note: For more in-depth information on using the core .screen-reader-text class, the Accessibility team has a great write-up on it.

The screenshot below illustrates the new headings in the Posts and Categories screens.

In the screen wp-admin/edit.php the heading structure is now:

  • H1: Posts
  • H2: Filter posts list (visually hidden)
  • H2: Posts list navigation (visually hidden)
  • H2: Posts list (visually hidden)

In the screen wp-admin/edit-tags.php?taxonomy=category the heading structure is now:

  • H1: Categories
  • H2: Categories list navigation (visually hidden)
  • H2: Categories list (visually hidden)
  • H2: Add new category

hidden headings for default posts and taxonomies lists

The hidden headings in the default posts and taxonomies lists.

If your plugin or theme provides custom post types or custom taxonomies, these new headings will use their default values “Post” and Category”:

hidden headings for custom posts and taxonomies lists

The hidden headings in the custom posts and taxonomies lists.

New post type and taxonomy labels in 4.4

In order to provide for better heading text, some new labels have been added for use with register_post_type() and register_taxonomy().

For register_post_type():

'filter_items_list'     => __( 'Filter your-cpt-name list', 'your-plugin-text-domain' ),
'items_list_navigation' => __( 'Your-cpt-name list navigation', 'your-plugin-text-domain' ),
'items_list'            => __( 'Your-cpt-name list', 'your-plugin-text-domain' ),

For register_taxonomy():

'items_list_navigation' => __( 'Your-tax-name list navigation', 'your-plugin-text-domain' ),
'items_list'            => __( 'Your-tax-name list', 'your-plugin-text-domain' ),

Here’s an example for a custom post type:

custom posts list with proper headings

Using the new labels to provide proper headings for a custom post.

Screen Options tab changes

Some plugins add custom options in the Screen Options tab. Previously, a h5 heading was used for the options “title”. In WordPress 4.4, the Screen Options tab has been revamped and together with other changes, it has been decided to remove the h5 heading which didn’t allow for a good headings hierarchy.

Each group of options is now within its own form fieldset and uses a legend element as “title”. You’re strongly encouraged to change the HTML you use for your plugin options and use the new markup.

the new Screen Options tab

The new Screen Options tab: each option is in a separate fieldset.

Dashboard widgets and meta boxes changes

All Dashboard widgets and meta boxes headings changed from an H3 to an H2.

<h2 class="hndle ui-sortable-handle">
	<span>your-widget-title</span>
</h2>

If you are a theme or plugin developer: please check the heading structure in the content of your widgets and meta boxes, use an H3 and lower in the right order and context.

Get ahead of 4.4 and update now!

Now is a great time to update your plugins and themes! 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-4, #accessibility, #dev-notes, #example-flow, #user-anecdote, #visual-comparison