Make WordPress Accessible

Category: Core Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 4:00 pm on March 21, 2016 Permalink  

    WordPress goes WCAG 

    With great pride the WordPress Accessibility Team can announce:

    All new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA.

    On February 15th, 2016, the WordPress Accessibility Coding Standards were approved and added to the Core Handbook as a part of the code standards WordPress developers are expected to meet when contributing to core.

    What does WCAG 2 AA mean?

    WCAG stands for Web Content Accessibility Guidelines, created by the World Wide Web Consortium (W3C). These guidelines ensure that people with disabilities can use the web. The current WCAG standards are version 2 and AA refers to the level of accessibility reached. Level A is the most basic standard, while Level AA is used as a reference for a legal standard in many countries worldwide. Level AAA is most commonly only addressed for special dedicated software.

    What does this mean for WordPress core?

    With every release WordPress gets more accessible for users with disabilities. We’re not there yet — a lot of work still needs to be done on current functionality and interface. We need all the help we can get! The accessibility of the Admin (the administration area of WordPress) is getting better and better. We are researching, testing and fixing accessibility issues in the Admin together with the core developers and our great test team.

    What about themes?

    The bundled themes, like Twenty Sixteen, already make it easy for you to create a web site that complies with WCAG 2 AA, so when you set up a new installation of WordPress, you’re already on the right track out of the box.

    In the WordPress theme repository you can search for themes with the “accessibility-ready” tag. These themes have gone through much the same testing process as the bundled core themes. For every theme with this tag, a member of the WordPress accessibility team has personally checked the theme for keyboard accessibility, color contrast, and a variety of other specific accessibility guidelines. We don’t currently have the depth of reviewers to test every theme update, however, unlike with the core themes, so we can’t guarantee that each theme will continue to meet these standards in future updates.

    What about plugins?

    The accessibility of plugins is the responsibility of each plugin author. Neither the accessibility team nor the plugin review team have the resources to review each of the more than 40,000 plugins currently in the repository. If you are a theme or plugin author, please take a look at our handbook for best practices and documentation.

    What’s next?

    Today, 25% of the web runs on WordPress and our mission is to democratize publishing. That is why we will keep moving forward on the accessibility of WordPress: to give everyone, including people with a disability, an excellent and easy to use tool so they can maintain their own website or application.

  • Rian Rietveld 10:13 am on December 15, 2015 Permalink  

    Accessibility code standards for WordPress core 

    During the WCUS community summit 2015 in Philadelphia we made a start with accessibility code standards for WordPress core. Joe Dolson put a concept for the a11y code standards together (see below or as Google Doc).
    These are the standards expected from new code (like feature plugins) at the time it’s to be merged into core. Our target for released code is WCAG2.0 AA.
    Proposed place to put them is the Core Handbook: WordPress Coding Standards, we aim for a short list of very basic things with references to the Accessibility Handbook.

    Feedback (in the comment section below) is very welcome.

    Concept Accessibility code standards for core:

    This document is a list of standards that a WordPress feature plug-in should meet for accessibility in order to be merged into core. These standards are focused on best practices and easily testable concerns.

    The expectations for all code released in WordPress is conformance with WCAG 2.0 at the AA level.

    • HTML Semantics
    • Headings Hierarchy
    • Definition of HTML for Controls
    • Usage of ARIA
    • Color Contrast
    • Keyboard Accessibility
    • Images and Icons
    • Labeling

    HTML Semantics

    Take a pragmatic approach to HTML semantics. Don’t add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element.

    Heading structure

    The H1 is the main heading representing the page title on every core page. For sub sections, use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup should not be used for presentational purposes.

    • Use H2 through H6 to give internal structure to the page.
    • Don’t skip heading levels.
    • Don’t add extra functionality inside a heading, like links or buttons.

    Semantics for Controls

    Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <a href=”url”>. If there isn’t, it should use a <button>

    Related ticket: #26504 Semantic elements for non-link links

    Dynamic Content

    When there are dynamic changes within a page without a page reload you must provide audible feedback with ARIA for important changes, like a successful saving for example.

    [Provide documentation and links for aria-live, wp.speak, etc.]

    Color Contrast

    In most cases, feature plug-ins are not expected to add or modify colors in core. However, if a feature plug-in needs to add new color combinations, those combinations must meet minimum contrast requirements. Minimum contrast requirements are 4.5:1 for font sizes rendering smaller than 24px or smaller and 3.0:1 for font sizes larger than 24px or 19px and bold.

    [in detailed reference, comment on why we’re referencing as pixels]

    Keyboard Accessibility

    Users must be able to reach and successfully interact with all elements on the page that are actionable, including all form inputs, buttons and links by using the keyboard. They must be able to see a visual indicator of keyboard focus. You should be aware that keyboard events may operate differently when a screen reader is running.

    Images and Icons

    Any image resource must include an accessible name. An image can be represented by an actual element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.

    For <img> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included, but left empty.

    For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element. e.g.

    <a href=’this.html’>
    <span class=’dashicons dashicon-something’ aria-hidden=’true’></span>
    <span class=’screen-reader-text’>Something</span>


    For SVG, the SVG should be inline, so that accessible information isn’t hidden from assistive technology. SVG elements should contain aelement with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby. For more information, see http://www.sitepoint.com/tips-accessible-svg/


    All form inputs must include an explicitly associated <label> 

    • Aaron Jorbin 6:02 pm on December 15, 2015 Permalink | Log in to Reply

      This looks great! I am a fan. A few pieces of feedback:

      Under Keyboard Accessibility, I would consider adding specific wording along the lines of “All actions that a user can complete with a mouse, must be completable with a keyboard”.

      For labeling, I think we should add that for all checkboxes and radio buttons clicking on the label must cause the associated field to toggle.

      I would also like to suggest that we add as a requirement all videos included inside core (right now it’s just the about page that usually has a video, but that doesn’t mean other videos won’t ever be added) must be include captioning (even if the captioning is off by default).

      • Joe Dolson 7:38 pm on December 21, 2015 Permalink | Log in to Reply

        The keyboard and labeling suggestions are great, and I’ll definitely incorporate those. I’m wondering if this is the right document for talking about videos included inside core? The document is intended to be geared at code authors primarily, and I feel like while that’s a great policy to have in place, I’m not sure this is the document to put it in. Thoughts?

    • Adam Silverstein 3:48 pm on December 16, 2015 Permalink | Log in to Reply

      Yea! Thanks for working on this. I’m excited to see these standards headed to the handbook. Having a standard in place will help us improve everyone’s efforts.

    • RachieVee 4:07 pm on December 16, 2015 Permalink | Log in to Reply

      This is awesome. My favorite parts here are making use of the screen-reader-text class for images/icons and the semantics for controls. It’ll be great having a guide with examples to reference from the handbook. 🙂

    • Mark Root-Wiley 5:26 pm on December 16, 2015 Permalink | Log in to Reply

      These are so awesome! I can’t wait to see them finalized. The accessibiility progress in WordPress (Core and the community) this past year has been so heartening.

      One issue not included that maybe should addressed is color blindness. WCAG Level A (and AA, then) requires that “color not be used as the sole method of conveying content or distinguishing visual elements.” (http://webaim.org/blog/wcag-2-0-and-link-colors/) The two issues with which I often run into this are:

      • Links. They can’t just be a different color from the text but should be underlined, designed as a button, etc.
      • State. Color should be used as the indicator of a state (which includes :focus, disabled states, toggles, etc.) This might affect the visual :focus requirement in keyboard accessibility.

      This standard can get a little tricky (for instance if you want to support a :visited link state), but aspiring to meet it feels like a bare minimum we should be requiring. For instance, this would at least catch issues like the long-standing Yoast SEO color blindness issue, were that a feature plugin. (https://github.com/Yoast/wordpress-seo/issues/440)

      • Joe Dolson 7:36 pm on December 21, 2015 Permalink | Log in to Reply

        Hi, Mark! We’re not going to address color directly in this document, generally, because we’re aiming to separate developer and designer concerns; that’s why there are issues explicitly addressed about adding new colors. Preparing a document for designers on color choice and WCAG would be great, however; and I’ll definitely look into that. This is supposed to be primarily a code standards guide, and I want to keep it as focused as possible, so it doesn’t become overwhelming.

        • Mark Root-Wiley 1:53 am on December 22, 2015 Permalink | Log in to Reply

          Thanks for the reply, Joe. I had missed that these were so explicitly code focused, but that makes sense to me. If/when the contrast/color/design page were added, I at least hope they would be tightly linked, seeing that developers often make small design decisions for expediency so should be aware of design requirements.

          I had assumed that the Theme Handbook would already have something like this, but I was really surprised to see that the one section on Colors doesn’t really address actual scenarios where colorblindness is a problem: https://developer.wordpress.org/themes/functionality/accessibility/#color (It also uses the word “commonest”…)

          The accessibility-ready requirements similarly don’t seem to touch colorblind-related color requirements.

          • Joe Dolson 9:54 pm on December 28, 2015 Permalink | Log in to Reply

            The accessibility-ready requirements explicitly require that all contrasts in the default settings have to meet WCAG AA contrast requirements. However, since the colors of a theme are the most changed aspect of a theme in actual usage, there’s not a lot to be done with those requirements that is practical.

  • David A. Kennedy 2:34 pm on September 14, 2015 Permalink

    Testing Twenty Sixteen 

    By now, I’m sure you’ve noticed Twenty Sixteen has been released on Github and the theme repository to spur development and testing. If you haven’t tested the theme for accessibility, now’s the time! I mentioned it in a recent chat, and a members from the community have already tested it, but the more the merrier!

    What do I test?

    Test the theme according to the accessibility-ready requirements. Since this is a default theme, you should test for the recommendations too. Also, it’s a good idea to look at the applicable WCAG 2.0 requirements (Link is not the official WCAG requirements, but a more readable version), and test the theme according to those, within reason. This way, the theme can be its best accessibility-wise.

    How do I test?

    The accessibility-ready requirements give some information on how to test. We also have a list of tools that will help when testing.

    How do I report bugs, issues or make a enhancement request?

    What information do you need to know when creating an issue?

    Here’s a good format to follow when creating a bug report:

    Title: Accessibility: ISSUE SUMMARY HERE
    What I Did:
    What I Expected:
    What Actually Happened:

    I’m not a developer, how can I help?

    No problem! You don’t have to be a developer to help out. Test the theme on your favorite operating system with assistive technology. This way, we get a better idea of how the theme works with different configurations. Try to break the theme! Note anything that is confusing, and makes the theme harder to use on the front end.

  • Joseph Karr O'Connor 5:03 am on August 13, 2015 Permalink
    Tags: , ,   

    Team Chat Summary August 10, 2015 

    New Structure Proposed

    Rian Rietveld wrote a proposal on how to structure our work better and plan ahead longer and we discussed it. What follows is examples from the proposal.

    Goals and Issues

    This will be a separate page on make/accessibility and also a main menu item. It gives an overview of our goals for the accessibility of WordPress, the work we (want to) do, how this is organized, how we test, a roadmap for the next year and how we track the progress of issues we are working on. An example of the roadmap for release 4.4:

    Release 4.4 (December 2015, Scott Taylor)
    • Finish still open issues focus from 4.3
    • Semantic heading structure Admin
    • The customizer
    • Handbook
    • Twenty Sixteen (?)

    Central Ideas

    Some central ideas also included in the proposal are keyboard focus, work on the handbook, color contrast, system to better follow tickets including splitting up tickets among team members on which to concentrate, and continue to develop code pattern library. Much more is included in the proposal and for now we will continue to work on the proposal to make it a more formal document to cover our activities over the next year.

    We also talked about the fact that having a planning document to refer to does not obviate the need to address all new features since there is a tight turn around towards the end of a cycle because that’s when the features going into the release are announced. If we don’t follow all new features we might miss one or more that advance to release at the very end.

    When we have it shaped up we will add the planning documentation to this blog in the form of pages and sub-pages to make it a community resource.

    • Samuel Sidler 1:43 pm on August 27, 2015 Permalink | Log in to Reply

      Just wanted to say that I love the idea of a longer term goals for this team! Short term goals are great, but it’s nice to be able to see the short term goals in context of where everything is headed. 🙂

  • Joe Dolson 10:06 pm on September 17, 2014 Permalink
    Tags: 4.1, , tickets   

    WordPress Accessibility Ticket priorities for 4.1 early 

    WordPress 4.1 development is just started. From an accessibility perspective, this means that we know almost nothing about what new features and UI changes will be taking place, but it gives us a great opportunity to work on resolving older outstanding issues or addressing concerns arising out of version 4.0.

    This is a grouping of the tickets currently in the Accessibility Focus report; no new tickets were opened for the purpose of this list.

    One general recurring topic in these tickets is the handling of focus in modals. This is something that could stand some global work: all WordPress modals should be initiated and closed in a standardized way: focus should be assigned to the first focusable item in the modal when it’s opened, focus should be restricted to within the modal while it’s open, and the modal should be closable using ‘Esc’. A thorough review of all modals would be valuable.

    Group 1:

    These tickets have an impact on the front-end use of WordPress. They are very unlikely to be relevant to any new features in development for 4.1, but are longstanding issues and improvements. Because they alter front-end code, they may require more time in trunk to address impact on plugins or themes.

    1. #15926 Add alt attribute support for Custom Header functionality
    2. #24148 Add aria-labelledby attributes to comment form (fixed)
    3. #21221 Image title and alt attribute content should be texturized.
    4. #27402 Add aria-describedby to image gallery output (fixed)
    5. JS #27645 MediaElement.js player & playlist not keyboard accessible (see Issue 1262 and Pull 1090 on MediaElement for reference)
    6. #16433 Extend function to optionally include commenter name in comment_reply_link
    7. #18650 Make archives and categories widgets dropdown ada compliant (depends on #29699)

    #18650 is a particularly long-standing issue which has significant challenges due to the way the front-end HTML would need to change to make the feature accessible. Other features should all be able to be addressed without any major front-end impact.

    Group 2:

    These are areas that received a lot of attention in 4.0, but have outstanding issues. #26167 doesn’t directly relate to the plug-in work done in 4.0, but would be a good area to get resolved. It should be an easy fix.

    1. JS #28892 Customizer – Widgets – Feedback for screen reader users when Moving widgets + other actions
    2. JS #28888 Customizer – Widgets – Screen Readers Don’t Announce Widget Names
    3. #20880 Keyboard navigation in Appearance > Header is broken
    4. #26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header
    5. JS #29371 Media Library: Focus keeps jumping to URL field
    6. JS #29455 Plugin Info Modal Close Button Does Not Announce for Screen Readers
    7. JS #29326 Improve accessibility of edit-selection mode

    Group 3:

    General issues relating to the author experiences, that can impact a user’s ability to author content.

    Add Media Experience:

    1. JS #25103 Submit buttons on form fields in the Add Media panel
    2. JS #23562 Using Speech Recognition Software with the Add Media Panel
    3. JS #28864 Cannot access edit menu options with keyboard inside Image Editor


    1. JS #29838 Post editing area: keyboard accessibility, tab order and focus
    2. JS #27642 Keyboard Accessibility for TinyMCE image panel
    3. #27553 Make WP editor toggle focusable
    4. #21414 Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
    5. #29358 Remove the ‘accesskey` attributes from Quicktags buttons


    1. JS #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

    Group 4:

    Administrator/Designer experience:

    These issues will effect a smaller number of users on fewer occasions because they primarily effect issues related to site set up and configuration. #18801 could really stand some major work; the settings pages in WordPress have a large number of miscellaneous accessibility issues, but I think that the ticket is too all-encompassing as is; we need to open some individual tickets handling specific issues in the settings pages or in the API, so that the issue is more readily addressed.

    1. JS #27592 Screen Reader Users Do Not Know Widgets are Expandable
    2. #27593 Widgets: Toggle arrows on focus need an indicator beside color alone
    3. #18801 Accessibility Enhancements to Settings API

    These are issues that make features more difficult to use, but don’t prevent the usage of the feature.

    1. #26758 Edit Tags form on submission does not stay at the same page and gets redirected
    2. #28873 JavaScript code for adding bookmarklet Press This is hard to access with keyboard only
    3. #25111 Keyboard focus does not stay within Full Screen Editor modal
    4. #26562 Remove title attributes: class-wp-admin-bar.php
    5. CSS/HTML #26504 Semantic elements for non-link links
    6. JS #26601 Inappropriate content in heading on Themes page
    7. #26551 Remove title attributes: link-template.php
    8. #26560 Remove title attributes: rss.php

    Group 5:

    These are tickets we recommend for closure.

    1. #29475 Adding ARIA roles in wp_nav_menu
    2. #26553 Remove title attributes: comment-template.php
  • David A. Kennedy 7:47 pm on August 27, 2014 Permalink
    Tags: 4.0   

    WordPress 4.0 Release Candidate Testing 

    The first release candidate for WordPress 4.0 is out. If you’re interested in testing for accessibility, here’s what to focus on:

    New features in 4.0

    1. Oembed
    2. Insert from URL
    3. Plugin installation
    4. Editor scrolling
    5. Media Library Grid
    6. Customize Panels

    Regressions from 3.9

    We don’t have a definitive list for this, but keep an eye out for anything that’s not working that you know worked in the last version.

    If you run into bugs, follow the instructions from the WordPress.org announcement post:

    Think you’ve found a bug? Please post to the Alpha/Beta area in the support forums. If any known issues come up, you’ll be able to find them here.

    To test WordPress 4.0 RC1, try the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”). Or you can download the release candidate here (zip). If you’d like to learn more about what’s new in WordPress 4.0, visit the awesome About screen in your dashboard ( → About in the toolbar).

    Things to Watch

    We want to keep things simple at this point. Look for any big blockers, like:

    • keyboard traps
    • confusing or non-existent tab order
    • content that can’t be accessed via keyboard
    • content that can’t be accessed via screen reader
  • 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 (https://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.


    https://core.trac.wordpress.org/ticket/26549 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26550 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26551 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26552 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26553 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26555 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26558 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26560 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26561 – 2nd opinion
    https://core.trac.wordpress.org/ticket/26562 – 2nd opinion

  • Graham Armfield 11:30 am on November 28, 2013 Permalink
    Tags: , ,   

    Analysis of what gets into the alt and title attributes when adding an image into a page/post 

    There was some debate in last night’s IRC chat about trac ticket 26270 raised by @yaelkmiller. Her original point was that when adding images to pages and posts, the Alt text box should have more prominence than the Title box – the alt attribute being an important accessibility feature.

    Personally, I think the idea is a good one, but discussion and comments by @helen also revealed some interesting behaviour when inserting images concerning what text ends up in the title attribute of the image, and what text ends up in the alt attribute.

    I’ve done a series of tests using different use cases and they are presented in the tables below – including my expected results and the actual results.

    Uploading images

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    1 Upload image, add it to page with no change to Title box or Alt text box Title attribute set to image name minus suffix Title attribute absent, alt attribute set to image name minus suffix – ie what the Title box was set to
    2 Upload image, add it to page but change Title box, not Alt text box Title attribute set to amended value Title attribute absent, alt attribute set to amended Title box value
    3 Upload image, add it to page but change Alt text box, not Title box Title attribute set to image name minus suffix, alt attribute set to amended value Title attribute absent, alt attribute set to amended Alt text box value
    4 Upload image, add it to page but change both Alt text box and Title box Both title and alt attributes set to amended values Title attribute absent, alt attribute set to amended Alt text box value

    Using images from media library (previously uploaded) without amendment

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    5 Add image from media library that has Title box set but not Alt text box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was before
    6 Add image from media library that has Alt text box set but not Title box Alt attribute set but not title Alt attribute set but not title
    7 Add image from media library that has both Title box and Alt text box set Both attrubutes set Title attribute absent, alt attribute set to whatever Alt text box was before
    8 Add image from media library that has neither Title box nor Alt text box set Title attribute absent, alt attribute empty Title attribute absent, alt attribute empty

    Using images from media library (previously uploaded) but making amendments

    Test No. Use Case Graham’s Expected Result Actual Result in Page
    9 Add image from media library, that has just Title box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    10 Add image from media library, that has just Alt text box set, update Alt text box Alt attribute set but not title Title attribute absent, alt attribute set to whatever Alt text box was amended to
    11 Add image from media library, that has neither Title box set nor Alt text box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
    12 Add image from media library, that has neither Title box set nor Alt text box set, update Alt text box Alt attribute set, no title attribute Title attribute absent, alt attribute set to whatever Alt text box was amended to
    13 Add image from media library, that has both Title box and Alt text box set, update Alt text box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was amended to
    14 Add image from media library, that has both Title box and Alt text box set, update Title box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was originally set to

    Looking at the results

    Using the Add Media Panel to insert an imageThe first revealing thing about these tests is that my own view of how I thought WordPress worked is at odds with the actual results in most cases.

    The second thing that’s become obvious is that it’s actually impossible to set the title attribute for an image whilst using the Add Media panel. The title attribute never appears in any of the results.

    Actually the only way to set a title attribute image within pages and posts is to use the older image edit dialogue box once the image is placed within the page (or to manually update the HTML obviously).

    I think the confusion comes from the labeling of the Title input field in the Add Media Panel. Helen refers to this in her comments on the trac ticket I believe. Maybe to avoid confusion this box should be given another label – ‘Image name’ maybe. I confess that I hadn’t noticed this change in WordPress behaviour – it did used to be possible to directly influence the title attribute of an image when uploading and adding it to a page/post.

    I’m sure that I’m not the only one who didn’t appreciate this situation. There is a plugin called Shutter Reloaded that I’ve seen on a couple of sites, which uses the title attribute from the image to provide a caption beneath the image when the full size is shown. Obviously this plugin is broken if site admins don’t realise the title attributes aren’t being written into the <img> tags – and the plugin author perhaps doesn’t realise either. I can’t comment on other lightbox plugins.

    What do you think? Is this what you expected? Is this the right way to go?

    • Rian Rietveld 3:23 pm on November 29, 2013 Permalink | Log in to Reply

      Hi Graham,
      The addition the title attribute to the element img was removed a few versions of WordPress ago, which is a improvement to my opinion.

      I use the title only for labeling the images in the Media Library, yes, maybe image name is a better description for that input field.

      And it seems logical to add the images name into the alt field if the alt field is empty, but that can result in alt texts like IMG_123. Maybe the best way is to leave the alt text empty unless a user entered a value there.
      An alt=””is always better than an alt=”IMG_123″.


  • esmi 9:00 am on August 9, 2013 Permalink
    Tags: , ,   

    Title Attributes Galore 

    The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any accessibility issues.

    Currently, the excluded methods, functions and scripts are:

    • the_author_posts_link()
    • rss.php
    • wp_fullscreen_html()
    • get_adjacent_post_rel_link()
    • _walk_bookmarks()
    • get_image_tag()
    • the_shortlink()

    (More …)

    • David A. Kennedy 12:02 pm on August 9, 2013 Permalink | Log in to Reply

      I’m wondering if we missed any? I believe some functions, like

      get_the category_list



      have title tags built in as well. I’m not as familiar with core so looking through the diff makes it hard to tell. Commenting here to get opinions and not junk up the ticket.

      • Amy Hendrix (sabreuse) 3:53 pm on August 9, 2013 Permalink | Log in to Reply

        Both of those functions are included in the patch that’s currently on the ticket — you can see the full list at the ticket link.

        The list in this post is just the ones that I left off the patch, either because they’re deprecated functions (which means aren’t actually used in core anywhere, and we normally wouldn’t make any changes to them unless it was for something like security), or because the title attributes are being used for help and not just labels (and in that case, they should get a better solution rather than just being deleted without any kind of fallback).

        It’s definitely not a problem to get this batch in, and still pick up any that were missed in subsequent patches.

        • esmi 4:16 pm on August 9, 2013 Permalink | Log in to Reply

          Understood, But my concern is how to handle wp_fullscreen_html()

          • Amy Hendrix (sabreuse) 5:08 pm on August 9, 2013 Permalink | Log in to Reply

            Yep, got that — I was just trying to answer David’s question about other functions that didn’t appear in this post.

            On with the wp_fullscreen_html() discussion, which is definitely a tougher case than most of these!

    • Joe Dolson 8:58 pm on August 10, 2013 Permalink | Log in to Reply

      I think we need to consider some alternatives for the wp_fullscreen_html labels and interface generally — this is definitely not a simple case of removing the title attributes alone. It should probably be pushed as a separate ticket; it’s related, but it seems sufficiently different that treating it independently is worth while. Thoughts on that?

    • Joe Dolson 5:55 pm on August 21, 2013 Permalink | Log in to Reply

      So, went to work on this to create the ticket, and decided that I first needed to create a ticket on keyboard focus — there are a lot of problems with keyboard focus in the full screen editor, so it’s nearly impossible to use with a keyboard. Ticket 25111.

  • Graham Armfield 4:56 pm on July 8, 2013 Permalink

    Accessibility Objectives for WordPress – Initial Thoughts 

    Some of us have been talking recently about pulling together some accessibility objectives for WordPress. These are things that we feel could, or should, be happening to ensure that the profile of accessibility is enhanced with the WordPress community.

    Ultimately, in order to support Matt Mullenweg’s view on the democratisation of the web by web-related software we want as many WordPress websites as possible to be accessible to as many people as possible. We also need to ensure that the WordPress admin screens are not excluding certain user groups from key parts of functionality.

    With that in mind, here is our initial list of objectives. Please feel free to comment on these, and to suggest others that you think are also important.

    (More …)

    • _Redd 9:07 pm on July 8, 2013 Permalink | Log in to Reply

      Great list, and provides a great map for a path forward. Huge thanks for putting this together.


      Development of formal education and outreach programs

      So that all WordPress core developers can gain a deeper understanding of the range of issues faced by disabled and elderly users.

      I personally don’t think this should be directed only at core developers, or even mainly at core developers. It should be much broader, so that those who support the supporters are educated. For a real-life example, take the instance in which a manager instructed that the words “text size” small, medium, and large from the web page because it interfered with design, or made color choices that would have made it impossible for those with color-blindness to actually read the web page. The outreach should extend not only to those who code or design, but to those who manage, approve, fund, or are otherwise beholden to the creation that is a web page. If managers understood the impact of their decisions, then that alone would enable designers to build accessible features even at the most basic level.

      Thanks again for what you’re doing here.

    • _Redd 9:19 pm on July 8, 2013 Permalink | Log in to Reply

      A couple more things to add.

      1. In the “providing resources” section, what’s the possibility of actually creating a new, accessibility forum in the support forums?

      2. I don’t know how to categorize this, but is it possible to visit “how” accessible themes are made available through WordPress.com and WordPress.org theme search? . I understand the “accessible-ready” tag is a seal of approval, but I’m concerned that the tag may be unfamiliar to a casual user. Perhaps, if we could find out how a casual user searches for such themes (I’m guessing accessible, or accessibility, or a11y) then we could make a point to include those tags so the themes come up better in searches. Right now, for what ever reason, it’s not easy to find them.

      Also, what’s the possibility of adding a pointer to accessible themes from this blog, or some highly visible location?

      Thanks again!

    • Joe Dolson 3:06 am on July 9, 2013 Permalink | Log in to Reply

      The visibility of accessible themes in the WordPress.org theme search is essentially non-existent, as it stands. The theme repository has a controlled tag structure: only the tags listed on the tag filter (https://wordpress.org/themes/tag-filter/) are allowed – there are no tags in the directory not on that list.

      So, we can’t just add random tags; every tag needs to be a unique way of associating that particular characteristic of a theme.

      We can encourage people to use whatever accessibility terminology they choose in their description of the theme; but the “accessibility-ready” tag would still be the only one of definitively pulling up all themes that include that characteristic.

      I’m not sure that the theme search tool is actually all that heavily used; but I don’t really know that. I’ve never used it other than to try and identify accessible themes; searching all terms I could think of.

    • _Redd 12:49 pm on July 9, 2013 Permalink | Log in to Reply

      Thankyou (as always!) Joe.

      Let me try to amplify my remarks a little, because I’m not trying to remove the “accessibility-ready” tag from the equation. Not at all. I just think we should be adding additional tags to address the common way in which people search.

      I guess at the heart of it, I ‘m unsure why adding “random” tags is in conflict with the need to have a unique identifier. The unique identifier of “accessibility-ready” is a seal of approval, and we should “market” it that way. But to FIND accessible themes is something else. Additional tags relative to accessibility would help those themes surface. In my mind, it’s no different than having a unique web-site, and using multiple meta-tags in the header for SEO purposes, or to assist in search, or in using #accessibility and #a11y in Twitter, yet having only one, authoritative Twitter site for the WordPress accessibility group.

      For the particular case where someone is logged into WordPress, and searches for a new theme, they go to the page tab, “Install Themes”. The first way they’ll look for the theme is through a keyword search, so the addtional meta-tags of accessibility, a11y, etc. would help there. But the next place they’ll look is the “Feature Filter”—they have themes organized by colors, columns, etc. Can we coordinate with whomever develops the interface so that we could have a section labeled, “accessibility-ready”, or “accessible”, or something like that?

      I hope I’m making sense. At any rate, thanks again, and I’m always looking forward to whatever further input you may have on the matter. Take care.

    • esmi 1:16 pm on July 9, 2013 Permalink | Log in to Reply

      I ‘m unsure why adding “random” tags is in conflict with the need to have a unique identifier.

      Because the whole theme repo system relies on a limited set pre-defined tags. Throwing it open to random tags would stop that system working effectively.

      Can we coordinate with whomever develops the interface so that we could have a section labeled, “accessibility-ready”, or “accessible”, or something like that?

      We already have someone. Well… two someones actually. Myself and Joe D. We both discussed this at length with the rest of the theme review team (who have been tremendously supportive). In order to develop an a11y audit that would work within the overall theme review system, we needed to come up with a single tag that didn’t “over-promise”. Tagging a theme as “accessible” was quickly dropped as – in reality – there is no such thing. A theme can only facilitate the creation of an accessible site. It is not “accessible” within itself. The tag “accessibility-ready” seemed to be the best option and the tag will be added as an option to the theme tag filter once the auditing process is fully up & running.

    • _Redd 4:01 pm on July 9, 2013 Permalink | Log in to Reply

      Thank you, much appreciated. I see I was ignorant of the mechanics of theme “tagging” in WordPress.

      And, if the accessibility-ready tag will be added to theme tag filter once the auditing process is up and running, then that fact alone will make the accessible themes more visible.

      Best regards, as always!

    • Aaron Jorbin 4:05 pm on July 9, 2013 Permalink | Log in to Reply

      Regarding appointing an accessibility lead, I’m going to strongly disagree with that. We are going to have much more success in the long run with WordPress if it’s not one person’s responsibility, but instead if everyone takes responsibility for it.

      I strongly support developing some common educational materials. Joe – I would love to see your slides from WCCHi converted into an accessible HTML slideshow and put up on github where others can contribute. We can then advocate that others use this base slideshow and present it at WordPress (and other) meetups around the world.

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

      I actually think that an accessibility lead is necessary. Not so much because it becomes one person’s responsibility, but because it means there’s one person in charge of the decision process. There are aspects of accessibility that are decidedly subjective; having a lead helps to reach decisions more quickly.

      Also, while the long-term depends on having a broader understanding of accessibility within the development community, short-term will benefit tremendously from having a go-to person to communicate with.

      Posting those slides and sharing them for contribution is a good idea; I actually have a few different WordPress A11y slide sets, dependent on type of audience, and I could share them separately.

      • Aaron Jorbin 3:07 am on July 10, 2013 Permalink | Log in to Reply

        The person in charge of the decision process is the release lead. If they aren’t an expert should they defer to someone else who is? Yes. Much like they generally do now.

        The problem I see with having an accessibility lead is that creates a situation where the entire team no longer feels responsible for accessibility. Every person that contributes to WordPress should own the accessibility of it.

        • _Redd 2:41 pm on July 10, 2013 Permalink | Log in to Reply

          Hi Aaron, speaking for myself only, I agree with you that each contributor should “own” the accessibility of my websites, but I feel just as strongly that there are many like me, who don’t have the expertise to do much of the significant work that needs to be done. It is precisely because there are “lead” members in the current group, who give of themselves not only with coding expertise, but with feedback, that I feel encouraged to work at learning the code that makes WordPress accessible. It would be too overwhelming for me otherwise.

          For me, an accessibility lead would provide the “backup” needed by beginner-level developers such as myself to enable contributions to the larger (and great) picture that is WordPress–and would directly facilitate growing the group with active members.

        • Joe Dolson 7:09 pm on July 10, 2013 Permalink | Log in to Reply

          Alternatively, not having a lead means that no one person feels specifically responsible for finding an answer to a question; a lead would simply mean a point person.

          I feel that for a release, there should be a single point of contact, so that there’s a clear chain of communication during that release cycle.

    • esmi 6:01 pm on July 9, 2013 Permalink | Log in to Reply

      I actually think that an accessibility lead is necessary.

      I agree with Joe but from a different perspective. I think each project/development needs one person who looks at all phases from an accessibility perspective during development. Otherwise, it’s all too easy for potential issues to get lost in the excitement of coding a new feature. I agree 100% that accessibility is everyone’s responsibility but, from a management pov, I think having one person keeping their eye on this particular ball would be tremendously beneficial.

    • After Gadget 10:13 pm on July 9, 2013 Permalink | Log in to Reply

      I really like what was said in the original post, and I’ve also learned a lot from the comments. For example, I did knows some themes were tagged as being more accessible than others. If there were a way to search for themes by accessibility I would have done that in the past and will probably do that in the future.

      One question I have, and I’m not sure if this is the appropriate place for it, and where it says about getting more people involved in that make WordPress accessible group. I tend not to be very involved because I’m not a developer. I don’t know about writing code, etc. I’m just a user so I’m often unsure what I can really contribute. I do have an idea of something that would make WordPress more usable for me as a blogger who uses Dragon, but I’m not sure where I should post that idea.

      Anyway, I’m really grateful that this group exists and that so much skill and care goes into making WordPress accessible. It really makes a huge difference. Using Blogger is a nightmare in comparison to WordPress in terms of access, both as a blogger with disabilities and as somebody who wants my blogs to be accessible to others with disabilities.

      One of the things I like best about what was suggested above is to have more obvious access tags and info/links on every WordPress site because it really feels welcoming and inclusive as the user was not as tech savvy as most of you are (all of you are?) And I think it encourages other people to think about access when it’s just included everywhere as a normal thing that you might want to be searching for.

      • Graham Armfield 7:06 pm on July 10, 2013 Permalink | Log in to Reply

        Hi @AfterGadget. Just wanted to underline what esmi and _Redd wrote. This group is for anyone who would like to see the accessibility of WordPress improve. And if you have any ideas for improvement we’d love to hear them. I’m especially interested to hear about your experiences with Dragon and WordPress – I think it’s an area that hasn’t received enough attention yet.

    • esmi 10:37 am on July 10, 2013 Permalink | Log in to Reply

      I don’t know about writing code, etc. I’m just a user

      That doesn’t matter. We’d love you to join. The whole point point of this group is that it isn’t just for coders. It’s for users as well. That way, if we pool our resources, we have the skills & experience to recognise potential problems, develop solutions and get them into WordPress core. As an experienced Dragon user, your input would be invaluable.

      • After Gadget 2:21 pm on July 18, 2013 Permalink | Log in to Reply

        I forgot to click “follow” so I could see the responses to my posts until now.

        I use Dragon for everything,including mousing. One of the things that is hardest to do when blogging with Dragon is formatting, such as block quotes, links, centering, inserting images, etc. One of the great things about WordPress for this is that there are keyboard shortcuts for most of those commands, so that I don’t have to click on icon to do them.

        However, to find out what they are I have to hover my mouse over the icon to learn that in the future I use alt shift A for making something into a link. There are two problems with this. One is that hovering a mouse over something is one of the hardest things to do with Dragon, and the other is that part of my disability is severe memory impairment so it’s hard for me to remember which things the keyboard command uses A or U or S, etc.

        So it would be really helpful to have those commands written out somewhere — either on the icons themselves or on some menu that could be visible in the same area as the text box, or ideally both.

        Because what I am doing now is needing to use my touchpad to hover over the thing first find out what the keyboard shortcut is— which is really hard on my wrists — and then write it down on a piece of paper that I can tape to my monitor (writing by hand is also problematic for me). And it will be difficult to get all of those formatting commands onto one small legible piece of paper.

        Maybe these are already written out somewhere and I just need to find them. I know blind users who use screen readers don’t use a mouse to click on icons necessarily, but I am guessing that the text reader reads the alt tag that tells the keyboard shortcut?

        I also am not sure if there is a keyboard shortcut for inserting media. Or for the various steps of inserting media. My memory is that including pictures has been harder for me since I’ve lost most use of my hands, but I can’t remember the specifics. Maybe some of you know what I’m talking about.

        I hope this is helpful and that this is the right place to post this.

    • _Redd 11:21 am on July 10, 2013 Permalink | Log in to Reply

      @After Gadget Your input is more valuable than you can even believe.

      I am NOT a programmer by any stretch of the imagination, but there are many simple things I can do to increase website accessibility. When I try to improve websites accessibility, I am stuck with the horrible option of either writing it on sheer faith that what I am doing is right, or clumsily and inexpertly trying to use assistive technology to test it. I’m not qualified to use that technology, because I am fully sighted and have full use of my hands. I really need the expertise of those who are real and true experts in the use of assistive technology for real and true feedback as to whether the code “works”. We need you, and we need your expertese.

    • David A. Kennedy 2:29 am on July 11, 2013 Permalink | Log in to Reply

      @Graham: Huge thanks for putting this together! There’s a ton of great stuff here.

      @After Gadget: Your feedback and involvement is essential! We developers need you to help ensure we do it right, and continue to get better! 🙂

      Regarding the team lead idea: I think a team lead, especially for each release, is vital. I agree with Aaron (and all of you) that accessibility is everyone’s responsibility, but I think a team lead would help keep communication tight. Yes, accessibility challenges center on code more often than not, but it’s also a communication issue many times. An accessibility challenge has to be explained effectively along with potential solutions and the benefits and drawbacks of each. I see the team lead not so much as being responsible for accessibility, but as the bridge between us and the developers and designers. So much of getting to good accessibility solutions is about trust between the accessibility advocates and the rest of the team. Perhaps rotating this slot would help too? A team approach might strike we balance we need.

      Regarding the accessibility statement: I would love to see this. In addition to the normal these are our standards, this is our process and here’s what to do if you have a problem, I would like to also see some “heart” put into it. That’s difficult to explain here, but I see a big opportunity to for the statement to serve as an entry point for people who know nothing about accessibility to learn something. I think it has to have some passion to it, tracing back to how the web’s initial vision was something that everyone could use easily. WordPress has a chance to reach a lot of people in this way because it’s so widely used!

      Regarding the coding and style guidelines/providing resources: I think creating documentation and resources that talks about how certain areas impact accessibility would be great. For example, if we’re developing theme resources, we might talk about how removing the underline on links effects things, etc. Again, I have some resources that might help, and I plan to do a blog series about the creation of Accessible Zen where I highlight some of this stuff. Happy to use that as a testing ground for some of this.

      Regarding education: this is the key. I think we have to really reach the designers and content creators. They are the front lines of accessibility. Yes, the code is vital, but if I’ve been handed a design with little or no thought given to accessibility, we’re in trouble. Similarly, if I have a site that has content in it that has challenge after challenge, we have a long road ahead of us.

      Those are my basic thoughts. Sorry for the long comment. 🙂 Also, I would be happy to and super excited to help with any of this. 🙂

    • _Redd 9:54 pm on July 11, 2013 Permalink | Log in to Reply

      @David A. Kennedy AWESOME comments….I think we speak for all of us when I say that WE are happy and super excited that you’re here! 🙂 Please join us at our IRC meetings on Wednesdays, if you can, as well as continue to offer any more insights you may have on this blog!

      • David A. Kennedy 12:03 pm on July 12, 2013 Permalink | Log in to Reply

        Thanks, _Redd! I keep meaning to attend the IRC meetings, but always forget. I’ll have to set a reminder. 🙂 I definitely plan to continue to help out wherever I can.

    • _Redd 1:30 pm on July 16, 2013 Permalink | Log in to Reply

      What’s the possibility of setting aside a special web page–or some other common online location–so that developers who need their code tested can put up the test sites in a central location, and those with the expertise to test the code can sign up for real-world testing?

      Something similar to the Khan academy’s page for volunteers, in which lessons that need to be close-captioned or translated are available for volunteers to do so?

      It would allow people who do not code a way to contribute–testing WordPress accessibility and giving the feedback that is so badly needed.

    • _Redd 4:57 pm on July 16, 2013 Permalink | Log in to Reply

      I’m embarrassed to say I wasn’t thinking deeply enough to recommend it for specifically themes, plugins, or core.

      That said, as someone working on a free, accessible theme, I (selfishly) think that a place to test accessibility for themes would probably be a great place to start. Much of our discussion right now is centered on creating accessible themes, so doing so would help us gain some traction in that regard.

      I think core has the trac system anyhow. That’s intimidating to a lot of people. Having a more benign interface for themes would give non-coders a place to contribute. Lessons learned from the “crowd-sourced” testing could benefit everyone. We wouldn’t have to keep re-inventing the wheel every time an accessibility problem is solved.

      And, if a solution works, then perhaps one of the more expert people in the group could take the solution to trac, for consideration of implementation into core.

    • esmi 7:22 pm on July 16, 2013 Permalink | Log in to Reply

      As themes and plugins are not “core”, they may not be suited for a Trac-like system anyway. From a purely personal perspective, I think it ultimately has to be down to the developers of these “3rd party add-ons” to take responsibility for a11y levels & issues in their own work. There’s only so much that WPORG can offer in the way of resources.

      Speaking from a theme developer perspective (as that’s the area that I have the most experience in and where the most centrally coordinated a11y outreach may be coming from), theme developers need to use their standard tools along with the Theme Unit Test data to check a11y levels. Longer term they’ll have the option of submitting their theme for an a11y audit as part of a WPORG theme submission – which should (hopefully) give them some valuable feedback. There’s also the theme reviewers mailing list for additional support – although if a11y-specific questions create too much traffic, there might be room later on to establish a better support resource,. Ideally that would be here.

      Does that help at all?

      • _Redd 1:44 pm on July 18, 2013 Permalink | Log in to Reply

        In light of last night’s meeting, what do you think of the idea of asking for non-coding volunteers, who use screen readers or other assistive technology, to test the survey forms for us?

    • _Redd 7:38 pm on July 16, 2013 Permalink | Log in to Reply

      That does help–and again, thank you.

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