Make WordPress Accessible

Category: Working Group Toggle Comment Threads | Keyboard Shortcuts

  • hearvox 2:28 pm on February 6, 2016 Permalink |
    Tags: ,   

    Accessibility Quick Start Guide in draft: needs vetting 

    The WordPress Accessibility Handbook now has a draft of a Quick Start Guide. The doc needs edits, comments, and vetting.

    We intend this as a resource for developers to quickly grab WordPress-oriented code examples and a11y guidelines. Let’s make sure everything is accurate and clearly explained, and that nothing a11y-critical for WP dev is missing. (This process might also help us identify which topics need further explanations in other Handbook sections.)

    Please review the draft and leave your comments on this post.

    • RachieVee 2:29 pm on February 8, 2016 Permalink | Log in to Reply

      I love that we have this now! And I really like the structure to cover all the basics. I do find it a bit long or hard to read it areas for skimmers. I imagined the quick start to be a “quick” checklist of tips whereas the rest of the handbook can go into depth for those that want to go down that route. I like how the theme handbook avoids large blocks of code: https://developer.wordpress.org/themes/functionality/accessibility/

      And I like how the a11y project offers quick tips and then the “how to’s” go more into depth.


      I feel like we can keep the bullet points and then use those code examples in new posts within the handbook that get linked to from the quick start. This way the quick start can still be treated as a checklist of sorts, don’t do this, make sure you do this, and when the reader wants to know the how’s and why’s if it’s not a quick explanation, there will be another post to provide that.

      I think my favorite part is the screenshots of how a screen reader shows links that aren’t worded accessibly. I’d love to see more examples of how screen readers behave or what it’s like to try and access something that wasn’t made very accessible like sites without :focus or sites that aren’t using semantics properly. Trisha and I were discussing empathy recently, and I think it’s a great way to educate people. A lot of people just assume accessibility is hard to do and the people it’s built for are some rare group and small percentage in the web’s audience. I think the more we can remind others how close this hits to home and how we can make a difference one small change at a time, the more successful we’ll be in convincing people to learn more about accessibility. 🙂

      Ideally it’d be cool if each section in this quick start would link to one or more in-depth articles that cover those sections even deeper. Nice work so far!

  • Joe Dolson 9:38 pm on January 24, 2016 Permalink |
    Tags: , , standards   

    Accessibility code standards for WordPress in draft 

    The accessibility code standards for WordPress have been added to the core handbook and are open for feedback over the next two week. Also see the Core blog announcement and the draft standards themselves!

  • Joe Dolson 9:22 pm on January 21, 2016 Permalink |
    Tags: ,   

    Updates to WordPress theme accessibility guidelines 

    The accessibility-ready guidelines for WordPress themes were updated today. There are no explicit changes to the requirements, but the order of the guidelines has been changed so that it corresponds more effectively to how it makes sense to run tests on the guidelines.

    Additionally, I’ve added some information on how to run tests for each guideline into the guidelines, so that theme developers are more easily able to find information on how to self-test when they’re creating an accessibility-ready theme.

    Review the guidelines.

  • Trisha Salas 6:47 am on January 8, 2016 Permalink
    Tags: ,   

    Summary Team Chat for January 4, 2016 


    #33952: get_search_form() accessibility improvements

    The main issue when using `get_search_form()` is redundancy.  A lot of  “search, search for… search… search button”

    Given that `get_search_form()` is used in both the admin & the front end as well as by themes it was determined that we will look at a uniform search for the 4.6 release.  In the meantime, we will remove the `title` attribute for a quick ‘win’.

    #35187: Remove title attributes: the terms List Table

    The current structure is semantically inaccurate but fixing it will require some design input to rework the list table layout. We have decided to stick with the original plan to remove the title attributes and find solutions for other issues at a later time.

    Accessibility standards for core

    @joedolson posted an updated link to the Accessibility Standards for Core document from last week. https://docs.google.com/document/d/1iySvDJ4duHYt6YlnnjnBNbU5LKAn1uRBMH8FKAfmswE/edit He has asked anyone who is interested to review and make comments.  He will eventually communicate with the core team to get this information into the Core Handbook.


    During the next week I will begin adding sub categories to the sections in this spreadsheet. https://docs.google.com/spreadsheets/d/1tOYzFn9vc7Ff4yGBmDajelrl7XMDUz4PR5H2lB4exI4/edit.

    The hope is to get more of a structure in place to make it easier to contribute.  So that, rather than needing to figure out where content will go you can pick a subcategory page and focus on the content for that page.
    We also discussed consistency as well as what the need to be sure that any of the content we link to from the handbook is vetted by the Accessibility Team as a whole.

    Next meeting

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

  • Jen 5:43 pm on January 4, 2016 Permalink
    Tags: annual survey, contributors   

    2015 Contributor Survey 

    Hi accessibility folks! Thanks for all your hard work and contributions in 2015. Could you contribute few more minutes to fill in the 2015 contributor survey? It will help us establish some baselines around the contributor experience so that we can see how things change over time.

    **This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.**

    The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results by the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could knock it out right after you read this post! 🙂

    There are two sections of the survey. The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).

    The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.

    The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks!

    Note: I used polldaddy for the survey and I’m guessing there some accessibility issues. If any of you have trouble accessing the survey, please let me know what the issues are so I can pass it on to the polldaddy developer, and we’ll work out a way for your to respond in the meantime.

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

    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

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

  • Joseph Karr O'Connor 7:21 pm on November 16, 2015 Permalink
    Tags: , ,   

    Team Chat Summary November 16, 2015 


    Discussion of adding information about accessible content management to either the Codex or the Accessibility Handbook. Decided to add it to Handbook. Keyboard shortcuts will go in the Codex with a link from the Handbook.


    #34681 Consider removing the “Disable the visual editor when writing” option.
    Decided to gather user experience data. Four questions to ask:

        Do you know how to switch between the visual and HTML editor in WordPress?
        If no, please try and figure out how, and tell us how that experience was for you.
        If yes, give us your thoughts about your experience using that feature.
        Do you use the option “Disable the visual editor when writing” in your profile?

    #34625: wp-login.php site title link points to wordpress.org.
    Suggested fix: removing the title attribute, changing the text to ‘Powered by WordPress’, and leaving the filter on that text.

  • Joseph Karr O'Connor 8:15 pm on August 31, 2015 Permalink
    Tags: accesibility, ,   

    Team Chat Summary August 31, 2015 


    More work is being done on headings in admin. Jeffrey de Wit created some tickets some of which are already patched and committed. Follow the headings discussion in #accessibility on Slack.


    Devised a strategy for building out the Make WordPress Accessible Handbook. Page leaders will help others build out the handbook.

    Twenty Sixteen

    Twenty Sixteen is on Github. Twenty Sixteen is also available in the theme directory. It’s not in trunk yet. According to David Kennedy ” I did a accessibility-ready review before it went on Github and the directory to make sure nothing was way off accessibility-wise. It’s solid. Takashi knows the drill.” We will ask the testers to test it. David Kennedy did an #accessibility-ready audit of Twenty Sixteen.


    We continued a discussion about Select2 as an alternative to the autocomplete/tagging input field types. There are two main accessibility issues: it doesn’t do a good job of providing feedback to screen readers and it requires the ‘enter’ key to begin typing for autocomplete, a non-standard interaction. The testers have tested Select2 and it is not very accessible. Rian Rietveld will collect all the data and report next week.

    WordCamp US

    Several of us are submitting proposals for talks at WordCamp US and depending on funding assistance some of us will be attending. Today is the last day for submitting proposals.

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