Ready to get started?Download WordPress

Make WordPress Accessible

Updates from Joe Dolson Toggle Comment Threads | Keyboard Shortcuts

  • Joe Dolson 8:58 pm on July 21, 2014 Permalink  

    Prioritization: Accessibility Tickets for WP 4.0 

    This is a list of current tickets with the accessibility focus in WordPress 4.0. So that we can get the most important issues done earlier, allowing for better iteration and testing, I’m prioritizing the tickets according to severity.

    Please don’t read this in any way as a listing of importance: all of these issues are important, but some issues have a greater impact and/or require more testing to make sure they’re done right, and these issues are getting higher priority.

    Group 1:

    These issues may prevent a user with disabilities from installing or using WordPress

    New in 4.0:

    1. #28858 New installation: Language Selector

    This should get very high priority, as this feature will be a new user’s first introduction to WordPress, and will set the tone for all further experiences.

    Group 2:

    These issues may prevent a user with disabilities from using a specific feature in WordPress.

    New in 4.0:

    1. #28822 Media Grid: Focus doesn’t change when tabbing through selected items
    2. #28857 Media Grid: Manage focus when toggling between the grid and an edit attachment modal
    3. #28892 Customizer – Widgets – Feedback for screen reader users when Moving widgets + other actions
    4. #28888 Customizer – Widgets – Screen Readers Don’t Announce Widget Names
    5. #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header

    Add Media Experience:

    1. #23560 Keyboard Accessibility of Add Media Panel
    2. #28209 Links inside help tabs (help-tab-content) are not keyboard accessible
    3. #25103 Submit buttons on form fields in the Add Media panel
    4. #23562 Using Speech Recognition Software with the Add Media Panel
    5. #28864 Cannot access edit menu options with keyboard inside Image Editor

    The Add Media panel and related experiences are a huge part of the day-to-day interaction with WordPress, so these should also get high priority.


    1. #27642 Keyboard Accessibility for TinyMCE image panel
    2. #27553 Make WP editor toggle focusable


    1. #20880 Keyboard navigation in Appearance > Header is broken


    1. #27592 Screen Reader Users Do Not Know Widgets are Expandable
    2. #27593 Widgets: Toggle arrows on focus need an indicator beside color alone


    1. #27555 Make tag post meta box more accessible
    2. #26600 Search installed themes input has no submit button
    3. #26550 Some anchor links should be buttons in media microtemplates
    4. #18801 Accessibility Enhancements to Settings API

    Group 3:

    These issue impact front-end user experience, and have enormous impact on the visitors to sites built with WordPress.

    1. #15926 Give header and background images alt tags
    2. #24148 Add aria-labelledby attributes to comment form
    3. #21221 Image title and alt attribute content should be texturized.
    4. #27402 Add aria-describedby to image gallery output
    5. #27645 MediaElement.js player & playlist not keyboard accessible
    6. #16433 Extend function to optionally include commenter name in comment_reply_link
    7. #18650 Make archives and categories widgets dropdown ada compliant

    Group 4:

    These issues should not generally prevent a user from using a feature, but will make it more difficult to use.

    1. #28976 Add Media Panel: Announce context of close button for screen readers
    2. #28867 Correctly label forms in wp_list_table
    3. #26552 Remove title attributes: default-widgets.php
    4. #26758 Edit Tags form on submission does not stay at the same page and gets redirected
    5. #28873 JavaScript code for adding bookmarklet Press This is hard to access with keyboard only
    6. #25111 Keyboard focus does not stay within Full Screen Editor modal
    7. #26562 Remove title attributes: class-wp-admin-bar.php
    8. #26504 Semantic elements for non-link links
    9. #27609 change ‘<code>’ to ‘<pre>’ in wp-includes/comment-template.php
    10. #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
    11. #26601 Inappropriate content in heading on Themes page
    12. #26551 Remove title attributes: link-template.php
    13. #26560 Remove title attributes: rss.php
  • Joe Dolson 3:39 pm on June 24, 2014 Permalink
    Tags: ,   

    Draft guide for accessibility-ready reviewers 

    To go along with the accessibility-ready guidelines, I’ve been working on a document to help people who want to help perform accessibility reviews on themes. This document is targeted at members of the accessibility team who want to help support the review process by checking themes for accessibility.

    Please provide comments, so I can edit them into the most helpful guide they can be!

    Theme Accessibility Guide for Reviewers

  • Joe Dolson 8:52 pm on June 12, 2014 Permalink  

    Theme Review Accessibility Guidelines Update 

    In anticipation of WordPress 4.0, I’ve been working on revising the Theme Review accessibility guidelines. With the release of WordPress 4.0, the theme review accessibility guidelines will no longer be considered “draft” guidelines.

    My goal is two fold: first, to make them easier to understand by adding examples, and second, to reorganize them so that the most commonly encountered issues in themes are listed first.

    Additionally, I’m adding a section for “recommended” guidelines.

    Please review the draft of the updates and make comments on this post. Thanks!

    • bobeaston 11:34 am on June 13, 2014 Permalink | Log in to Reply

      This guide just keeps getting better and better. It hits the big issues, yet stays concise enough to be approachable. In a previous life, I watched a guide like this grow from a few pages that were useful to one with nearly a thousand pages that no one wanted to open. You’re on exactly the right path for keeping it useful.

      I imagine you might have plans for the following, but if not, I suggest:
      Add a very liberal sprinkling of reference links throughout the guide. People who work with accessibility issues day in and day out know where to quickly find many of the things mentioned in the guide, but your target audience may not. Help them find the quickest route to things like ” the W3C alt text decision tree,” ARIA techniques, etc.

    • Joe Dolson 2:55 pm on June 13, 2014 Permalink | Log in to Reply

      There should be a link for the alt text decision tree; I failed to copy that over from the current version. Whoops! I’ll get that fixed.

      Liberally sprinkling links is definitely an aim; I’ve started on that, but specific suggestions of resources are always welcome. I don’t want to overwhelm with links, either, of course.

      Thanks for your comments! Keeping it short and understandable has been one of the major goals from the beginning.

  • Joe Dolson 6:24 pm on April 28, 2014 Permalink

    Update on WordCamp accessibility planning 

    I had a great conversation with Andrea Middleton at WordCamp Minneapolis this weekend, and we’re making some plans to work on the core accessibility features that WordCamp organizers will need to pay attention to in building their sites.

    Some of the key tasks will include working through the accessibility issues in the base themes available for WordCamp organizers to build from, providing some documentation to help organizers know what design standards they need to meet, and doing some basic training on checking their work.

  • Joe Dolson 9:02 pm on April 15, 2014 Permalink
    Tags: ,   

    Update on accessibility-ready theme tag 

    We’re gradually working the kinks out of the process. There was an oversight in the automated process that added the accessibility-ready keyword to themes, so that only new themes were automatically getting the keyword, and not updated themes that added it. That’s been fixed, which will improve our ability to note themes that need to go through the review process.

    There’s a lot of support for the process, and the theme review team is invested in making this work, but I could use some backup in actually doing the reviews. Even if you don’t have the accessibility background, let me know if you’re interested: I’m happy to provide training to make sure you’ve got the knowledge it takes to do this review.

    • David A. Kennedy 4:00 pm on April 16, 2014 Permalink | Log in to Reply

      @joedolson I can help out with this once I finish up a few other projects. It’s a good place for me to contribute since it’s theme-centric. Feel free to reach out to me with details on how to get started.

  • Joe Dolson 11:14 pm on February 8, 2014 Permalink
    Tags: ,   

    Want to participate in reviewing WordPress themes for the accessibility-ready tag? There’s a trac keyword for that! Themes awaiting an accessibility-ready review.

  • Joe Dolson 8:01 pm on December 12, 2013 Permalink  

    Remove title attributes trac tickets 

    I’ve created all new tickets for each file referenced from the original remove title attributes trac ticket (http://core.trac.wordpress.org/ticket/24766). I originally split it up into 17 separate tickets, but closed 3 of them already, because they had already been committed into 3.8 or earlier.

    I’ve added comments and/or patches, as relevant, on all of the remaining tickets – so please chime in with opinions as relevant! Many of these incorporate situations where a 2nd opinion would be valuable, because the title attribute incorporates relevant information and some alternative handling may be necessary.



    http://core.trac.wordpress.org/ticket/26549 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26550 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26551 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26552 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26553 – 2nd opinion


    http://core.trac.wordpress.org/ticket/26555 – 2nd opinion


    http://core.trac.wordpress.org/ticket/26558 – 2nd opinion


    http://core.trac.wordpress.org/ticket/26560 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26561 – 2nd opinion
    http://core.trac.wordpress.org/ticket/26562 – 2nd opinion

  • Joe Dolson 4:54 am on June 29, 2013 Permalink
    Tags: , , , media, plugins   

    Potentially useful accessibility plug-in I learned about today at WordCamp Chicago: http://wordpress.org/plugins/media-ally/

  • Joe Dolson 3:28 am on April 21, 2013 Permalink
    Tags: , , patch   

    Just submitted: http://core.trac.wordpress.org/ticket/24148. Comments welcome.

    • _Redd 12:13 pm on April 22, 2013 Permalink | Log in to Reply

      I never cease to be amazed, Joe, thank you–yet again.

      I looked briefly at the ticket, and I see obenland has the following question:

      Do we really need additional html elements for the ids? Can’t the labels or the p elements carry them with the same effect?

      My understanding is that ARIA is needed above and beyond simple form labeling and p elements due to the dynamic nature of WordPress. In other words, if a page is updated dynamically for whatever reason, the screen reader will only capture the “old” information in the buffer, without ARIA…

      Is the following a true and correct statement?

      To create a “live” region by which screenreaders may be able to access dynamically updated pages (such as those used in WordPress) using the aria-live property is necessary–simple form elements won’t do.

      Thanks for any input you may have, and thanks again, VERY much, for what you do.

      • Joe Dolson 2:07 pm on April 22, 2013 Permalink | Log in to Reply

        First, this is *not* creating a live region — the native comment form is not a dynamically updated region; although some themes may cause it to be. What this patch is about is incorporating the extra text statements that are contained within the comment form into the labels for the elements that they are associated with using ARIA, so that text is exposed to a screen reader without requiring a second pass through the form.

        The commenter is correct that an extra HTML element is not required in order to attach these IDs; and I was able to eliminate two of them, because the text they’re catching is already wrapped in entirety. A third span is required because the text I needed to catch is not already discretely wrapped by any element.

        Your statement is accurate, yes — but not actually relevant to this situation.

    • andyvaughn 9:02 pm on April 22, 2013 Permalink | Log in to Reply

      Thanks for the thorough look at this, Joe.
      Perhaps this is forest-questioning in a tree-analysis area…but, is it semantically appropriate to be using paragraph-tags for comment-form-email, comment-form-comment, and comment-notes? I always rewrite my comment templates to definition lists, with labels as definition-titles, and inputs/textareas as definition-descriptions, as I felt this was more semantically correct. Am I incorrect? Does this have a negative effect when read as a definition-list? It’s been a while since I’ve used a screen reader.
      Either way, thanks for the work Joe.

    • esmi 9:48 pm on April 22, 2013 Permalink | Log in to Reply

      I don’t think there’s a problem – semantically – with either approach and there are valid arguments for both. From a Real Life accessibility perspective, it might be worth bearing on mind that some (most?) screen reading software will announce content in definition lists in the same manner as content in paragraph tags. So from the user’s perspective, there’s no difference and your definition lists will still work just fine.

      • andyvaughn 9:52 pm on April 22, 2013 Permalink | Log in to Reply

        Thanks for the quick reply, Esmi. It helps to know I’m not causing screen-reader confusion with my preferred form markup.

    • Joe Dolson 9:52 pm on April 22, 2013 Permalink | Log in to Reply

      I’d agree with esmi on this; there may be some semantic value to considering these to be definition lists (although it’s debatable), but there is no accessibility value. It would just be a matter of your own judgement concerning whether the list of inputs should be considered a set of term/definition value pairs. My feeling is that the

      Either way, it doesn’t impact accessibility.

    • Anders Herning 11:16 am on April 24, 2013 Permalink | Log in to Reply

      Awesome work Joe! Really appriciate it! I know it’s not the right approach, but I gotta ask:
      I’ve been searching for the most “popular” accessibility theme for WordPress but can’t seem to find any.
      Do you have any advice on this?

  • Joe Dolson 6:28 pm on April 16, 2013 Permalink  

    Updated Theme Review Guidelines 

    I’ve updated the Theme Review guidelines for Accessibility again. This update takes into a consideration a number of suggestions and questions from Chip Bennett regarding the understanding of issues and how to resolve them.

    Among the changes:

    • Images now state that decorative images must be included with CSS.
    • Headings explicitly states that post and widget titles must be wrapped in headings, to draw the ‘reasonable headings’ guidelines into a context explicitly relevant to WordPress structure as defined by a theme.
    • Link text provides specific techniques for accomplishing the goal.
    • Keyboard navigation provides guidance on testing and specific mention of one of the most common failures for dropdown menus.
    • Contrast references tools for testing.
    • Skip links defines a conforming skip link.
    • Forms defines specific changes that can be made to defaults that would break accessibility.

    Your comments are welcome.

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