WordPress Accessibility Team Delivers Sobering Assessment of Gutenberg: “We have to draw a line.”

Shoes on the street
photo credit: classroomcamera DSC03657(license)

WordPress’ accessibility team has published a statement on the level of overall accessibility of Gutenberg. The team, largely a group of unpaid volunteers, collaborated on a detailed assessment that publicly challenges Gutenberg’s readiness for core in a way that no other WordPress team has done through official channels to date. After a week of testing the most recent version of the plugin, the team concluded that they cannot recommend Gutenberg to be used by anyone who relies on assistive technology.

The Accessibility team – like any team in WordPress – has no specific authority over the project. Because we’re a small team of volunteers, we’ve been pragmatic in how we apply the guidelines. We have made tradeoffs in prioritization. Gutenberg is a place where we feel it is necessary to draw a line. The ability to author, edit, and publish posts is the primary purpose of WordPress.

Accessibility team rep Joe Dolson, speaking on behalf of the team, cited cognitive load and complexity, inconsistent user interface behavior, heavy reliance on keyboard shortcuts, and difficulties with keyboard navigation through blocks, among other concerns about Gutenberg. He outlined an example of the keyboard sequence required to do something as simple as change the font size in a paragraph block. It currently requires 34 separate keyboard stops, and even more if the tester doesn’t have prior knowledge of how to navigate Gutenberg.

“Because the complexity of interaction with Gutenberg is an order of magnitude greater than in the classic editor, we believe that Gutenberg is less accessible than the existing classic editor, though it offers many great features that are not available in the current editor,” Dolson said.

This assessment echoes many of the common themes found in Gutenberg’s reviews on WordPress.org, even among the most recent reviews of the latest version. Ratings are currently hovering at 2.3 out of 5 stars. Users have repeatedly said the interface is “far too heavily reliant on hover based functionality.” Even those without accessibility needs find it confusing, unintuitive, and difficult to navigate content. Some testers find it nearly impossible to do what they want to do with it.

The positive reviews recognize the software as a work in progress and testers seem more aware of the overall vision for the plugin. They are excited about some of the more advanced features that blocks offer, but many positive reviewers urge WordPress to give it more time before making it the default editor.

The accessibility team is convinced that the main accessibility issues in Gutenberg stem from design issues.

“Gutenberg is the way of the future in WordPress, but the direction it has taken so far has been worrying,” Dolson said. “We do not want to miss the opportunity to build a modern and inclusive application for WordPress, but in order to achieve that goal, accessibility needs to incorporated in all design processes in the project.

“These problems are solvable. Retrofitting accessibility is not an effective process. It is costly in terms of time and resources.”

In a recent post titled Iterating on Merge Proposals, Gary Pendergast, who is leading the merge of Gutenberg into core, acknowledged that they could have asked for the accessibility team’s help much earlier in the process.

“The Accessibility team should’ve been consulted more closely, much earlier in the process, and that’s a mistake I expect to see rectified as the Gutenberg project moves into its next phase after WordPress 5.0,” Pendergast said. “While Gutenberg has always aimed to prioritize accessibility, both providing tools to make the block editor more accessible, as well as encouraging authors to publish accessible content, there are still areas where we can improve.”

At this time there has been no official response to the accessibility team’s assessment. It does not look like it will meaningfully impact the release date, as Beta 2 went out last night and RC 1 is planned for release today. If the core dev chats are any indication, contributors involved in 5.0 seem to be on board with the ambitious timeline for its release.

In a post titled “Accessibility in Gutenberg is not a one-more feature,” core developer Drew Jaynes urges the project’s leadership and contributors not to compromise core accessibility standards for the sake of an expedited timeline.

“Please let’s not make the ‘new standard’ be that we’re willing to ship technically accessible but perhaps not entirely usable-for-all features; let’s not define it as one that sacrifices standards core to the WordPress experience in the name of perceived expediency; let’s not define it as the new default authoring experience for all users when not all users can use it well,” Jaynes said.

WordPress 5.0 release lead Matt Mullenweg has frequently said the release will ship when it’s ready. He contends that the interface has been continually modified for accessibility needs throughout the process of developing Gutenberg.

Matthew MacPherson, Gutenberg’s accessibility lead, was not immediately available for comment on the team’s assessment. Ultimately, the decision to delay the release will fall to Mullenweg and his leadership team. The accessibility team, however, will not lend its endorsement of Gutenberg at this time:

The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.

Gutenberg is now 20 days away from landing in WordPress 5.0, but this does not leave enough time to solve the design and architectural issues the accessibility team has identified. They have proposed a notice on the 5.0 release to inform administrators of Gutenberg’s inadequacy for users of assistive technology, with a prompt to install the Classic Editor plugin. Many people with accessibility needs depend on the WordPress editor in order to do their work and will need to stick with the old interface. The proposal has been closed with a note indicating that 5.0 will point users to the Classic Editor plugin if they need it.

The mistake of not having consulted accessibility experts in the design phase cannot be easily rectified at this point, but the Classic Editor is still available for those who need to preserve their same workflow. The conflict lies in whether WordPress should ship a new editor that those with accessibility needs cannot immediately use. It is a somewhat painful and frustrating outcome for those users when the entire ecosystem is rapidly moving towards Gutenberg as the standard.

Either the accessibility and usability issues the team identified are not as bad as they purport or this document is a last-minute clarion call that could prevent WordPress from shipping an editor that excludes users who rely on assistive technology. Due to the gravity of their claims, the accessibility team’s statement on Gutenberg demands an official response.

45 Comments


  1. The post was one of the more rationale and reasoned looks at everything, and I really appreciate Joe and the team’s work in putting it together. It’s a starting point for prioritizing the extensive accessibility work that has gone into improving WP’s core editor already, but a key thing we have to fix is the team working in a less adversarial way with all the other contributors to WordPress — for example collaborating on posts like this, not tossing them over the transom. Some things like “icon-only controls,” which are in every modern web app, are going to require further discussion. What’s also getting lost is many things have already vastly improved over our old TinyMCE experience, including galleries, embeds, color picking, adjusting fonts (or design elements at all), and keyboard shortcuts. I’d also like to expand the conversation to cover widgets, nav menus, CodeMirror template editing, and other aspects I consider key to the WP experience beyond just publishing — our accessibility tent should include those and doesn’t currently.

    WP’s super transparent and open development style means that these bumps in teams working together happens in public and that can sometimes cause more polarization as people pick sides or inflame things on Twitter, but the reality is that we are all working toward the same goals. Someone told me they were abandoning WordPress and switching to Squarespace because of the accessibility stuff… without realizing Squarespace’s block editor is way less accessible than Gutenberg, besides the fact that it’s proprietary and commercial.

    We all want open source to win. We all want publishing online to be accessible to as many people as possible. Communication is key and I’m glad everyone is talking to each other more, and we’ve begun to move away from the Twitter-style attacks (“fundamental ignorance and disregard for accessibility and amateurish approach to product management”) to practical next steps and improvements.

    Report


    1. Why not take another 5 or 6 weeks and have core developers work more closely with accessibility team and try yo resolve the issues the report outlined, and make the editor better. Lock the merge as is, stop the further development, and focus on accessibility and testing.

      I just don’t understand why insistance on releasing the WP5 on tight schedule, when delay will help with accessibility issues, and give all WP devs few more weeks with beta versions to further polish plugins depending on the editor. And considering problems with Beta versions and number of bugs reported so far, I don’t ser how all that can be fixed in the next 3 weeks with enough time to test it.

      Report


      1. It’s definitely been considered, and we may still end up delaying the release, but for many accessible technology users Gutenberg improves what you can do and access, or there’s the officially supported Classic Editor plugin to stay with today’s baseline experience. There has also been some good feedback from folks on the team on improvements to Classic Editor that will make it less of an all-or-nothing plugin.

        Despite some differences that still need be resolved, there’s general consensus that the long-term way to create the best WP experience for all types of users is not something you can tack on with 5-6 weeks at the end, but will be the result of continuing the continuous iteration we’ve had with the 42 public releases of Gutenberg so far. It means we can get improvements into the hands of users within weeks following a release, not months (or years) as was the old model with WordPress.

        Report


      2. Thanks for the response Matt! I think that WP 5.0 would benefit from taking extra time to address bugs and plugins related issues, and I hope that when released, WP 5.0 will be great release.

        Since I am testing my plugins with current WP 5.0 beta, I would like to say to anyone planning to continue using old editor, it is easy to disable block editor even without any extra plugins, with one line of code, or few lines if you want to do it selectively. So, kudos to core developers team for making this an easy thing to do.

        Report


      3. I think that WP 5.0 would benefit from taking extra time to address… plugins related issues

        If you mean compatibility with Gutenberg, the ability of developers to test their themes and plugins has been around, well, quite some time. However, I don’t think many are going to do anything more definitive until Gutenberg is part of core and they have no choice to address problems. In this respect, I don’t think holding up WordPress 5.0 will benefit anyone.

        Report


      4. @matt

        To start off, I want to make it clear that I think Gutenberg is the future of WordPress and should absolutely be merged into core at some point. However, I am becoming increasingly concerned at the release schedule.

        Despite some differences that still need be resolved, there’s general consensus that the long-term way to create the best WP experience for all types of users is not something you can tack on with 5-6 weeks at the end, but will be the result of continuing the continuous iteration we’ve had with the 42 public releases of Gutenberg so far. It means we can get improvements into the hands of users within weeks following a release, not months (or years) as was the old model with WordPress.

        You can still have continuous iteration without merging Gutenberg into core yet. Why not just continue to develop it out of core until all the major accessibility issues (see David Finch’s comment) are fixed?

        What makes it so important to merge Gutenberg into core WordPress right now? Why can’t it be delayed several months? People who are impatient to get their hands on Gutenberg can simply install the plugin like they have been able to for the past several months.

        How does it make any sense to release an update with Gutenberg as the default editor, and then recommend a plugin to anyone who has accessibility issues? If you are going to recommend the Classic Editor to people who can’t use Gutenberg due to accessibility issues, then Gutenberg is not ready to be the default editor.

        Continuous iteration does not mean you have to release something that isn’t at a stable point yet for millions of users. You should just keep developing it as a plugin until it reaches that state.

        This push to release Gutenberg in core within the next couple of weeks makes no sense to me. So far I have not seen any real answers as to why… only suggested workarounds for those who will be affected. Workarounds are not solutions.

        Releasing Gutenberg in core implies it is ready for all WordPress users, but clearly, that seems to not yet actually be the case. Therefore, the logical conclusion that I see is to delay merging Gutenberg into core, put a big focus on fixing accessibility issues and resolving any other major bugs, and _then_ merging it into core.

        You may say that getting it into core will help Gutenberg get more testers, but with all the issues it already has, I don’t Gutenberg needs more testers yet. You should be focusing on the issues you already know about and fixing those before releasing it to more people.

        Saying “we’ll fix it in a minor bugfix update” is not a solution. Just because you fix the issue a week or so after release is not a justification for releasing the update with known issues in the first place. It is treating accessibility users as second-rate, which seems to against WordPress’ philosophy.

        Who benefits from Gutenberg being released right now? Plugin and theme devs wanting to integrate would benefit from having extra time to work on integration before the merge into core (since the APIs have only recently stabilized), accessibility users would be happy since they would not be pushed to the side for a couple weeks in favor of a quick release, and people who find Gutenberg difficult to use regardless of accessibility issues would benefit as there would be more time to fix general usability issues. People who want to use Gutenberg right now have always been able to do so.

        Report


      5. One option would be to integrate it into core, but with an “add_theme_support” activation required. Default would be classic editor, while those that are ready can activate Gutenberg.

        That meets the goals of releasing with 5.0, but also allows more time for it to be refined before making it the default editor with 5.1 (or another version).

        Also helps prevent broken sites and doesn’t require installing an additional plugin (which many users I’ve talked with don’t even know exists).

        Report


      6. @Matt,

        for many accessible technology users Gutenberg improves what you can do and access

        Can you share specifically what assistive technology you are referencing?

        Report


    2. @Matt I’m impressed with your ability to dismiss all sorts of constructive criticism as being FUD. Things pointed out by the accessibility team was lifted like a year ago. Not to mention all the constructive criticism from all different parts of the community. It’s just really disrespectful to tackle criticism from the community this way.

      Your standpoint with Gutenberg is very clear for all watching this disaster unfold.

      WordPress is no longer an open source project, it’s an Automattic project. If anyone thinks otherwise then you are naive.

      Report


      1. It is with great regret that I have to agree with you,

        WordPress is no longer an open source project, it’s an Automattic project.

        The community no longer matters it’s whatever Matt wants and we can all suck it up and we might as well just shut-up to as nobodies listening.

        I am one of those annoying disabled people that you forgot about, 34 key strokes to change a font, total joke and please Matt explain how, with my ONE FUNCTIONAL HAND, do I do these 34 key strokes.

        I like Gutenberg in principal but as I have said before your moving to fast to hit a deadline that was never going to work.
        Nobody in the community would ever recommend a plugin with a 2.3 star rating so please explain how it’s ready for the core?

        Report


    3. We all want open source to win. We all want publishing online to be accessible to as many people as possible. Communication is key and I’m glad everyone is talking to each other more, and we’ve begun to move away from the Twitter-style attacks (“fundamental ignorance and disregard for accessibility and amateurish approach to product management”) to practical next steps and improvements.

      I am one of the people who has been critical on Twitter and elsewhere, and I’m exhausted by it. I’m genuinely excited about Gutenberg, and I’ll be very happy to leave all of this acrimony behind.

      But it’s not clear to me what you have in mind when you say “practical next steps,” as though they’re somehow still to be determined. Besides the open accessibility issues on GitHub, the accessibility team’s report pretty clearly identifies some potential improvements and actions.

      Will WordPress 5.0 ship with a notice for administrators about the editor’s accessibility challenges, as the team recommends?

      Will you be asking the Gutenberg team to create a way for individual users to re-map the editor’s keyboard shortcuts?

      Will you be asking the Gutenberg team to reexamine the architecture of the editor to reduce the number of keyboard stops required when editing?

      Will you be asking the Gutenberg team to find ways to replace custom controls with native HTML elements?

      If these things aren’t done by the 5.0 release date, will there be a 5.0.x release that addresses some or all of these issues? (And what kind of timeline would you hope for that release?)

      What steps will you take as release lead to facilitate better communication between teams?

      Report


    4. I can imagine that the person who switched WordPress for Squarespace didn’t do it from comparing both of them and thinking Squarespace superior, but did it from comparing the old and the new WordPress and thinking the old one superior, or, in other words, the WordPress he/show knows and cares about, and the WordPress it may be becoming. The issue here is not technical capabilities, but trust: it is exactly because WordPress is open source and transparent that people can get disappointed at the process, and want to quit as a result; Squarespace, on the other hand, doesn’t have this problem, since the transaction is purely commercial, and their voice on that platform will possibly not count anyway (at least not if they are not profitable customers), but this is known and understood in advance.

      Report


      1. I’m a little suspicious about this “person who said they were switching to squarespace because of accesibility”. Actually more than a little suspicious. What user concerned with the topic of accesibility and in touch enough to know about the working group would then choose squarespace?

        Do any of us recognise this as a typical user, or dev, or stakeholder? I could list 20 more common user types before this one.

        Eg: the user moving to a static site generator. The user sticking on 4.9. The user into forks. The user looking at the API for solutions.

        Now, me personally I have seen the shape of gutenberg and I myself have said I choose “another pagebuilder”. Perhaps Mat refers to me. If thats the case then I’ll clarify. For Accesibility I’ll use 4.9. For visually adept pagebuilder clients I will use DiviBuilder. Why? Its a far superior UI to the API when considered like for like. I am aware thats off topic of accesibility but as I’ve said elsewhere I think a GUI pagebuilder is not a good tool solution for visually impaired peopl and a new API interface should be considered. And for the visually adept, Gutenberg is not competitive.

        Report


  2. I don’t understand why Matt is hurrying so much to get Gutenberg out to masses.

    Report


  3. The statement from the Accessibility Team is stunning. The fact that Gutenberg was not developed to meet the needs of the widest possible user base from the onset is an indictment. Accessibility is not something that is layered on in an Authoring Tool or in Web Content after the work is complete. It is a value which needs to be implemented at the earliest possible moment.

    Report


  4. Accessibility team rep Joe Dolson, speaking on behalf of the team, cited cognitive load and complexity, inconsistent user interface behavior, heavy reliance on keyboard shortcuts, and difficulties with keyboard navigation through blocks, among other concerns about Gutenberg.

    This is a big thing! Not only for users who rely on assistive technology, but also for normal users. I’ve been using Gutenberg for months on my personal blog, and I have the similar experience. I think there should be an update on UI/UX for Gutenberg in later releases, to make it easier to use.

    At this moment, the big question is: is it good enough for release? I agree with Matt that we still can improve the editor after releasing. The first release can be considered as a MVP. But it has to be good enough for most use cases. Personally, I think it’s not there.

    I’m working on making Meta Box plugin to make sure my users have smooth experience when Gutenberg is merged into the core. However, there’s some issues from the Gutenberg that doesn’t make it work, and it might break not only Meta Box but also other custom fields plugin. It’s a bad backward-compatibility and might hurt thousands sites.

    I hope the team can focus on backward-compatibility / existing features, to make them work reliably before release. Other fancy things can be updated later.

    Report


  5. If Gutenberg is so great as Matt claims, while he dismisses most concerns in his reply to this post, then why not release it to all wordpress.com users first? Why should the users of the self managed WordPress setup be used as guinea pigs? Is it because the self-managed users would have a much harder time complaining about the product but some would give bug reports? Instead of massive amounts of complaints in the wp.com support forums etc?

    I don’t understand why there is such a rush to release Gutenberg. I don’t understand why the whole UI and block and HTML comments approach was taken in the first place but thats another issue.

    Report


    1. Independent of other thoughts about the release timeline, or readiness of the new editor, I wanted to reply to your comment about who should have to test it first…

      It’s been available to activate on wp.com ever since the Try Gutenberg callout was included in 4.9.8. Similarly there are a number of major hosts who have been pre-installing and activating the plugin on new accounts/sites for a while.

      There hasn’t really been an increase in complaints or support requests because of it. Now maybe that will change with 5.0. Impossible to say for sure. But up to this point, the data from the actual Gutenberg users (over 1/2 million sites) doesn’t necessarily support the assumption that there will be a massive surge.

      Report


      1. It’s been available to activate on wp.com ever since the Try Gutenberg callout was included in 4.9.8.

        It’s only available to users who use wp-admin. It’s not available to Calyspo users – ie, the default WP.com dashboard a majority of WP.com users use.

        Automattic is using WordPress core as a test bed for WP.com.

        I think part of the reason for this is due to apathy outside Automattic for Calyspo.

        Automattic’s idea for Calyspo was that they’d develop it internally, get buy-in from plugin developers, then
        merge it with core.

        That hasn’t really worked out, plugin authors haven’t embraced Calyspo – their customers aren’t asking for it.

        Matt seems to have decided to flip that development process around as a result of that experience – do it in core first; it puts more pressure on the plugin developers and the community to support it than doing it on WP.com first would.

        Report


      2. the data from the actual Gutenberg users (over 1/2 million sites)

        Which exakt data? Where does this data come from? Where can it be seen in detail? If it can not be seen, why not?

        Report


      3. @Geraldine

        Automattic’s idea for Calyspo was that they’d develop it internally, get buy-in from plugin developers, then
        merge it with core.

        Is that just speculation or was this actually said or implied by someone at some point?

        Report


      4. @Zebulan – it’s been implied in the State of the Word address and in podcast’s Matt has appeared on.

        WP-admin will eventually be replaced by something built with React. Unless someone else comes up with a better alternative (unlikely, given the resources required), then it’s likely that’d be Claypso.

        https://wptavern.com/state-of-the-word-2016-mullenweg-pushes-calypso-as-future-of-wordpress-interface-proposes-major-changes-to-release-cycle

        Report


      5. @Geraldine Interesting. Thank you for the info. :)

        Report


  6. This has been an interesting tale to watch unfold. Matt seems to be having his ironic “Thesis 2” moment. “Let’s change things up dramatically irrespective of the users’ wants and the realities therein, and let the cards fall where they may.” Accelerate commitments, ignore the core constituents, offer paltry options while pressing down harder down on the gas pedal. It contains all the same elements.

    Report


  7. Modifying the interface to accomodate (sic) a11y is the compromise

    Matt, you have just summed up everything that’s wrong with your whole approach. Making a user interface accessible is not a compromise. It is part and parcel of “democratizing publishing.” Or do democracies now only count those with good eyesight who can use a mouse?

    It’s high time developers and designers understood the concept of universal design: http://universaldesign.ie/What-is-Universal-Design/

    Report


    1. While I think that Gutenberg needs to undergo a focused accessibility audit with the full resources of Automattic and the community at hand, I think you are not being genuine here. All of design is a series of compromises that vary in degree of importance. A11y is very important, but you will be hard pressed to find a dev or designer that has not altered/compromised an original design because a11y concerns.

      Report


      1. you will be hard pressed to find a dev or designer that has not altered/compromised an original design because a11y concerns.

        If they had to alter a design, then they were “doing it wrong” in the first place. Every time I have seen a design changed to make it fully accessible, everyone else benefited too.

        Designers might view this as a “compromise” of their original design, but the users don’t.

        Report


  8. Wow. These were my concerns as an average user of WordPress, when Gutenberg was first available to be tested. It was the most frustrating, rage-enducing experience in the world for me, and my main concern was that it wasn’t (and still isn’t) intuitive, and requires one to do SO much more to accomplish once-simple tasks. What used to take me literally a few seconds to do ONE thing, now takes MINUTES – like 30! Gutenberg basically ensures that a writer will get absolutely nothing accomplished.

    I was returning to Joomla, but I was notified that a fork of WordPress was in the works, so I’ll be switching to ClassicPress. Right now I’m just waiting for the fork to go live, so I made sure to block WP updates from installing onto my server.

    Report


  9. Something to ponder:

    Gutenberg in its current form (and future I assume) will encourage content makers to structure their content. Currently the average user just plops content into TinyMCE and hits publish, accessibility and even basic design concepts are not even closely considered.

    I have seen users who have had someone design their site with a variety of site builders not able to change a simple piece of text because it is buried somewhere deep in a structure or in a configuration block in a page they have never ever edited or learned how to edit. They are truly lost. How’s that for accessibility?

    a11y is super important, but I think it will be greatly aided by Gutenberg in the very near future, rather than hindered. There are 2 things at play here:

    1) Using the editor and 2) the content it generates.

    My hope is that the content Gutenberg will generate will be more accessible than ever before due to the fact that accessible elements will be attached to each Gutenberg block as a first class element. Structured content as a result will be also more SEO friendly as Google adopts the new structured pages Gutenberg generates. This is my hope and one that I hope others share.

    As for the actual content creation, this is definitely a challenge, no doubt. It appears that in the rush for a superior experience with new technologies (ie React), the WordPress community and Automattic will be forced to innovate and make the underpinning tech behind Gutenberg accessible. No easy feat, but I am sure it is doable. And admirable!

    But remember, this is innovation. This isn’t just the latest x.x.x release, but a major release. Innovation does require pushing forward, pissing people off, but eventually advancing and making it even easier to create beautiful AND accessible content. My bet is on Gutenberg creating a more accessible web, not one that is less accessible. We just have to be a bit more patient, constructive and probably contribute in ways we have not before.

    Report


    1. You are absolutely right that Gutenberg can improve accessibility concerning content, however this is not a reality yet. People are concerned that, on the day Gutenberg goes live in less than 3 weeks, accessibility will be worse than what it is now. So the issue here is not about releasing Gutenberg or not, but to release it as the default experience on a later date, once all these accessibility potentials become realities…

      Report


      1. It may be worse for a while, I don’t contend this. People who care about a11y will stay at something before 5.0. But to forge ahead and innovate one cannot please everyone. I think Gutenberg will be a watershed moment for the web, after the blood, sweat and tears subside. That may take more than a little while.

        Report


    2. As for the actual content creation, this is definitely a challenge, no doubt. It appears that in the rush for a superior experience with new technologies (ie React), the WordPress community and Automattic will be forced to innovate and make the underpinning tech behind Gutenberg accessible. No easy feat, but I am sure it is doable. And admirable!
      But remember, this is innovation. This isn’t just the latest x.x.x release, but a major release. Innovation does require pushing forward, pissing people off, but eventually advancing and making it even easier to create beautiful AND accessible content. My bet is on Gutenberg creating a more accessible web, not one that is less accessible. We just have to be a bit more patient, constructive and probably contribute in ways we have not before.

      First, it is absolutely possible to make React apps accessible right now, no innovation needed. Second, before you can even talk about innovating when it comes to accessibility, you need to get the basics right first, and that means learning HTML deeply, CSS deeply, learning accessibility fundamentals, learning how to write JavaScript with accessibility baked in, and when and how to use ARIA, good focus management, ETC. All of this is necessary because when you decide to use your favorite framework, you will be able to recognize where it falls short, or where the code snippet you copied falls short so you can then fix it. You have to walk before you run, and the starting place for all of this is knowing what you don’t know. Everybody who works in the field of accessibility has to start with knowing what they don’t know, so you can then go from level to level.

      Report


      1. That’s even more promising! If in fact the solutions are indeed out there, then it’s just a matter of time before one or more volunteers take their experience and knowledge and address the a11y deficiencies.

        Was this level of knowledge available on the Gutenberg project and was it addressed? Sounds like it was not or it was not volunteered. Which leaves it to Automattic to decide how to allocate their limited resources across all that they do. Automattic could have made a business decision for “later.”

        Faulting Automattic for making this decision is unfair because in the end the project to this day has been volunteer driven and if the volunteers can’t or are unwilling to do a11y in Gutenberg then Automattic has to step in. It sounds like the expectation was to have Automattic was expected to address this with paid resources due to their level of expertise that was not available elsewhere. And they “drew the line” so to speak just like so many companies do every day while research and development happens.

        Report


  10. 📂server
    └📁wordpress
    └📁gutenberg
    └📁 accessibility
    └⚠️ This folder is empty

    Report


  11. By the way the way apple does a11y on iOS and OS X is impressive albeit they have had decades to perfect it. The idea of an accessibility editor mode is probably a good idea and rather on creating compromises, there is a special mode to create and alter blocks. This approach of “layering” accessibility is regularly practiced by OS makers and the iOS layer for a11y gives this access instantly to all apps that deploy on the app store.

    An a11y layer in WordPress in general is probably what is needed rather than a break/fix for Gutenberg per se. And of course this is a huge project, but probably something that will help everyone including plugin and theme authors that want to bake in a11y into their product without having to reinvent the wheel.

    Report


  12. I think the most important point in all of this is if you need to “compromise” design after the fact, a11y wasn’t baked into the process from the beginning. There will be issues that need to be fixed always, but you can really limit the risk by making a11y a PR approval requirement.

    Report


  13. I’m surprised that Automattic’s “Head of Computational Design and Inclusion” hasn’t bothered to weigh in on the subject.

    I assumed that this would be kind of a big deal to him.

    Report


  14. Apart from the accessibility shortcomings it is very odd that blatantly the most obvious issue with Gutenberg is locating block elements in the UI, especially once you start using columns and third party blocks. That the dev team behind the project can’t see this strikes me as odd. If they can crack getting this one UX pain point I expect that acceptance of the block interface will improve.

    Report


  15. MM: but a key thing we have to fix is the team working in a less adversarial way with all the other contributors to WordPress — for example collaborating on posts like this, not tossing them over the transom.

    AR: I can’t speak for the rest of the accessibility team, but I should not have to politely ask you not to violate my civil and human rights as a person with a disability yet again, and I should not have to ask you not to turn the Four Freedoms into the Three Obligations plus I left you a freedom as a consolation prize why aren’t you thanking me? I don’t think the rest of the team has been adversarial at all and I’ve attended quite a few of the meetings and bug scrubs over the last year and a half. I will freely admit to being adversarial myself, and will continue to do so without apology until your words and your actions match. Saying you want publishing online to be accessible to as many people as possible and doing it are two very different things. You can’t claim that galleries, embeds, color picking, adjusting fonts (or design elements are improvements when a specific subset of your user base cannot use them until you get around to solving a problem you created by not designing with accessibility in mind from the word go. You can’t claim keyboard shortcuts as an improvement when they are designed without taking into account how people who use a keyboard to do everything on a daily basis actually use that keyboard. You create your own keyboard shortcuts when you need to do so because for some reason or other you cannot use a native element and you cannot replace the missing semantics for your custom element. This is also fundamental to accessibility. So I’d say that statement that you lack fundamental understanding of accessibility is dead accurate, however impolite or uncivil it is. I will wait to see if you answer Brian’s questions below concretely. I would also like to add a few questions of my own: What are you going to do to ensure that this doesn’t happen again? Are you, for example, going to begin to advocate for accessibility in the same way you’ve advocated for translation and internationalization? Are you going to ensure that the developers and designers under your aegis are provided the resources to make sure they are able to design and develop with accessibility in mind from the start? Are you going to ensure that there are policies in place with regard to accessibility that cannot be pushed aside for the sake of expediency? If you answer both my and Brian’s questions in the affirmative and without meaningless plattitudes and you follow through with matching actions then I will be the first person to go to bat for you and shout from the rooftops about the improvements being made because believe me I’d rather not be adversarial. It’s exhausting. But accessibility is far too important to be swept under the rug or shrugged off when it’s lacking for the sake of maintaining business as usual or not bruising egoes.

    Report


  16. This is unfortunate for WordPress.

    The rush to Gutenberg is going to splinter the WordPress community which it already has. The forked ClassicPress in pushing forward and as more and more developers figure out that Gutenberg makes their lives miserable, they will jump ship. Simple things like placing images and changing fonts should not take 10 times longer than before. That’s just plain absurd.

    Over time, the massive reach WordPress has will be diminished.
    I see ClassicPress becoming the new WordPress with the hard-core users and developers. I’m already working with the beta and it’s WordPress the way I like it.

    Yes, it’s been stated that the Classic Editor will remain for years to come, but that is hardly saying it will be there forever.

    The fact that Matt is willing to push out an inferior product to the masses, then work on fixing it is just ridiculous.

    After 15 years of working with and developing for WordPress, it’s time to move on.

    Report


  17. Im not sure what the reasoning is for pushing ahead with Gutenberg in its current state. Regardless of if you think this is the right move for WordPress future or not, ignoring the majority of your community and forcing an editor on them that has a 2.3 score in the plugin repository is astonishing.

    The backlash to WordPress in general right now is so negative and brand damaging. Ignoring your end users & blocking out all negative comments with an ‘it’s not us, you’re using it wrong’ attitude is baffling.

    You’re going to cause your own userbase to splinter. It is absolute lunacy to simply put your head in the sand and plough through.

    If you do your plan as a November or December WP5.0 launch with Gutenberg in core I fear WordPress will become one of those lessons 10 years down the line you hear about… how to ruin something that powered 30% of the web at one point as some kind of teachable lesson not to make the same mistakes.

    It doesn’t matter if Gutenberg going into core is the right move or not at this point – Forget that – the community that makes WordPress so amazing are feeling betrayed & disappointed…people are planning to leave to other CMS’s or go to classicpress in protest.

    Matt & his team have also handled this horribly from a PR perspective. This article is just another example of it.

    I don’t know why the human race, especially in business find it so hard to put their hands up and say ‘You know what may be your right we are going to rethink this’

    Good Luck Matt & the Team – your going to need it

    Report


  18. A view of Gutenberg from a ‘traditional’ WordPress Plugin and Theme development agency.

    Over the past 8 years, our team has built over 100 WordPress plugins (19 of which are open source on wordpress.org) and spent 5 years developing a WP Customizer framework.

    Sorry, that is not an ad – just to let you know that we are WP devs who are very experienced CSS / SaaS, PHP programmers.

    6 months ago we decided that we need to get all of our plugins and Theme framework ready for Gutenberg. Imagine our anxiety when we could barely read Gutenberg React JS let alone write it.

    In order to be able to work with Gutenberg as a team over the last 4 months we have set about learning the following – Firstly JavaScript – ES5 / ES6

    Then React – which we found is much more than just a JS lib – it requires learning

    * JSX
    * React Router
    * Redux
    * Testing (Jest, Enzyme, Cyprus )
    * Web Pack
    * Bable

    React is also evolving with a very active development community – for example, the essential create-react-app latest version just added support for Typescript (another learning curve).

    To date learning all of this involved 450+ hours of study per developer ( and we have not even touched learning Next.js, Gatsby.js, Preact.js, Node.js )

    Now we get to the Gutenberg Docs and find that they are not what we would hope – example Depreciated Blocks are removed in Gutenberg v 4.2.0, whilst Formatting API for extending RichText is new – but there are no Docs for it.

    From a WordPress developers point of view, the barrier to entry to the world of Gutenberg is masive.

    My point here is that it is the same for all of us – What stood out for me was a month ago when the Accessibility team leader Rian Rietveld stepped down from the project.

    On that blog post the number one and number 2 problems cited where:

    The codebase of Gutenberg is difficult for all of us, because no one in the wpa11y team is a skilled React developer. So it was hard to implement changes and write PRs ourselves. What we could do is test, tell what’s wrong and what it should be and hope a developer would pick it up. A lot of a11y work has been done by the Gutenberg team but major issues still exist.

    There was no React developer with accessibility experience in the community, and no React accessibility experts from outside the community willing to work on the issues for free.

    My point is that there are not a lot of React engineers.

    @EyesX makes an interesting and possibly valid point here

    WordPress is no longer an open source project, it’s an Automattic project. If anyone thinks otherwise then you are naive.

    If you look at the Gutenberg contributors for the last 2 months you will see that there are only 52 people contributing to Gutenberg. Of those as close as I can tell from looking at the profiles.

    * 34 Are Automattic employees
    * 18 are developers, the majority of who work for larger agencies (eg Yoast)

    I realize that there are a lot of people who contribute by posting bug reports, testing etc – but these are the people with the knowledge and experience that are contributing to the code base.

    Again my point is – React is a high level and complicated code base and React engineers in the WordPress community from my reading of it are at the moment few and far between.

    Its a massive hurdle for any ‘traditional’ WP developer to climb and from an agency point of view requires a massive dollar investment in training / education.

    Report


    1. I wonder if WP Tavern would consider expanding this comment into an article. It’s an interesting topic that could help many WordPress PHP Devs understand how they can now move towards becoming WordPress JavaScript Devs.

      Report


  19. my only real concern — as a developer — is that WP has taken the React path, instead of Vue.

    Vue is infinitely easier for beginners to grasp, and would be a perfect fit for newcomers wanting to build stuff with WP.

    With React, you’ve added too much complexity.

    Report

Comments are closed.