Make WordPress Core

Tagged: accessibility Toggle Comment Threads | Keyboard Shortcuts

  • Felix Arntz 4:18 pm on January 23, 2017 Permalink |
    Tags: accessibility,   

    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.

  • Joe McGill 5:40 pm on November 11, 2016 Permalink |
    Tags: , accessibility, ,   

    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>

    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.

    • Carrie Dils 9:52 pm on November 11, 2016 Permalink | Log in to Reply


    • bahia0019 7:48 am on November 12, 2016 Permalink | Log in to Reply

      One thing to bear in mind is that while WebAIM will take either figcaption or alt, search engines haven’t declared the figcaption as a identifier in image search, whereas the alt tag is still in play with Google, et al.

      So, the alt should definitely not be pulled from image file name, but if a caption is filled out, it may be redundant for WebAIM, but it’s not redundant everywhere.

      • Joe McGill 2:51 am on November 13, 2016 Permalink | Log in to Reply

        Thanks for bringing that up @bahia0019. According to Google’s image publishing guidelines, they take several factors into account, including the file name and context around the image, including captions and titles. So it would appear that captions are indeed read by Google.

        Also, to be clear, if you define an alt attribute along with a caption for your images, WordPress will still display both. What has changed is that formerly, including a caption and omitting an alt value would result in the alt attribute duplicating the text that was in your caption.

    • FolioVision 7:21 pm on November 15, 2016 Permalink | Log in to Reply

      Hi Joe,

      Bahia’s quite right in making a difference between what Google says and what Google does.

      One shouldn’t take Google’s guidelines to heart. We coded lots of schema.org into a recipe plugin following Google’s guidelines, passing Google’s structured data tests. That markup was ignored for years, while an older form of microdata actually worked.

      For SEO, we should still be duplicating caption data to alt. It would be even more helpful to include an option to include file names at alt (for those who do use explicit file names), with the option turned off by default as most publishers these days are too lazy and amateur to name their media accurately.

      • Joe McGill 11:07 pm on November 15, 2016 Permalink | Log in to Reply

        Hi @FolioVision,

        Thanks for sharing your experience. I agree that anticipating how Google will actually parse markup in their algorithms is fairly opaque.

        In this case, the changes we have made do nothing to inhibit people from crafting `alt` attributes in ways that optimize how Google ranks their content, if they so choose. At the same time, we are making the experience better for actual users in the process.

        I think the benefits outweigh the downsides for publishers who aren’t taking the time to include good `alt` values with their images.

    • Aaron Jorbin 10:06 pm on November 15, 2016 Permalink | Log in to Reply

      WordPress should always choose the experience that humans have when interacting with a site over an attempt at better search rankings.

      This is a great change. Thanks to all the people who helped make it happen.

    • Chuck Reynolds 9:23 pm on November 16, 2016 Permalink | Log in to Reply


    • blepharisma 8:55 pm on November 21, 2016 Permalink | Log in to Reply

      I think this is just Step #1 — Step #2 would be to prompt the user to enter ALT text when the field is left blank.

      I know that the regulations differ in different countries, but in many is is becoming law that public and private business meet certain accessibility standards. Having the ALT text present is in the first level, and a prompt would go a long way to training content creators to automatically include this very important information.

      In similar implementations, a check box is present if the image is decorative.

    • teamduce 7:43 pm on December 6, 2016 Permalink | Log in to Reply

      Happy to see accessibility continuing to be improved in each release. Keep it up!

    • folletti 1:35 am on December 10, 2016 Permalink | Log in to Reply

      Excuse me!
      But a simple solution when I have used the Title and not Alternative text?

    • Dan 2:18 am on December 28, 2016 Permalink | Log in to Reply

      I always have good alt text, because I always have good titles. But now, I have blank alt text everywhere. This might be helping screenreader users to use sites that are poorly managed, but good sites now have blank images and good authors need to do twice the work (writing a title then copying it into the alt). Thanks!

      Does anyone have a function for restoring the automatic alt?

    • Li-An 11:55 am on December 29, 2016 Permalink | Log in to Reply

  • Andrea Fercia 1:03 pm on May 16, 2016 Permalink
    Tags: , accessibility,   

    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.

  • Andrea Fercia 8:14 pm on October 28, 2015 Permalink
    Tags: , accessibility, , example-flow, user-anecdote, visual-comparison   

    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">

    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.

    • Marcel Pol 9:22 pm on October 28, 2015 Permalink | Log in to Reply

      Just to be of help, you can easily check your headings as developer with the WP-Tota11y plugin:

    • Rami Yushuvaev 12:00 am on October 29, 2015 Permalink | Log in to Reply

      Meta Box Question:

      When creating meta boxes, we use the add_meta_box() function. The second parameter sets the meta box title. As a plugin developer I don’t create h2/h3 titles, It’s done by WordPress. What do I need to update?

      Dashboard Widget Question:

      Same thing. When I register new dashboard widgets I use the wp_add_dashboard_widget() function. The second parameter is used to set the widget title. The function added HTML tags around the title, not the plugin developer. What do I need to change in 4.4?

      • Jeffrey de Wit 12:35 am on October 29, 2015 Permalink | Log in to Reply

        Hey Rami,

        The main thing to look out for is when you use additional headings inside of your actual meta boxes/widgets. If you don’t do this, then you’re all set and good to go without having to change anything.

      • Ahmad Awais 12:39 am on October 29, 2015 Permalink | Log in to Reply

        Hey, Rami!
        If you yourself are not creating headings and relying on WordPress to create them for you, then there is nothing to worry about. I myself changed these headings for the widget part, not sure about the Metabox.

        You can download the bleeding edge version and check your metabox generator code. I am pretty sure, you won’t run into any issue.

    • Amanda Rush 8:46 am on November 1, 2015 Permalink | Log in to Reply

      This is excellent news! Yet another accessibility win for WordPress.

      • FolioVision 1:40 am on November 2, 2015 Permalink | Log in to Reply

        I agree whole heartedly Amanda. This is exactly the kind of low friction but usability improvement which doesn’t break anything and makes WordPress better.

        Very nice instructions Andrea!

    • pepe 11:06 am on November 2, 2015 Permalink | Log in to Reply

      So is this only for installations running 4.4 or should we change the heading hierarchy regardless of the user’s WP version?

      • Andrea Fercia 10:22 pm on November 2, 2015 Permalink | Log in to Reply

        WordPress 4.4 has some CSS back compatibility for plugins or themes screens that still use H2 as main heading, basically keeping the old selectors in the style sheet(s). There may be edge cases though which would require some minor CSS adjustments. So, if you prefer to don’t update your headings, you’re not immediately forced to do that. You’re strongly encouraged to update them though 🙂
        About previous WordPress versions, plugins and themes can provide their own CSS for the headings in their screens or accept some minor visual glitches in exchange for greatly improved semantics and accessibility. Probably another good reason to update WP 🙂

      • Ipstenu (Mika Epstein) 12:12 am on November 3, 2015 Permalink | Log in to Reply

        If you tag your next release as “Requires at least: 4.4” then no one below 4.4 will get the update so they won’t get the new headings.

        In general, we recommend people stop supporting older versions of WP to help encourage people to upgrade.

    • Ryan Boren 4:33 pm on November 11, 2015 Permalink | Log in to Reply

      Great post. I tagged it #visual-comparison, #user-anecdote, and #example-flow. The example flow in “Why it matters” provides important perspective and context that most of us don’t have. We need more anecdotes and more step-by-step bulleted flow, especially for accessibility.

    • Cor van Noorloos 7:43 pm on November 14, 2015 Permalink | Log in to Reply

      Great job. Not exactly keyboard related, but have you thought on adding anchor links on (sub)headings as well?

    • revaxarts 8:28 am on November 25, 2015 Permalink | Log in to Reply

      Should we so a feature check or a version check to output H2 on WP = 4.4? Is there a new function available to check?

    • Andrea Fercia 1:12 pm on November 25, 2015 Permalink | Log in to Reply

      You don’t need anything special to output a H2, but you’re strongly encouraged to use a H1.

  • Rian Rietveld 2:04 am on July 31, 2015 Permalink
    Tags: , accessibility,   

    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.

    • Jan Maat 5:53 pm on August 9, 2015 Permalink | Log in to Reply

      What is the effect of this change in older releases?

      • Ipstenu (Mika Epstein) 9:02 pm on August 9, 2015 Permalink | Log in to Reply

        On pre 4.3? Nothing. It won’t break anything, it’ll just make it better for screenreaders.

        That said, no one is under any obligation to make their plugins work on pre 4.0 WordPress, which is about how far back you need to go to make things look weird.

    • Roy Tanck 9:00 am on August 13, 2015 Permalink | Log in to Reply

      Are you sure? As a test, I tried changing an option screen heading in one of my plugins to h1 on a site running WP 4.2, and it looked decidedly different (bold, for one thing). This makes it harder to make the transition seamless?

      • Ipstenu (Mika Epstein) 6:50 pm on August 13, 2015 Permalink | Log in to Reply

        In your readme, tag the new version of your plugin as requiring WP 4.3 and up. That will prevent older users from getting the new versions.

        It won’t be seamless. Yes, it’ll change the display for people who haven’t updated to 4.3 yet, but it won’t break things.

    • norths 5:19 pm on August 13, 2015 Permalink | Log in to Reply

      Alright, we change the heading tags to h1 in our plugins/themes, any admin page or setting page prior to 4.3 will have the transient message be applied (under) h1 tags going forward. But if h1 is hardcoded, and there is an h2 tag also, prior versions of wp will place the transient under the h2?

      • Ipstenu (Mika Epstein) 7:03 pm on August 13, 2015 Permalink | Log in to Reply

        What ‘transient messages’ are you talking about?

        • norths 8:10 pm on August 13, 2015 Permalink | Log in to Reply

          I’m using a settings page on the admin menu, currently using 4.2.4. I updated the h2 tags to h1, but the current version of wp still places the transient message “settings saved” under the h2 tag (I know have 2 heading tags, h1 h2).

        • norths 8:19 pm on August 13, 2015 Permalink | Log in to Reply

          Probably an issue on my end so please disregard

        • norths 6:36 pm on August 14, 2015 Permalink | Log in to Reply

          I added a dummy h2 tag under the h1 for older versions of WordPress. Issue resolved.

    • SoursopTree 7:24 pm on October 13, 2015 Permalink | Log in to Reply

      Where is it located? I need to modify it. Is there a filter for that part?

  • Ryan Boren 12:01 am on July 15, 2015 Permalink
    Tags: accessibility, bubbles, , content-overrun, , edit-site, , , , , , network-admin, right-now, ,   

    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.



    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.



    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.


    See #32254.


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

  • Joe Dolson 6:15 pm on April 15, 2015 Permalink
    Tags: , accessibility,   

    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.

  • Konstantin Obenland 5:50 am on January 26, 2015 Permalink
    Tags: accessibility,   

    Support for Screen Reader Text in Themes.

  • Jen 11:12 am on May 6, 2011 Permalink
    Tags: accessibility   

    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.

  • Jen 5:29 pm on February 25, 2010 Permalink
    Tags: accessibility, interaction models, , navigation, ,   

    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. 🙂

    • Carl Hancock 6:13 pm on February 25, 2010 Permalink | Log in to Reply

      Great points Jane. The one area I don’t necessarily agree with is moving the toolbox to the left and the menus to the right so it is more in line with what is done with Widgets. I guess thats because I look at editing menus more like editing posts, pages, or even the appearance editor.

      The main content is the main column and the toolbox items are on the right.

      If anything i’d say that the Categories, Tags, and Widgets area stray from that convention when most everything else in WordPress maintains a “navigation bar – content – sidebar toolbox” type of layout.

      • Jane Wells 8:20 pm on February 25, 2010 Permalink | Log in to Reply

        Not a bad point. Maybe we should swap the widgets orientation. 🙂

        • Carl Hancock 8:28 pm on February 25, 2010 Permalink | Log in to Reply

          Thanks. Worth looking into, it’s tough with the widgets because of requiring enough space for both the active widgets area AND the widget collection you choose from.

          One thing I never understand is why Categories and Tags stray from the way Posts, Pages and Media Library are displayed.

          Why not have the first page when you go to Categories be the table/grid of Categories and then an “Add New” button just like when you go to Edit Posts/Pages. I know it’s for the convenience of quickly adding a category or tag, but it strays from the other areas of the site that have a table of existing data items, and then an add/edit page.

          Honestly I think thats the route to take with Menus. Instead of doing it all on one screen.

          • Screen 1 would be a table/grid of the available menus with an Add New button.
          • Screen 2 would be the add/edit screen for adding or editing a Menu.

          When you go to Menus you would get Screen 1 which would be presented in similar fashion to Edit Posts or Edit Pages. A list of your menus which you can then choose to edit one or add a new one.

          Cramming everything into one screen is certainly a departure from the rest of WordPress so it would be nice to have it in line. I think how Posts and Pages are managed is a good model to use for Menus.

        • ocean90 8:31 pm on February 25, 2010 Permalink | Log in to Reply

          Compromise: The menu widgets should be make draggable so that everbody can style it themselves, like the Post and Pages.

        • Carl Hancock 8:36 pm on February 25, 2010 Permalink | Log in to Reply

          Forgot to mention, splitting it into 2 screen would also allow you to have some quick edit functionality with it so that you could add something like a default menu flag option so you could quickly set the default menu that is used when the template function call is used WITHOUT passing a menu name/id. Right now I believe it just pulls in the first menu alphabetically. Would also allow for more flexibility in the future for additional functionality.

    • Ryan 7:41 pm on February 25, 2010 Permalink | Log in to Reply

      If when visiting the Menus admin page there are no menus defined, we can create a menu containing all top-level pages. Woo did this but the functionality hasn’t been added back yet after the schema port.

      There are two ways to add menus to a theme. The first is when the theme explicitly calls wp_nav_menu(). The second is by using the widget. Any menu can be displayed as a widget meaning any widget supporting theme can have a menu.

    • kgraeme 7:47 pm on February 25, 2010 Permalink | Log in to Reply

      Thanks for bringing the accessibility issue to the forefront on this. I had asked wpmuguru if it had come up and he said yes, but seeing it on the dock here is great. I agree that handling it like the widgets should be fine.

      For the hierarchy display/editing, I’d love to see the same underlying code be able to be used for the Page Order and Category heirarchy editing.

    • Dean Robinson 10:43 pm on February 25, 2010 Permalink | Log in to Reply

      I only played with the new menu system for the first time yesterday (liking what I’m seeing so far), so some of the things I noticed may not be issues I just may not have looked close enough yet 😉

      Icons – I noticed the “non-matching” icons straight away, I’d probably go for text labels to match interaction in other parts of the admin – text labels would also be better for aspects such as translation?
      Little Arrows – I was clicking furiously on the little arrows until I realised that didn’t actually do anything… bullet point might be a good option, a dash could also possibly get confused for +/- open/close?
      Default menu – Kind of a agree with this, I wasn’t sure what I had to do to get started when I first hit the menu setup page. Did I have to start adding items to a menu, did I have to create one first, did I have to name it ‘appropriately’. Looks like the new sidebar widget thats been added to display the custom menus should take care of the themes that won’t have support built in straight away.. providing they support widgets.
      Non-collapsible metabox – that makes sense, probably should be collapsible
      Hover arrow instead of edit icon – yeah, the more widget like the interface is the less learning users will need to do to start using the new menus, that can’t be a bad thing

    • Martin Lormes 1:59 pm on March 7, 2010 Permalink | Log in to Reply

      I hope I am not too late with this:

      When I started playing around with the menus feature i instantly wondered why I could add existing pages and categories to the menu but not the links I had added to the “Links” section. And then from a different perspective but it’s the same question: Why are the “custom links” stored in the wp_posts table and not in wp_links? (Or maybe it’s not the same question and we need both, custom links stored as a custom post type in the wp_posts table AND the ability to add “links” to our menus!?)

    • Keith 7:54 pm on April 19, 2010 Permalink | Log in to Reply


      Some late feedback. I notice this new menu system doesn’t support a default “home” page. Any plans to addthis? My theme index page is a static home page. The only way to get it into the menu is to create a new home page and redirect.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar