WordPress.org

Make WordPress Accessible

Welcome to the official blog for the WordPress Accessibility team.

The a11y group provides accessibility expertise across the project. We work to make sure that WordPress core and all of WordPress’ resources are accessible for all users.

Want to get involved?

Join the discussion here on the blog, or check these areas out:

Weekly meetings

We use Slack for real-time communication.

The team has a meeting every Monday at 18:00 UTC in the #accessibility Slack channel.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 4:20 pm on February 9, 2016 Permalink |
    Tags: ,   

    Summary Team Chat for Februari 8, 2016 

    Core accessibility coding standards

    After discussion with @jorbin some last changes where made on the Accessibility Coding Standards. @jorbin will bring it up at the next Core meeting to make sure there are no objections there.

    Documentation

    @hearvox finished the Quick Start Guide in our Handbook. @rachievee is working to add other pages to expand on topics from the Quick guide that need longer explanations.
    @trishasalas organizes a one time meeting on Februari the 22nd 17:30 UTC to discuss finalizing (for now) the structure for the handbook. In the meantime Trisha is going to begin writing the Plugin section of the Handbook.

    Accessibility Test Team

    Nimbus Hosting is so generous to sponsor the #wpa11y team with a VPS server. Here we can install a production, nightly and trunk version of WordPress and also have SVN and SSH access.
    We will set the server up next week, then we’re up and running again and resume sending tests to our team.

    Accessibility-ready themes

    Joe started to work on a fork of the theme unit test data, focused on accessibility testing – a smaller set of data, eliminating false positives in the data, etc. He will let us know when it’s usable.

    The post with the requirements for the accessibility-ready tag has been improved. There is now more information on how to test a theme to help theme authors better.

    Tickets

    @afercia: Investigation about color contrast continues.

    #26601: Inappropriate content in headings on admin screens.
    @trishasalas will write an new, refresed patch, keeping the add new link visually on the same place but placing it in the HTML outside the h1 heading

    From Februari 16 on we will have an extra meeting to work on tickets. The group has grown so much last year that we need more time to discuss and work on core tickets then we have now in the regular meeting. This ticket meetings will be every Tuesday on 18:30 UTC.

    And from everybody in the a11y team:
    We wish @accessiblejoe a good and quick recovery!

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

      http://a11yproject.com/

      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.

     
  • Rian Rietveld 10:23 am on January 19, 2016 Permalink |
    Tags: , ,   

    Summary Team Chat for January 18, 2016 

    Documentation

    @trishasalas and @rachievee have been working to organize the docs and create some new drafts in the handbook. Work in progress.

    Tickets

    #34780: Updates screen: Plugin and Theme tables improvements
    We discussed removing the scope from the th and td first and then think of a way to set up the layout, not in a table but in another, more semantic way.

    #34625: wp-login.php site title link points to wordpress.org
    We need to research if themes and plugins would break if the title attribute on the logo is removed. Maybe an option is to have no title output by default for the filter. @arush volunteered to own the ticket.

    #35313: Remove title attributes: Posts, Pages, and CPTs screens
    What to do with icons with a title attribute? For a sighted desktop user, the title attribute is the only indication what the icon means. There are many places where the link is just shown as an icon, and here the totle attribute was useful. We discussed how to solve this: we need to develop a core method to handle tooltips effectively. Andrea will open a ticket for this.

    Color contrast: Some browsers do not support the styling of checkboxes and radio buttons. This means that in some browsers give that borders a poor contrast by default.

    @afercia started to open tickets about the color contrast like #35497: List tables: Post format links improvements
    @rianrietveld will make a list of all the color issues in the Admin, we can use as a reference to open new tickets.

    Accessibility guidelines for core

    @joedolson had some comments on the core a11y guidelines; just a couple, minor changes for clarity. Basically well received by the core team. Joe is waiting for a few more comments from members of the core team that did not have to chance to look at them yet.

     
  • Trisha Salas 4:09 pm on January 11, 2016 Permalink
    Tags: , , f   

    Accessibility Handbook Update 

    Today I started to add subsections to the Accessibility Handbooks Contributor Spreadsheet and while I was looking over other Handbooks (Docs in particular) I decided it might be best to streamline content even further to separate Informational content about the team, mission, etc from the actual Resource for Developers.  Documentation has a Docs Handbook for their section as well as links to other Handbooks for Developers.  I’d like to see Accessibility follow that format and have reached out to @sewmyheadon and @topher1kenobe to get some insight into how they approached the process.

    Join us in the meeting today, January 11 @ 18:00 UTC or comment here if you have any thoughts or additional ideas to help us move this project forward!

    Thanks to everyone involved for all the help so far!

     
    • hearvox 4:38 pm on January 11, 2016 Permalink | Log in to Reply

      Trisha, great idea to stick with the formats the other teams have adopted as much as we can. One way would be to compose an intro section for the main a11y page — e.g., the big blue box at the top of: https://make.wordpress.org/docs/
      https://make.wordpress.org/polyglots/

    • hearvox 4:58 pm on January 11, 2016 Permalink | Log in to Reply

      Another issue is there’s two types of Handbooks:
      1. Many of the Make teams have a handbook that describe the team and how to contribute (eg, “About the Docs Team”, “What We Do…”).
      2. Then there’s the how-to handbooks: Theme, Plugin, and Code Ref, which are written for devs (and are NOT about the team): https://developer.wordpress.org/

      Currently, the A11y Handbook is serving both functions: It’s for contributors and about the team, and it has sections directed to devs (not about the team or contributing).

      That probably isn’t a problem for now, while we’re still writing the handbook, and while the Codex is still the main repository of WP knowledge (and still the highest in most search results).

      But it’s something we should consider for later: Once support resources are housed mainly at developer.wordpress.org, that’s where devs will look for a11y info. Maybe we end up splitting the current Handbook into two, one for-devs and one mainly for-team/contributors.

      Not exactly but kinda like there’s a handbook for the Theme Review Team:
      https://make.wordpress.org/themes/

      And the Theme Handbook
      https://developer.wordpress.org/themes/

      BTW, I’m reading the entire Plugin handbook right now. It is really well-written. I hope ours can be this clear:
      https://developer.wordpress.org/plugins/

    • RachieVee 7:13 pm on January 11, 2016 Permalink | Log in to Reply

      I like the blue box idea on the main make.wp a11y landing as well to serve as an intro and a quick way to get a summary of meeting times.

      I like the “tools” section on the polygot handbook. It might be useful to have a section of tools on the handbook for heading/contrast/general a11y checkers.

      If we’re keeping a11y in one handbook for content writers/designers/developers – then I think what we have now separating by audience is great. I also like that I can get all my information from one handbook versus if there were separate handbooks per audience because often, the lines blur and people using WP have several disciplines. It’s probably easier to keep our content consistent as well if we can cross reference between the audience posts on one handbook.

      What I’d like to see after the “Our Mission” or team intro area, is a section that is a general collection of posts on a11y. Mostly for the what’s, why’s and primers. What’s a heading, what’s alt text, why do we make things accessible, what kinds of disabilities/illnesses do accessible sites cater to etc? So that way in the “audience” sections, there’s no repetition of the “basics”. Each post can go right into the topic without feeling the need to introduce the reader to the concept every time, and instead link back to the primer post instead.

      I agree that contributing can be a separate handbook.

      Looking forward to seeing where this goes. 🙂

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

    Summary Team Chat for January 4, 2016 

    Tickets

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

    Documentation

    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
    https://make.wordpress.org/accessibility/

    Make WordPress Accessible> Accessibility Handbook
    https://make.wordpress.org/accessibility/handbook/

    (Draft: outline for A11y Handbook) Accessibility Contributor Handbook
    https://docs.google.com/spreadsheets/d/1tOYzFn9vc7Ff4yGBmDajelrl7XMDUz4PR5H2lB4exI4/edit?usp=sharing

    Make WordPress Accessible> Useful Tools

    Useful Tools

    WordPress Accessibility> Theme Patterns
    https://github.com/wpaccessibility/a11ythemepatterns

    Docs Handbook> Handbooks Style and Formatting Guide> Accessibility

    Handbooks Style and Formatting Guide

    Codex> Accessibility
    https://codex.wordpress.org/Accessibility

    Theme Handbook> Accessibility

    Accessibility

    Theme Review Handbook> Accessibility

    Accessibility

    Theme Review Handbook> Accessibility> #resources

    Accessibility

    Theme Review Handbook> Accessibility> Resources

    Resources

    Theme Directory> accessibility-ready tag
    https://wordpress.org/themes/tags/accessibility-ready/

    Plugin Directory> WP Accessibility
    https://wordpress.org/plugins/wp-accessibility/

    Plugin Directory> Access Monitor
    https://wordpress.org/plugins/access-monitor/

    (Draft: guidelines for Plugins) WordPress A11y Code Standards
    https://docs.google.com/document/d/1iySvDJ4duHYt6YlnnjnBNbU5LKAn1uRBMH8FKAfmswE/edit

    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:
      https://make.wordpress.org/accessibility/useful-tools/
      https://make.wordpress.org/themes/handbook/review/accessibility/resources/
      https://developer.wordpress.org/themes/functionality/accessibility/#resources

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

    Documentation

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

    Tickets

    #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

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar