Headings in Admin screens change in WordPress 4.3

Are you a theme, plugin or framework developer for WordPress? Take note: the heading structure in the Admin screens will change in WordPress 4.3.

From H2 to H1

Currently, in WordPress 4.2 and before, the main heading in admin screens is an <h2>. However, if you want to have a correct, semantic heading structure, a page should an <h1>, but only one, which describes what the page is about.

People using assistive technology use the <h1> to identify a page and quickly know where they are. Further, proper HTML5 dictates that an <h1> should be the initial heading.

Therefore, in WordPress 4.3 the headings of all admin screens have been changed from <h2> to <h1> (see #31650).

Related CSS changes

If your theme or plugin still uses <h2> for admin screens, don’t worry; styles for <h2> are still supported in the admin CSS so that, visually, nothing changes during the update to 4.3. However, a new class was introduced to properly style <h1>s, page-title-action. Here’s an example of the new class in use:

<h1>Posts <a href="[..]/wp-admin/post-new.php" class="page-title-action">Add New</a></h1>

The old class .wrap .add-new-h2 is still supported but has been labeled deprecated. It has been replaced by: .wrap .page-title-action.

More changes ahead

After the release of WordPress 4.3, the accessibility team will continue making changes to heading so that they are semantically correct. Current <h3>s will become <h2>s, <h4>s will become <h3>s, and so on.

Check your code

Does your plugin, theme, or framework have admin screens? Check the heading structure. Change the main heading from an <h2> into an <h1>. If you’re feeling generous, check the rest of your heading structure to ensure it’s semantic.

Making these semantic changes will ensure your plugin or theme is in sync with WordPress and that people using a screen reader can understand your admin screens better.

If you have any questions, ask them in the comment section below, or contact the WordPress accessibility team in the #accessibility channel in WordPress Slack.

#4-3, #dev-notes

Today in the Nightly: Site icons in the customizer, editor patterns, more accessible comment bubbles, row toggle focus styling

Install the nightly, and try out this fresh batch of shiny.

Site Icons in the Customizer

I’ve long wanted site icons in the customizer alongside site title and tagline. The identity information that I always want to edit when first setting up a site are now all together in the customizer.

For more visuals, see these visual records.

See #16434.

Editor Patterns

Create bulleted lists, ordered lists, and blockquotes using markdown like patterns. I find this particularly handy on phones when the editor toolbar is offscreen.

Screen Shot 2015-07-14 at 4.39.12 PM

See #31441.

Better focus styling for list table row toggles

See #32395.

Better accessibility and design for the comments bubble

The comments columns in our list tables were among the most confusing for screen reader users. Accessibility and visuals are now improved.

See #32152.

Eliminate content overruns on small screens

An audit of content overruns on small screens resulted in many fixes.

After:

Before:

See #32846.

Styling improvements on small screens for Right Now in the network admin

See #32962.

Improved header information in Network Admin Edit Site tabs

  • Use the site’s name rather than URL in the Edit Site header.
  • Provide “Visit” and “Dashboard” links for the site on all tabs.

After:

Before:

See #32525.

Disambiguate “Automatically add new top-level pages to this menu”

In the customizer, a menu’s auto-add pages option is now separated from the preceding menu location checkboxes.

See #32820.

 Passwords UI Improvements

Passwords received a couple of improvements. The show/hide toggles look better, and passwords ui is on the install screen. Passwords on the install screen still needs a little more flow work.

See #32589 and #32925.

For more visuals, see these visual records.

Reduce link noise in media library list view

This is visually subtle but removes confusion for screen readers.

KL_7dmW58c

See #32254.

 

Previously: Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons

#accessibility, #bubbles, #comments, #content-overrun, #customize, #edit-site, #editor, #list-tables, #media, #menus, #multisite, #network-admin, #right-now, #site-icons, #today-in-the-nightly

Letting WordPress Speak: New accessibility feature in 4.2

One new accessibility feature in WordPress 4.2 is the new JavaScript method wp.a11y.speak(). The essence of this feature is to provide a consistent methodology for announcing dynamic JavaScript updates to assistive technology. For more information about how this works, why it exists, and how to use it, read the complete post at Make/Accessibility.

#4-2, #accessibility, #dev-notes

Support for Screen Reader Text in Themes

Support for Screen Reader Text in Themes.

#accessibility, #themes

I put out a call from the @wordpress…

I put out a call from the @wordpress Twitter account yesterday asking for accessibility volunteers. Already getting some helpful feedback. Anyone not working on a 3.2 feature already could help out by working on one of the accessibility issues.

#accessibility

Menus UX Manifesto

A Menus Manifesto?

Now that the new menu system patch is in and working, I’ve been able to start going through it for UI stuff. The are some things I think we should consider changing to fit into the WP UI, though based on timing I’m also okay with letting some of it slide until next release if needed. Here are the things on my mind, which hopefully we can touch on during today’s dev chat.

  • Icons. The edit/delete/view icons are inconsistent with the way we handle actions everywhere else in WordPress. We have two options here: we can have icons made that will match WP core icons, or we can get rid of the icons and change the UI a bit to match existing interaction models. If we go with icons, I’ll ask Ben to make us some that match better, which might be the better part of valor to get 3.0 out on time, rather than trying to make everything perfect. Release early and keep iterating, right?
  • Accessibility. The menus function as it stands now is completely inaccessible. There doesn’t seem to be a no-JavaScript version, which we have to have. It will be clunky and ugly, like widgets, but we NEED to do this. Icons for actions rather than text is an accessibility no-no, which is another reason to move away from them eventually, but the bigger problem is that we need a no-JS version. I’m emailing the accessibility list to see if anyone there is willing to pitch in and help.
  • Little arrows on the left of each item. These should be removed. We use little arrows everywhere else to indicate an open/close functionality. If we need a symbol to indicate hierarchy we could use dashes like some other plugins do, or better and more attractive, just indent the bar itself? We also need to get rid of those little mini-arrows in the modules on the right when you click on View All.
  • Everywhere else in the admin, the right-left convention is opposite of how it is on this screen. For example, in Widgets, the available widgets are on the left and the completed sidebars are on the right. On categories and tags, you add on the left and see the updated list on the right. It would probably make sense to swap the menu and the menu controls so the controls are on the left and menus are on the right.
  • Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.
  • Display. Like some other people, I’m wondering why each menu has to have its own screen, when it’s generally a pretty narrow column.
  • Default menu. When you first go to the menu screen, it says you don’t have any menus, to create one, but that’s both confusing and incorrect. There is a default menu in place using pages (or categories, in some themes). We should either a) (and preferably) Display the pre-existing menu as Main Menu or some such, or b) change the default text to explain that they currently use the default menu, and this screen is for customizing. It’s also highly unclear how someone should name a menu, or what the relationship is between menus and themes. If someone creates 20 menus but none are supported by the theme, what will happen? It should really pre-fill what menus you have available to you, just like it does with sidebars on the widgets screen.
  • The click to add icons perform the same action as the page/category titles themselves. The icons impair accessibility. If we are to have a second addition mechanism, it should be a text link, not an icon.
  • The mechanism for adding URL and adding page/category is inconsistent. Pages and categories have a list from which you can add, while links are added to menu directly. It would be more consistent to create link rather than add link when it’s first entered, then have link appear in a list below, as the pages and categories do, so that links could be added to/removed from menus without just deleting them. This would also follow the principle we established in widgets that you shouldn’t lose settings when you deactivate something like that.
  • The metaboxes down the right all show the on-hover gray arrow in the right header corner, but the boxes don’t collapse. Either make the boxes collapsible or get rid of the hover arrows.
  • Instead of the edit icon, each menu item should have the hover arrow, which would open it to the edit view. Then we should use save/close/delete as in widgets, thus getting rid of the delete icon as well. This is the interaction model for this type of metacontent and should be followed.
  • I don’t really see the need for a View link (icon) from each menu item.
  • Whatever we do in terms of these changes, hooks need to be included so that Woo can get their own current look back if they choose, as that was part of the agreement.

This is the kind of thing that we need a styleguide for, which the UI group has recently started working on. 🙂

#accessibility, #interaction-models, #menus, #navigation, #ui, #ux

Going through some of the accessibility …

Going through some of the accessibility improvements. 2.7 was tested with JAWS but there were some changes in the UI since then. Does anybody use JAWS or another screen reader, or know somebody that uses it? Feedback is welcome.

#accessibility