Make WordPress Accessible

Updates from December, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • hearvox 9:12 pm on December 28, 2015 Permalink
    Tags: ,   

    WP a11y docs list 

    Here’s a collection of all the A11y resources I’ve found at WordPress.org sites (and two Google docs in use for drafting Handbook pages):

    Make WordPress Accessible blog

    Make WordPress Accessible> Accessibility Handbook

    (Draft: outline for A11y Handbook) Accessibility Contributor Handbook

    Make WordPress Accessible> Useful Tools

    Useful Tools

    WordPress Accessibility> Theme Patterns

    Docs Handbook> Handbooks Style and Formatting Guide> Accessibility

    Handbooks Style and Formatting Guide

    Codex> Accessibility

    Theme Handbook> Accessibility


    Theme Review Handbook> Accessibility


    Theme Review Handbook> Accessibility> #resources


    Theme Review Handbook> Accessibility> Resources


    Theme Directory> accessibility-ready tag

    Plugin Directory> WP Accessibility

    Plugin Directory> Access Monitor

    (Draft: guidelines for Plugins) WordPress A11y Code Standards

    Accessibility code standards for WordPress core (similar to above)

    Accessibility code standards for WordPress core

    • hearvox 9:15 pm on December 28, 2015 Permalink | Log in to Reply

      We can use this list to try to maintain reasonably consistent phrasing in our explanations, code in our examples, and references in our various resources lists:

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

      I’d take the WordPress.com support document out of this list; that document is controlled by Automattic, and is completely out of our hands. Also, can you provide a definition of what you mean by “WordPress-made”?

      • hearvox 10:49 pm on December 28, 2015 Permalink | Log in to Reply

        WP.com resource removed. “Wp-made” rephrased. What I mean is: all the a11y resources at WP.org sites, plus the two g-docs for planning a11y resources at WP; i.e., any pages we might find similar language or lists that we may want to keep consistent. (It’s mainly these pages, BTW, from which I’m pulling language and topics fro the Quick Start Guide.)

        • Joe Dolson 12:37 am on December 29, 2015 Permalink | Log in to Reply

          Thanks; I’m still not clear what the definition of “WP-made” resources is; it’s not written above, that I can see. I’m mostly asking because there are at least 2 resources up there that are my personal projects: Access Monitor and WP Accessibility. They’re certainly dedicated to WordPress, but they aren’t “WordPress Made” in any meaningful way.

          • hearvox 1:02 am on December 29, 2015 Permalink | Log in to Reply

            It doesn’t say “WP-made” anymore. Says: “Here’s a collection of all the A11y resources I’ve found at WordPress.org sites.” I included your plugins because there’s language, topics, and resources in them that might be of use when making a11y docs.

  • Rian Rietveld 3:09 pm on December 28, 2015 Permalink
    Tags: ,   

    Summary team chat, December 21, 2015 

    Accessibility standards for core

    There where several comments on the post with the accessibility code standards for core.
    @joedolson will add the relevant remarks. These standards will be added to the WordPress Coding Standards of the core Handbook.


    @trishasalas made a Google Doc with an overview of all the documentation that needs to be written for our handbook. More details about how to help her and contribute to the documentation in the blogpost Accessibility Handbook and Docs Update.


    #34957 #a11y-focus: Standardizing the handling of :focus and :hover
    Moving forward, we’ve established that :focus is the primary transition for when a user interacts with a link or button. :hover is an extension of :focus that comes from a direct action, whereas :focus comes from an indirect action. Because :focus lacks a direct action, it needs to be styled in a way that brings clear visual attention to the element. Michael Arestad (@michaelarestad) is working on the visual update and we’ll move forward with implementing it once we have that complete.

    #26601: Inappropriate content in headings on admin screens
    Consensus is: ‘Add New Button’ === burn it with fire (agreed on by @michaelarestad)
    @trishasalas will write a refreshed patch for this.

    Next meeting

    Next meeting will be in January 4, 2016 at 18:00 UTC

  • Trisha Salas 6:33 pm on December 21, 2015 Permalink  

    Accessibility Handbook and Docs Update 

    Since WordCamp US we’ve gotten a lot more people contributing to the wpA11y Documentation team.  Welcome to Robert Jolly (@iamjolly), Barret Golding (@hearvox), Job Thomas (@jobtex) Scott Mann, Rachel Vasquez (@rachievee) and Nancy Thanki (@nancythanki)!

    The spreadsheet for contributing the the Accessibility Handbook can be found here https://docs.google.com/spreadsheets/d/1tOYzFn9vc7Ff4yGBmDajelrl7XMDUz4PR5H2lB4exI4/edit#gid=0

    The idea is similar to the other handbooks in that you pick a section or even a page within that section and you can be the lead for that part of the handbook.  As you can see some of the sections have very little content (or none at all in some cases!) so we are in need of content creation as well as editing.

    I have also started a basecamp that will hopefully help us to stay organized.  If you would like access to that please either comment here with your email address or you can ping me in Slack @trishasalas.

    Note that no content has been removed from the Handbook, things have just been rearranged.  If you can’t find something you were working on let me know and we can look together 😉

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

    Team meeting summary December 14, 2015 

    The last month, especially after WordCamp US we’ve got a lot more people contributing to the wpa11y team.
    Welcome Robert Jolly, Morten Rand-Hendriksen, Cheo Walker, Sakin Shrestha, Barret Golding, Adam Soucie, Scott Mann and Rachel Vasquez!

    We want to keep all the new people involved, not make them feel lost or left out and leave.
    Therefore we decided to form working groups, assign one lead and divide the new people in the workgroups, so they know what to do and who to ask for help/work. People can jump in and out of groups as work ebbs and flows.

    Working groups


    • Task: Find accessibility issues, write and discuss tickets on core trac and code patches for WordPress core.
    • Lead: Andrea Fercia
    • Contributors: Joe Dolson, Jeffrey de Wit, Sergey Biryukov, Cheo Walker, Trisha Salas, Adam Soucie, Robert Jolly, Rian Rietveld.


    • Task: Write documentation about accessibility in our Handbook and on other relevant places on WordPress.org
    • Lead: Trisha Salas
    • Contributors: Joseph O’Connor, Barret Golding, Richard Senior, David Kennedy, Rachel Vasquez.
    • Joe Dolson and Robert Jolly volunteered to review written content.

    Theme team


    • Task: Find accessibility issues, write and discuss tickets on meta trac and code patches for the website WordPress.org and WordPress.tv
    • Lead: Joe Dolson
    • Contributors: Morten Rand-Hendriksen, Barret Golding, Trisha Salas

    WordCamp themes

    • Task: Review of the WordCamp themes and help with fixing the accessibility
    • Lead: David Kennedy
    • Contributors: Jeffrey de Wit, Adam Soucie

    Test team

    • Task: Test the accessibility of new and exsisting functionallity in and for WordPress core, at the request of the other workgroups and teams
    • Lead: Rian Rietveld
    • Contributors: > 75 volunteers, with different kind of assistive tecnology and/or accessibility expertise

    Accessibility code standards for core

    During the WCUS community summit in Philadelphia we made a start with accessibility code standards for core.
    Joe Dolson put a concept for the a11y code standards together.
    Please look at the concept and comment on it.


    Barret and Trisha are working on a good outine for the documentation, lots of good ideas, work in progress, more next week.


    The last #a11y-headings ticket is #26601 Inappropriate content in headings on admin screens.
    Joe Dolson will look into this, make a decision on how to solve this issue. On the WCUS contributors day we discussed this and the outcome od this was: First get the link out of the heading, without changing the visual design. And after that is committed, start the discussion of removing it conpletely from the post-new.php / post.php pages.

    Next big project for 4.5: Color contrast ratio of the colors used in the WordPress Admin.
    The official colors to use are on make.wordpress.org/design/handbook/foundations/colors/
    Related ticket: #31234 closed Update wp-admin default colors.

    We need to review them and fix contrast ratios for text and background lower than 4.5.
    The tickets we file for this will be labeled #a11y-color.

    Also related:
    #34957 #a11y-focus: Standardizing the handling of :focus and :hover
    Any feedback on this ticket for the project is appreciated by Adam Soucie


    Ideas for meta.trac tickets from Barret:
    1. the skip-to link needs to be closer to.
    2. the skip-to link-text should be visible on focus.
    3. the headings hierarchy is far from W3C standard.

    Idea from Morten: Start a campaign to get WordCamp speakers to caption their own talks.

    To-do for next week

    Read and comment on Accessibility code standards for core.

    Tickets that needs work/discussion
    If you want to work on core, grab one of these tickets and help solving them

    • #31195: Add a user-friendly way to preview site responsiveness in the Customizer
    • #34625: wp-login.php site title link points to wordpress.org
    • #31195: Add a user-friendly way to preview site responsiveness in the Customizer
    • #35029: Remove title attributes: the revisions limit in the Publish box
    • #35050: Remove title attributes: Plugin Cards
    • #35064: Remove title attributes: options-general.php
    • #35076: Remove title attributes: the Featured Image postbox
    • #34957 #a11y-focus: Standardizing the handling of :focus and :hover
    • And every other ticket that focusses accessibility
    • RachieVee 4:18 pm on December 16, 2015 Permalink | Log in to Reply

      Looking forward to helping out with documentation. It’ll be awesome getting those standards that were just posted into the handbook.

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

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