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

  • 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

     

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

    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)

    Homework

    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!

     

     

  • Rian Rietveld 9:53 am on February 20, 2017 Permalink  

    Ideas for the accessibility team at the Community Summit 2017 

    What can the accessibility team do on the  2017 WordPress Community Summit (CS) before WordCamp Europe in Paris?

    Here some ideas, comment below this post if you want to join the CS for the accessibility (a11y) team or if you have suggestions or remarks.

    Note: the deadline for submission is March 3, 2017.
    So we should make final decisions on the a11y team meeting in Slack on Februari 27.

    1. Proposed topics

    The editor

    @joedolson did a writeup on safeguarding the accessibility of the new editor. We have to make plans on how to provide our a11y expertise and resources to the editor team.

    The customizer

    The same counts for the customizer as for the new editor. Although this is a feature already is in core, it continuously needs our attentions and work.

    Education

    How to educate developers and designers more effectively. Ideas: better documentation, different approach for the handbook, accessibility talks, reviews, training, courses, a Day of A11y, etc…

    Get more developers and designers involved

    Set up a plan how to involve more coders and designers to work on a11y tickets in WordPress trac. And if people are joining, how to keep them involved for a longer time.

    Pattern library

    We need to review our GitHub repo a11y theme patterns. Is this the place we want to publish code and is the code still valid (some of it is 2 years old). Does the code validate for WordPress code standards, etc..

    The handbook

    After a few years of trying we just don’t seem to find the time and people to set this up. My proposal is to leave the concept of writing stuff ourselves but instead build a great list of resources and put WordPress specific issues in the core handbook.

    2. Representatives

    So far Andrea Fercia, David Kennedy (probably), Morten Rand Hendriksen, Rian Rietveld and Sami Keijonen (if he can find a sponsor) want to be at the CS.
    Anyone else wants to represent the a11y team?

    3. Help with the organisation of the event

    The CS organisers ask for one or two contributors who are willing to help with: posts, communication, travel assistance, finding sponsors, etc.

    As for the a11y team: the travel expenses of Andrea, David and Rian will be covered by their employers. It would be nice if we could find a sponsor for Sami.
    Who wants to volunteer or sponsor this Community Summit??

    Please put your ideas in the comments, we will discuss this on the accessibility team meeting in Slack February 27, 18:00 UTC.

     

  • Joe Dolson 9:02 am on February 17, 2017 Permalink
    Tags: core-editor, gutenberg   

    Revising the WordPress Editor: Gutenberg and Accessibility 

    One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an accessibility perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

    We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

    The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its core mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

    It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

    While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

    Fundamentals of Accessibility to Consider

    1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
    2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
    3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content block); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

    Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

    It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

    Help develop the new editor

    If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.

     

← Older posts

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