WordPress.org

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 11:59 am on June 27, 2017 Permalink |
    Tags:   

    This week in WPA11y – June 27, 2017 

    WordCamp Europe

    For discussions and plans see: Takeaways from Paris.

    New structure handbook

    We agreed on the following new structure: Per topic short explanations, then links to good articles and examples. The resources do not need to be WordPress specific.
    We’ll need some method for ensuring the currency and accuracy of resources listed, if we’re going to list specific resources. So probably restrict the resources to the most authoritative ones. And we need to check the resources regularly.

    Order of things:

    • make a list of topics
    • add an intro per topic
    • add resources to it

    @samikeijonen and @rianrietveld will start with a spreadsheet gathering the topics, everyone can add possible resources to that later, so we can see what we can use for the handbook.

    Test Gutenberg

    Now Gutenberg is available as plugin we want to install it on our test server and give it to the test team this week. With a clear description on what it does and a link to the issues already reported on GitHub.

    @arush already gave her review: Gutenberg With A Screen Reader: Initial Thoughts And Reactions

    Adjustments Accessibility Coding Standards

    @joedolson is working on a new draft, work in progress.

    New Settings API

    The plugin Settings API enhanced is now an almost complete prototype, but still needs refinements and design. It’s a prototype though, many things could change. We would like feedback from more people before moving on.

    And what else happend

     

    Next meetings

    Next New Setting API meeting: July 3 ,2017 at 16:00 UTC in the Slack #core channel
    Next WPa11y meeting: July 3, 2017 at 17:00 UTC in the Slack #accessibility channel.

     
  • Rian Rietveld 8:32 am on June 27, 2017 Permalink |  

    Takeaways from Paris 

    So the community summit, the contributor day and WordCamp Europe happened in Paris. And this is what we learned from all the discussions we had during that warm week in June:

    Education instead of taking over

    The accessibility team must not try to do everything themselves. Like raise and solve all accessibility trac tickets themselves. What we should do is add to the tickets how they should be solved and let other developers do the patches (or ask them to do). Hopefully this will attract more developers to do accessibility tickets. That way the developers will learn instead of handover to us. Now the team is like a proxy, everything needs to go though us, slowing the process down. What we need to accomplish is that the developers solve the issues themselves, and we just help them if needed.

    Handbook

    The handbook must be replaced by a list of resources, good examples and test tools, with short explanations. We don’t need to write everything ourselves, but make list of links with a short intro per subject. Focus on education and point to good info. In other words: help and educate the developers instead of fixing ourselves.

    Testing and research

    We need to ask more a11y experts from outside the WordPress community to assist us with the testing and research. For this we can reach out to companies specialised in accessibility, ask them if they can sponsor time to do research on WP core and featured projects.

    So this defines 3 tasks for the a11y team

    • Teach: Provide easy to use overview of resources for developers
    • Research: Test and research current and new functionality for accessibility
    • Help: Review and raise accessibility tickets and provide developers with info on how to solve the issues

    This doesn’t mean we won’t be working on tickets and issues on GitHub, we want to move our team focus to research, education and support.

     
    • Milana Cap 10:36 am on June 27, 2017 Permalink | Log in to Reply

      These are all good news. I’m personally happy with more education and pointing on what the output should look like.

      Accessibility covers a lot and it’s difficult for developer to keep track of everything, or even start learning. Having direct guidelines in tickets will help a lot in both ways – accessibility team will have more developers working on tickets and developers will learn faster and with more ease.

      Great discussions’ outcomes 😀

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

    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.

    Testing

    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
    Tags:   

    This week in WPA11y – May 22, 2017 

    Agenda

    • 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

    https://core.trac.wordpress.org/ticket/40822
    https://core.trac.wordpress.org/ticket/40428
    https://core.trac.wordpress.org/ticket/40331
    https://core.trac.wordpress.org/ticket/40330
    https://core.trac.wordpress.org/ticket/37486
    https://core.trac.wordpress.org/ticket/31818
    https://core.trac.wordpress.org/ticket/26504

    Gutenberg

    https://github.com/WordPress/gutenberg

    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.
    https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3AAccessibility

    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

      hi,
      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
    Tags:   

    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

    Proximity

    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
    Tags:   

    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

    https://github.com/wpaccessibility/settings-api-enhanced

    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

    https://github.com/WordPress/gutenberg

    @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

    https://make.wordpress.org/core/2017/04/23/target-browser-coverage/

    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

    https://github.com/wpaccessibility/a11ythemepatterns/pull/10

    @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

    Tickets

    Two tickets were closed this week.

    Widgets

    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)

    Tickets

    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

    Homework

    Test:

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

     
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