WordPress Accessibility Team Is Mobilizing to Make Accessibility Required for WordPress.org Themes


Throughout the first half of this month, the WordPress Accessibility team has been working together with the Theme Review Team to discuss the possibility of requiring the accessibility-ready tag for themes hosted on WordPress.org. The team will need to create an official proposal to submit to the Theme Review Team in order to make this happen.

In preparation, the Accessibility team is increasing efforts to educate theme authors on accessibility best practices. Joe Dolson published a post with tips for making WordPress themes accessible, which includes basic instructions for making themes work with a keyboard, creating event triggers as accessible controls, and adding supporting text for images.

The Accessibility team also created a GitHub repository for sharing WordPress-specific code examples for accessibility and plans to add resources in the near future. The theme handbook and reviewer’s handbook will potentially need to be reworked in order to account for the new guidelines. “The goal is for those documents to explicitly correlate to the theme accessibility guidelines, so that theme authors have specific guidance on what to do to meet those requirements,” Dolson said at a recent meeting.

The Accessibility team hopes to announcing new guidelines for theme developers in April 2015, which would then be required as of November 2015. Once the guidelines are finalized for both required and recommended items, the Accessibility team will also need to train the Theme Review Team on reviewing for accessibility.

For most traditional WordPress sites, the active theme is the face of the website, and accessibility-ready themes undoubtedly improve the experience of WordPress for users with disabilities. However, making accessibility required for themes is a long and difficult path. The possibility of the requirement already has opposition among Theme Review Team administrators.

When we published about WordPress.org’s newest requirement for themes to be translation-ready, several readers chimed in on the comments to advocate for accessibility to be required. Justin Tadlock, a TRT admin, replied, “As an admin of TRT, full compliance with our current accessibility guidelines is something I’d fight to not make a requirement.

“Unfortunately, making a theme accessible can sometimes mean not respecting a designer’s artistic vision. This is particularly an issue with color contrasts. Anything that would hinder design decisions like this is not something I would support. That’s beyond the scope of what TRT’s role is.”

Even with more education for theme authors, additional guidelines pose another hurdle to overcome in the rigorous review process. Tadlock believes it would stifle submissions from new theme authors. “Requiring accessibility-ready themes would be such a huge barrier to entry for new theme authors that it would be detrimental to the system.”

The Accessibility team is highly motivated to push for this new requirement and is currently working on a precise proposal that will be voted on by the Theme Review Team. “The important thing with the proposal is clarity,” Dolson said, recognizing that it could be blocked if the two teams are unable to communicate effectively about the issues at stake. The decisions made in the first part of 2015 will determine the immediate future of theme accessibility in the WordPress.org Themes Directory.


17 responses to “WordPress Accessibility Team Is Mobilizing to Make Accessibility Required for WordPress.org Themes”

  1. Thanks for sharing, Sarah! It’s a long process to get there, and we’re not aiming to push it in place before theme authors have the resources they need to understand. We don’t yet know just how far we’ll go – what types of accessibility features we’ll be requiring, for example – but there are still a lot of conversations to be had.

  2. I’m with Justin. I’m not willing to cross the design-aesthetic line in what we require of Theme developers. There are certain aspects of accessibility that would be worth considering as *required*; but the entirety of the accessibility guidelines? I think that’s a bridge too far, for all the reasons Justin mentioned in his comment on the linked post.

  3. As far as I’m aware, the Accessibility Team has not been working with the Theme Review Team on this. This has been the Accessibility Team holding meetings on their side of things about the possibility of bringing this up. This is not something we’ve discussed in our theme review meetings, unless I missed something.

    I did want to share some of my concerns. One of my biggest concerns is forcing theme authors to do stuff that core WordPress itself doesn’t do. For example, the “read more” tag default output doesn’t conform to the accessibility guidelines. This is something that should probably be addressed in core rather than as part of theme review.

    My next concern is the even higher barrier to entry for new theme authors. Suppose you’re a new theme author who just coded his first drop-down menu. This is like the most awesome thing in the world to you. Suddenly, someone tells you that the drop-downs can’t be opened via keyboard and you must recode this. While one is better coded, it doesn’t mean the original is incorrect. If someone had told me this the first time I submitted a theme, I would’ve went elsewhere. Any requirement that unnecessarily hinders new theme authors is not OK in my book.

    I mentioned this in my comment, but my other concern is hindering someone’s artistic vision. The color contrast guidelines could very well do this. Sometimes, people just want to design something for the sake of designing it. When TRT starts getting into policing a stylistic theme author decision, we’re going a bit too far. I’d also argue the same thing about sliders that auto-start (even though I hate sliders).

      • As one of the people present, I have to just correct the idea that it was done as the team saying this was to be required. The meeting was about whats and ifs. As was said very clearly, before anything a proposal has to be made to the entire theme review team. We are not one persons opinion, never have been and never should be. I clearly said that this should be brought to the team in the meeting.

        It’s also worth noting the language use has to be done very carefully. The discussions are not about it being required, they began in the community summit talking about a tag that would not be accessibility-ready but (for want of a better word) accessibility-unready.

        I think in any reporting it has to be done with a lot of care at this stage. Nothing is decided, nothing has even got to team discussion point. It’s also being looked at not even being an ‘all requirement’. Maybe it’s 2 or 3 things, maybe it’s 8.. who knows? I don’t think anyone at this stage.

  4. We’re having conversations, but it’s still very early; and we’re not necessarily looking at explicitly transferring the existing accessibility guidelines into a single requirement – but some aspects of them, yes. Even the existing accessibility guidelines only require that a theme has accessible default contrasts or a clearly labeled color scheme that’s accessible; we don’t want to restrict people’s imaginations, but we want people to be able to obtain accessible themes easily with wide choice availability. And yes – where something should be fixed in core, we’d rather fix it in core.

  5. It looks that WP core is improving. New functions in v4.1 added hidden H2 titles for post/posts navigations.

    As for the new themes, designers should adopt good starter themes. If Underscores would have solid accessibility features and people would be encouraged to start designing using those boiler-plate themes, things would move faster.

    Of course every designer can impair accessibility features while designing, but at least they would have solid base, that would still keep them on accessibility path.

  6. Has there been an agreement on how to define “accessibility”?

    Without refinement, that term could encompass anything from dyslexia or color-blindness to significant motor disabilities. Yet each issue requires its own approach.

    If there is going to be any movement on this, I think it should be made considerably clearer which forms of accessibility are being championed and why.

  7. I think that accessibility is important and the team did an outstanding job with reviewers and education.

    However, I agree with Chip and Justin here and at the same time there is no room for more requirements.

    As many of you know we made serious improvements to our guidelines to simplify the overall process and drastically reduced the list of what is required to get the theme accepted.

  8. I think there’s a much bigger danger in making accessibility standards mandatory than anyone has mentioned so far. That danger is that they might actually marginalize groups of users much more than happens now.

    Take the WCAG 2.0 standard on contrast, for example. Essentially, it suggests that more contrast: good; less contrast: bad. Well, for some users, that’s true. But for many (not all) dyslexics, for example, that’s absolutely not true. Too much contrast actually exacerbates the problem. For this group of users, low contrast with colored backgrounds is much more preferable.

    But that runs the risk of causing problems not just for those who need higher contrast, but also for those with certain forms of color-blindness. You could try to overcome that with different focus attributes, for example, but that risks adding clutter and artefacts which may hinder those with other accessibility issues.

    I could go on …

    The point is that any choice of accessibility requirements will thus inevitably help with certain accessibility problems while exacerbating others. Yet, if someone who is now worse off were to complain about these new standards, s/he would be met with the response that the theme is “accessibility-compliant”!

    So we’d have developers systematically producing themes that would be inaccessible to specific groups of would-be users, and yet this result would have been brought about in the name of accessibility!

    Rules are great in certain circumstances. But, in a case like this, what’s much more important is that developers (and site-creators) learn about the issues so that they can make informed choices. No doubt different developers will make different choices, and so we won’t have a whole group of users who are effectively marginalized.

      • I don’t know about impossible, but certainly very, very difficult. And that’s not the point of the WordPress accessibility-ready requirements; these are targeted at a very basic level of accessibility, to ensure that certain fundamentals aren’t ignored. Ultimately, in every case, the accessibility of the site is the responsibility of the site owner – but if we can provide themes that don’t require thousands of dollars in modifications just to meet basic requirements, we’ll make that much less painful.

  9. Great to hear people commenting about accessibility in WordPress.

    A designer can make a site accessible, without sacrificing design or innovation.

    As with web standards and responsive design, education is key.

    How many people are still designing websites and applications using HTML tables for layouts? Using inline CSS? Creating sites that only work on desktops?

    Or using link to add CSS to WordPress, rather than enqueueing CSS?

    I’d love to see people embrace the idea of accessibility in WordPress, rather than push it off.

    As Steve Krug said about accessibility,

    “And not just the right thing; it’s profoundly the right thing to do, because the one argument for accessibility that doesn’t get made nearly often enough is how extraordinarily better it makes some people’s lives. How many opportunities do we have to dramatically improve people’s lives just by doing our job a little better?”

  10. One of the facts of a WordPress theme is that it *cannot* conform to any WCAG standards. It’s not possible as those standards are written, because the standards are about content. However, there are fundamental practices that can be incorporated into any theme (such as keyboard accessibility and visual focus, labeling forms, and providing alternative text for images or image-like objects) which will improve the experience for everybody.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: