Make WordPress Accessible

Welcome to the official blog for the WordPress Accessibility team.

The WordPress Accessibility Coding Standards state that

“All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA.”

In an effort to help reach that goal, the A11y Team provides accessibility expertise across the project to improve the accessibility of WordPress core and WordPress resources.

See the Accessibility Coding Standards for more information.

Want to get involved?

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

Looking for support?

If you have questions or need support related to WordPress & accessibility, please visit the WordPress Accessibility forum.

Weekly meetings

We use Slack for real-time communication.

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

You can find out more about our Accessibility Working Groups as well as who you can contact if you’d like to get involved by looking at the Working Groups page.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Rian Rietveld 8:31 am on June 6, 2017 Permalink |

    This week in WPA11y – June 5, 2017 

    WordCamp Europe

    Topics Community Summit (CS):

    • New developments for the the Editor, and how to safeguard it’s accessibility – (Core)
    • Technology version support policies – (Core)
    • How to involve more developers in helping with the accessibility tickets
    • How to proceed with the handbook
    • Addition: Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding standards

    @joedolson will write up a draft for the updated coding standards, for us to discuss on the CS.

    Contributor day:
    All plans are in the Google Doc: List of goals for Contributors day in WCEU.
    And the is also a list of a11y tickets to pick from.


    After June 26th we will start testing again. For this patches and plugins will be installed on our test server and given to the test team.

    To test:

    Next meetings

    There won’t be a meeting or bug scrub on June 12th (due to WordCamp Europe).

    • Next bug scrub: June 19, 2017 at 16:00 UTC in the Slack #accessibility channel
    • Next WPa11y meeting: June 19, 2017 at  17:00 UTC in the Slack #accessibility channel.


  • Rian Rietveld 10:39 am on May 30, 2017 Permalink |  

    X posting Proposal WordPress Community Conduct Project 

    X-posting Proposal: WordPress Community Conduct Project
    Please read + comment on the original post.

    Proposal: WordPress Community Conduct Project

  • Trisha Salas 7:18 pm on May 22, 2017 Permalink

    This week in WPA11y – May 22, 2017 


    • Tickets for 4.8
    • A11y Tasks tickets
    • Testing Gutenberg (and others?)
    • Tickets for Future Releases
    • WCEU Contributor’s day

    In attendance:
    Andrea Fercia @afercia
    Sami Keijonen @samikeijonen
    Joe Dolson @joedolson
    Trisha Salas @trishasalas
    …and others possibly lurking

    Tickets for 4.8

    • tag cloud widget
    • custom logo alt attribute fallback

    Both of these tickets are very close to commit.

    @flixos90 dropped in during the meeting to say 38768 is done! 🎉

    @afercia is currently fixing the tests for the custom logo alt attribute, thanks to @flixos90

    A11y-task tickets

    @afercia helped to define the a11y-task tickets for us.

    To summarize:

    • A11y-task tickets are more related to a11y “topics”. (infinite scrolling, proximity, placeholders, CSS generated content, etc)
    • A11y-task tickets have an educational purpose 😀
    • A11y-task tickets are something we don’t have the resources to address right now, but something we should talk about with other people, to increase awareness.
    • A11y-task tickets are something to point people to when they ask about big a11y pending issues… hey look, there’s this Trac report you can have a look at.
    • A11y-task tickets are something that should be brought to other teams attention (Design Team, for example)
    • A11y-task tickets can be used as tracking tickets for separate smaller tickets.
    Current A11y-Task Tickets




    Everything needs to be tested, from the most basic text operation to the most complex interactions. For example: navigation in text with the keyboard, select text, select all, etc.

    Installing the plugin is very easy if you already use VVV and are familiar with GitHub

    See instructions for installing the plugin here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

    The plugin is not complete yet, but feedback should be given as soon as possible.

    As a reminder: today is May 22nd and the Gutenberg deadline for a first 1.0 version is the end of June, as far as I know.

    There are already several issues open on GitHub with the `accessibility` label.

    Discussion about tickets for Future Releases will be put on hold until we are more comfortable with the state of accessibility in Gutenberg.

    WCEU Contributor Day

    The WCEU Committee has requested that each team come up with a list of goals due by June 9th for contributor day.

    @sami.keijonen asked how we should prioritize and organize tasks given that we will have 30-40 people in attendance.

    @joedolson mentioned “Training is frequently the most valuable part of contributor days – just trying to get people better educated about a11y. Getting a patch done is nice, but getting 40 people to know a11y better has more long-term value. I’d suggest segmenting the group according to experience, and have different plans for groups with more or less experience.”

    The plan is to do both workshops and training along with identifying some simple tickets to have ready.

    Homework for the team is

    • Have a list of goals ready for next week (5/29/2017)
    • Identify some ‘good first bug’ accessibility tickets
    • Graham Armfield 3:14 pm on May 23, 2017 Permalink | Log in to Reply

      I’m attending the WCEU contributor day in Paris. Happy to be used wherever you see fit – whether that’s testing or education. Happy to pair up with anyone working on patches if required.

  • Trisha Salas 1:46 am on May 20, 2017 Permalink
    Tags: GAAD, Global Accessibility Awareness Day   

    State of WP Accessibility 

    The following is a post by Adam Soucie (@adamsoucie)

    Yesterday was Global Accessibility Awareness Day! In celebration, the WordPress Accessibility Team (WPa11y) would like to present the State of WordPress Accessibility for 2017. The WPa11y is always working towards making WordPress more accessible. We have several active projects, and are currently planning larger goals for future WordPress releases. Here’s a breakdown of what we’re looking at for both the present and future of WordPress.

    Current Projects

    The WPa11y has several active projects, ranging from small changes that the average user wouldn’t notice like color contrast in the admin or removing title attributes to larger projects like making sure the new Gutenberg editor is as accessible as possible before launch.

    Tag Cloud Widget

    Andrea Fercia, Sami Keijonen, and David Kennedy are currently reworking the tag cloud widget, as it has several accessibility issues. The tag cloud project involves not only reworking the widget, but updating the bundled themes as well. Each theme handles the HTML output slightly differently, and the team is working on standardizing them. This project was born at the first WordCamp US (Philadelphia 2015) and hopes to see release in time for 4.8.1.

    Enhanced Settings API Plugin

    The Settings API could use some work, so Felix Arntz and Andrea Fercia have created a plugin that ties all of the patches together for easier testing. This enhanced version of the settings API improves on the default render callbacks and proves a more accessible layout. The plugin is available on GitHub and is ready to be tested.


    For more on our current projects, review the April 5th meeting notes where we unveiled all of our current projects.

    Future Plans

    The future of accessibility in WordPress is bright, but filled with work. Just like the rest of WordPress. We have a few big targets including: media, the Customizer, themes management, menus, and plugin management.

    A Media Rework

    The WPa11y’s biggest future priority is a rework of the media system, particularly the Media Library. To be blunt, it’s a mess. It really needs to be rebuilt from the ground up with accessibility in mind, instead of having the team try to graft on accessibility to what’s already there. Because this will be such a labor-intensive project with input and assistance from nearly every group involved in contributing to WordPress, it will take months of planning to accomplish. Still, media is a vital part of WordPress and a vital part of the web experience in general. We’re committed to making it as accessible as possible for a future release.

    The Customizer

    Like the Media Library, the Customizer needs a lot of work. With the Customizer getting more and more focus, now is the time for the WPa11y to be making sure that future updates are accessible while improving what’s already there. It is clear that the Customizer is the future of WordPress. It needs to be accessible.

    How You Can Help

    Accessibility can be scary. It seems like a foreign, complex concept. It isn’t. Testing for accessibility is as simple as using your browser’s inspector to check font sizes and color values or using browser settings to make sure fonts resize. If you’d like to learn more and help contribute to making WordPress more accessible, join the WordPress Accessibility Team for our weekly Slack meetings at 1pm EST on Mondays. We’ll show you the ropes and have you up and contributing in no time!


    If you’re a developer who already knows accessibility, even better. There’s a lot of code that needs to be written or refactored to make each of these projects an accessibility success, and you have an opportunity to impact a large part of the internet, from a user as well as a development perspective. You have the opportunity to create code other WordPress developers can and will learn from. The core WordPress Accessibility Team is very small, and the number who are developers is even smaller. Add to this that every one of us are further constrained by the amount of time we have available to devote to WordPress, and you have a recipe for glacially slow accessibility improvements.


    To be sure, we’re not asking for all of your free time. But wouldn’t it be excellent if everyone who is a developer, already knows web accessibility, and uses WordPress either in their side projects or as part of their business contributed five percent of their working time, or code, back in order to make WordPress more accessible, faster? Right now, there are one hundred and thirty-four accessibility ready themes available for free in the WordPress theme repository, and reviews for the accessibility ready tag can take months, because there’s more demand for the tag than there is supply of reviewers. Imagine how many themes we could have for people to build accessible sites with if there were no cue?


    Please consider contributing to the efforts of the WordPress Accessibility Team if you are able. If you’ve written accessible components for WordPress themes, consider contributing them to the WordPress Accessibility pattern library on GitHub. If you know of a translation of WCAG and its associated documents in a language other than English, send links our way so we can spread them around. And if you can help with any of the projects listed above, please do so.

    • danial1y 11:15 am on May 22, 2017 Permalink | Log in to Reply

      i am a freelancer web accessibility consultant I wanna help you in any project I know WCAG 2.0 and WCAG 2.1 and wanna weekly Slack meetings at 1pm EST today.

  • Trisha Salas 6:08 pm on May 19, 2017 Permalink

    The Last 3 Weeks in WPa11y! 

    Accessibility Tickets in 4.8

    These are the current accessibility related tickets slated for the 4.8 release:

    • #35566 removes the title attribute in the tag cloud widget
    • #38768 adds the site title as the alt attribute to the custom logo

    WordPress 4.8 introduces a few new media widgets as well as the ‘Nearby Events’ widget. Testing should continue to be sure that new accessibility issues aren’t introduced.

    Future Releases

    If you would like to have an impact on future WordPress releases join us during our bug scrubs! During bug scrubs we go through the “awaiting review” and “future release” reports.
    Gutenberg Editor

    The Gutenberg Editor is slated for a big reveal at WordCamp Europe.
    Let’s keep testing for accessibility related issues as development continues.

    You can find installation instructions here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

    Note that it is not a conventional plugin so there are some specific steps to follow.
    Accessibility Tasks

    There are several ongoing tasks with the goal to improve accessibility in the Admin area.

    • Proximity
    • Add widgets screen
    • Menu screen

    Widgets and menu screen

    It’s not a secret that there are many issues in the Add Widgets and Menu screens. What to do? @juliemoynat has suggested some improvements in this ticket: https://core.trac.wordpress.org/ticket/40677


    In web design, the principle of proximity states that related items should be placed close together. By the same token, if things are spaced farther apart they appear to have less relation to one another.

    This principle is so powerful, that it overrides similarity of color, shape, and other factors that might differentiate a group of objects.

    Proximity is especially critical for users with low vision. It will even be addressed in the next draft of the WCAG guidelines! https://w3c.github.io/low-vision-a11y-tf/requirements.html

    An initial ticket has been created, feel free to join in! https://core.trac.wordpress.org/ticket/40822

  • Trisha Salas 2:26 pm on April 27, 2017 Permalink

    Week in WPa11y – April 24, 2017 

    Topics of Discussion

    • Settings API project
    • Gutenberg editor plugin
    • Browser support changes
    • Screen reader text PR
    • Tickets
    • New Widgets to test

    Settings API


    The current approach involves a redesign of the settings pages that is being discussed with some members of the design team.

    The next step is to process the thoughts @helen gave use on the CSS naming conventions. See: https://github.com/wpaccessibility/settings-api-enhanced/issues/6#issuecomment-294011891

    Gutenberg Editor Plugin


    @afercia recommended that we install and test the plugin. Instructions are here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md

    Note that it is not a conventional plugin so there are some specific steps to follow.

    @afercia has submitted a few issues based on the mockups but real (a11y) testing has yet to start.

    Changes in Browser support


    We discussed how the browser support changes would impact the screen reader text PR. @sami.keijonen said we should not use our time so much of finding things to remove at this point. But test new things like settings API and editor and make changes as needed.

    Screen reader text PR


    @ffood submitted a PR to update the screen reader class in the A11y Theme Patterns repo in Github.

    There was some discussion about updating the class in core as well.

    We agreed to merge the PR and also open a new issue in core to modernize the class. The changes in core should take into account end of support for IE 8-9-10


    Two tickets were closed this week.


    There are 2 new widgets to test

    Next meetings in Slack

    • Team meeting on Monday, May 1 at 17:00 UTC in the Slack #accessibility channel.
  • Corey McKrill 7:03 pm on April 14, 2017 Permalink  

    X-post: Nearby WordPress Events 

    Hello! Looking for feedback: https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/

  • Rian Rietveld 7:43 am on April 11, 2017 Permalink  

    Week in WPa11y, April 5 -11 2017 

    Results Editor survey

    Editor Experience Survey Results

    105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.

    Some quotes from the survey questions about accessibility issues with the Editor:

    You need to add more notifications for screen reader when somethings change on the page.

    I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.

    @mapk gave @afrecia a list of all the accessibility related answers for him to take a closer look at.

    WordCamp Torino

    Andrea: There were a variable number of 6-8 participants at the a11y table during the day. That’s a huge number for a11y during contributor days. Most of them were beginners so we’ve spent most of the time on introducing to accessibility. Run some keyboard accessibility testing, followed by an introduction to screen readers basic principles. In the last part of the day we’ve discussed all together #35497 – List tables: Post format links improvements.

    Dana Donato (@danuccia) joined the WPa11y meeting in Slack after joining the contributors day in Torino. She wants to help with tickets.

    Summary of the discussion during the Settings API meeting

    Notes by @afrecia:

    • use more settings sections to group fields that belong together (note: sections that group logically related controls should be fieldset elements)
    • GitHub flow: use distinct branches for design/layout changes and Settings API improvements
    • planning new GH issues to open
    • CSS naming conventions: the general issues here are trying to establish easy and maintainable patterns, taking into considerations the CSS Roadmap
    • keep selectors specificity as low as possible, avoid overqualified selectors
    • @helen suggested selectors should also provide a context:
      • “In an ideal world, you would have some baseline stuff for elements themselves, and then you scope upward to apply specific stuff based on context as needed”.
      • “The goal should be for people (devs) to not have to do anything involving class names or CSS the vast majority of the time.”
    • @helen will try to start a doc to dump thoughts on the best option we have for CSS naming
    • CSS classes to target stuff in JS: they should be separate from classes used for styling
    • CSS classes for state naming for JS (e.g. .is-active or .is-dismissible)


    Proposal for a new a11y-task ticket:  CSS generated content.

    We’ve discussed a few times the issue about font icons or other characters generated with CSS ::before and ::after. In some cases, they can be announced by screen readers. At the moment, the only way to make sure they’re not announced is using a <span aria-hidden="true"> element and target that with ::before and ::after rather than the main element. We should progressively introduce this as a best practice and also make people aware of the problem.

    Andrea will write the ticket and @trishasalas will do research on how CSS content is used in core.

    Note: a11y-task tickets are issues that should be addressed but we don’t have time and resources to tackle right now. Starting a discussion about them would be valuable though.

    Current work a11y team



    • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php
    • Settings API plugin

    Both are also installed on our test server at wpaccess.org

    Interesting reads this week

    Next meetings in Slack

  • Rian Rietveld 8:03 am on April 4, 2017 Permalink

    Week in WPa11y, March 29 – April 4 2017 

    New keyword a11y-task

    @afercia created a new tickets keyword a11y-task. These tickets aim to start a discussion and spread awareness about a11y issues that maybe can’t be resolved so soon. It’s also a way of being able to find accessibility tasks that we aren’t actively working on.

    Current work a11y team

    Gutenberg: as soon as the featured plugin is released we will test it.

    Tag Cloud adjustments (tag-cloud): #35566 #40187 #40186 #40184 #40138
    @samikeijonen and @davidakennedy

    Settings API plugin: @flixos90
    Felix released the plugin on GitHub: https://github.com/wpaccessibility/settings-api-enhanced which at the moment does exactly the same as the latest patches on #39441
    We can work on this plugin to iterate to the one-column layout we aim to have for admin forms.
    The advantages of developing in GitHub are:

    • Users can easily test the latest changes without us being required to do extra work.
    • Better diffs (because of individual commits) so that we can easier see what has changed over the last “patch”.
    • Easier collaboration (more people are familiar with git).

    Once we get to a first version of the one-column layout that is ready for testing, we should consider also adding the plugin to the wordpress.org plugin repo and formally announcing it as a feature project. This will allow us to hopefully get more voices on the honestly quite drastic changes and also to ask for user testing.

    Colour contrast in the Admin: @adamsoucie

    Required fields @rianrietveld

    Non-link links: @cheffheid

    Remove title attribute in the Admin: any volunteer

    To be worked on later

    Test requests (keyword a11y-feedback)


    Test the patches for

    • #35497: List tables: Post format links improvements
    • #31476: Semantic elements for non-link links: /wp-admin/includes/widgets.php

    Test the plugin Settings API Enhanced

    Interesting reads this week

    Next meetings in the Slack #accessibility channel

    • Team meetings are on Mondays at 17:00 UTC in the Slack #accessibility channel.
    • Trac ticket discussions (bug scrub) are on Mondays at 16:00 UTC
  • Rian Rietveld 10:52 am on March 21, 2017 Permalink  

    Accessibility discussions and work at WordCamp London 2017 

    At WordCamp London the a11y team worked during the contributors day and the two days after that on several issues. We where privileged to have Adrian Roselli joining us for two days to pluck his brain.

    Besides working on a11y tickets on trac we spend a large amount of time discussing and making decisions:

    Settings API: @karmatosed agreed to go for a one column design. @flixos90 will work on a patch and we will ask for the design team to help us. Summary of the Settings API discussion.

    Use of a code editor instead of the Text editor@grahamarmfield tested Code Mirror with Dragon NaturallySpeaking, and we discussed what the consequences would be of implementing this or any other code editor or syntax highlighter. Overall conclusion: A code editor is useful, but it should be implemented as an opt-in, not as default until there is an accessible version available. Summary of the Code Editor discussion.

    Gutenberg: The new block based editor. We researched and discussed the editor prototypes on Github and together with Adrian came with a list of recommendations to safeguard the accessibility. Issue at the Guterberg GitHub repo.

    Thanks for joining in the discussions and the work: @karmatosed @afercia @flixos90 @grahamarmfield @samikeijonen Adrian Roselli @hedgefield @abrightclearweb @moorscode and many others.

    And a huge thank you for the organisers of WordCamp London!


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