1. joedolson

    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. Chip Bennett

    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. Justin Tadlock

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


    • Sarah Gooding

      Justin, Thanks for leaving your thoughts here. I was referring to the Accessibility meeting held here: https://wordpress.slack.com/archives/accessibility/p1417707822002176 – where a TRT admin was present. I guess that doesn’t qualify as the entire theme review team but it appears some members have been having discussions about the possibility.


      • Tammie Lister

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

    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. Tomas M.

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

    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. Emil Uzelac

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

    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.


    • Jeff Chandler

      Interesting comment. It seems as though there is no way to create a website that caters to everyone at the same time.


      • joedolson

        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. Alan Kellogg

    Then make themes responsive where accessibility is concerned. For viewing let the audience specify what they can and can’t handle, so that on their machine a theme takes on a specific appearance.


  10. Deborah Edwards-Onoro

    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?”


  11. joedolson

    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.


Comments are closed.

%d bloggers like this: