1. Claire Brotherton

    It would be great if Astra theme, popular as it is, had the accessibility-ready tag on WordPress.org. According to this thread (https://wordpress.org/support/topic/astra-accessibility-ready-tag-removed/) they did have it at one point, but the tag was removed until the final review. That was most of 3 years ago, and I have not been able to find out if the theme was resubmitted for the accessibility review.

    The funny thing is that on Astra’s site they say:

    Astra is accessible and follows WCAG 2.0 standards. It meets the AA level which is essential for usability.

    It would be nice to see the evidence behind that claim.


  2. Sander van Dragt

    The main problem with accessibility is the term itself. It’s about a universal user experience.

    Let’s ask ourselves: why make a theme and then make it hard to use on purpose? Why make a theme and only allow a subset of people to use it? Do you only allow people with a first name in the first half of the alphabet to log in to your site?

    The industry needs to stop selling it as a checkbox, we need to stop viewing it as something extra to do. It is part of everything we make and do already, not a on off switch.

    It should be expected now, it’s a bug when someone can’t use your theme, and your theme is not inclusive when people can’t use it.


  3. Rod Olman

    I remember reading here on the tavern that the accessibility lead (or was it the whole team) for Gutenberg completely quit because accessbility was completely broken and could never be fixed, and that Automatic wasn’t taking it seriously.

    Has there been any change on that front yet?


  4. Felipe Lungov

    There are a lot of things to comment on this post, but in general I just think things are being looked at from the wrong perspective.

    A small fraction of WP users wants to add a shop to their site – so WP doesn’t come with WooCommerce preinstalled. Few users want to create custom user roles, so there are addon plugins that offer the ability to create them.

    But then suddenly not every WP user needs accessibility aids, and still that must be in core. Even worse, it is being pushed on to 3rd party developers to adopt them in their own products.

    In my opinion, WP core should only have the features that will be needed/used by a large enough fraction of its users. Everything else should be left to extensions (themes and plugins). And under no circumstance should the WP team impose any obligation on these extension developers to include the demands of more users. Especially since this only happens very selectively.

    A lot of the text is about creating empathy with those who need the aids. I can only understand that the author believes that those who do not support accessibility aids in every theme have no empathy for those who need them.

    I can’t speak for everyone else, but that is certainly not my case. It must be awful to have any kind of impairment, and I really hope people who do can find aids in and out of WP that will make their lives easier.

    But I believe the motto should change from “It’s okay to be different” (which is correct in itself, it’s just misplaced) to “It’s okay to add plugins to make your WP more what you need.”


    • Bianca

      It’s an interesting perspective you have, however I think you are looking at it wrong. Accessibility is not a feature and should never be considered as such. In fact accessibility in webdesign has been a blind spot for many years.

      People with a disability are not some marketing target group that you can dismiss, they are a part of the society and should not be subordinated or discriminated. When you build a website that is not accessible, you are in fact doing just that.

      Accessibility on the web goes beyond WordPress (see W3.org). These days web accessibility is even required by law in more and more situations.


      • Peter Shaw

        What you don’t see is the economic loss from developers being forced to make themes accessible when their customers don’t demand it. From an economic point of view, this is inefficient relative to a free market.

        Noting that personally I try to develop with accessibility in mind but that is my choice.


        • Bianca

          I don’t see…? My reply was pointed towards Felipe, who states that accessibility should not belong in core, but in a plugin.

          I don’t build themes for wp.org. However I do client work and always make sure my hours are billable. If you end up with too many unbillable hours in client work then in my opinion something went wrong in the previous process (discussing requirements & expectations, estimation hours and so on). My clients don’t ask for accessibility, but I can surely explain why I think their website should be, especially when building for organizations in the public sector.

          In my opinion, having a theme featured on wp.org is considered to be a privilege and not so much an entitlement. If wp.org raises the bar on theme requirements, like accessibility, I’d rather encourage that.

          Also I think making a theme accessible and building an accessible theme are different things. Building with accessibility in mind might be be less time consuming than fixing an unaccessible theme.

          Like I said, it’s been a blind spot for many years, let’s correct this. Not so long ago websites weren’t responsive, yet here we are.


        • Carolina Nymark

          No, accessibility that is built in from the beginning is not more expensive.

          A button is not more expensive than a div or a span.

          A visible label is not more expensive than the time you put on hiding them or making them look like placeholders.

          Because the HTML, when used correctly, is mostly accessible in the first place, it is the changes and additions that creators add, that makes the websites less accessible.


    • Gareth Gillman

      What you meant to say is “a few people don’t understand how their website needs to be accessible”. If a theme is downloaded 10k times from the .org repo, it could be seen by millions of people who visit the website using the theme. In the US, they have 54m people with disabilities, 18% of the population have some form of disability which requires a modification to the website. Would you like to annoy 18% of your website visitors?

      It makes no difference to the website owner if they have accessibility features enabled in the theme but it will make a big difference to disabled visitors to their website! WordPress is the biggest cms in the world, it should be the leader in accessibility and making changes which impact the way we use the web. If accessibility wasn’t added to the theme, website owners wouldn’t do it, this would impact their visitors and potentially the website owners revenue.

      Adding accessiblity to the theme helps the visitors who need the features but also helps the website owner by being able to allow those with disabilities to use their website, comfortably. There should be NO reason not to be totally onboard with this. It’s a win win for everyone and the website owner doesn’t need to do anything as the theme author is the one putting in the work to add these features.


    • William Patton

      You are welcome to make a theme that does not consider any additional needs and share it with anyone you wanted to. Not all themes are suitable for all users and not all themes are suitable for the .org directory. That is fine, nobody is preventing anyone from doing that :)


  5. Accessibility Matters

    6 years ago on the Tavern. Read the comments and see how little we have learned: https://wptavern.com/wordpress-themes-suck-at-accessibility-its-time-to-fix-it


  6. Mike J

    I read here on the bar that the availability lead (or was it the entire group) for Gutenberg totally stopped on the grounds that accessbility was totally broken and would never be fixed, and that Automatic wasn’t taking it seriously.Has there been any change on that front yet?


  7. Guido

    “Thus far, the team has required only that themes have a working skip-to-content link and keyboard-capable navigation menus.”

    These 2 requirements are still not added to the Theme Check plugin.


    • William Patton

      Because they are usability tests and theme check tests code.

      If you know how to test keyboard navigation and skip links via static analysis please open a PR on theme check and I’ll merge it right away :)


      • Guido

        I always thought Theme Check covers whole theme, so also the frontend features of it. Guess it’s possible to identify a skip to content link, but to do the same for the nav, no idea.


        • William Patton

          It covers as many parts as it can but there are still a few things it doesn’t have the ability to test by just scanning the code.

          Skip links are hard to test they Keyboard navigation I don’t even know how to test that while it’s unrendered code.

          I had my fingers crossed you might have known how but from trying to figure it out myself I know there isn’t a simple code solution. It’s not super efficient but the best tool right now for it is a human with a browser and a keyboard :)


Comments are closed.

%d bloggers like this: