W3C Selects Craft CMS for Redesign Project

W3C has selected Craft CMS over Statamic for its redesign project, after dropping WordPress from consideration in an earlier round of elimination:

In the end, our decision mostly came down to available resources. Craft had already committed to reach AA compliance in Craft 4 (it is currently on version 3.5, the release of version 4 is planned for April 2021). They had also arranged for an external agency to provide them with accessibility issues to tackle weekly. In the end, they decided instead to hire an in-house accessibility specialist to perform assessments and assist the development team in adopting accessibility patterns in the long run.

W3C CMS Selection Report

Last week we published a post urging W3C to revisit Gutenberg for a fair shake against the proprietary CMS’s or consider adopting another open source option. During the selection process, Studio 24, the agency contracted for the redesign, cited its extensive experience with WordPress as the reason for not performing any accessibility testing on more recent versions of Gutenberg.

When asked if the team contacted anyone from WordPress’ Accessibility Team during the process or put Gutenberg through the same tests as the proprietary CMS’s, Studio 24 founder Simon Jones confirmed they had not.

“No, we only reached out to the two shortlisted CMS’s” Jones said. “I’m afraid we didn’t have time to do more. We did test GB a few months ago based on editing content – though it wasn’t the only factor in our choice. As an agency we do plan to keep reviewing GB in the future.”

In response to our concerns regarding licensing, Jones penned an update titled “On not choosing WordPress,” which further elaborated on the reasons why the agency was not inclined towards using or evaluating the new editor:

From a business perspective I also believe Gutenberg creates a complexity issue that makes it challenging for use by many agencies who create custom websites for clients; where we have a need to create lots of bespoke blocks and page elements for individual client projects.

The use of React complicates front-end build. We have very talented front-end developers, however, they are not React experts – nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.

As of yet, we have not found a satisfactory (and profitable) way to build custom Gutenberg blocks for commercial projects. 

The CMS selection report also stated that W3C needs the CMS to be “usable by non-sighted users” by the launch date, since some members of the staff who contribute to the website are non-sighted.

Since the most recent version of WordPress was not tested in comparison with the proprietary CMS’s, it’s unclear how much better they handle accessibility. Ultimately, W3C and Studio 24 were more comfortable moving forward with a proprietary vendor that was able to make certain assurances about the future accessibility of its authoring tool, despite having a smaller pool of contributors.

“[I’m] also deeply curious since the cursory notes on accessibility for both of the reviewed CMSes seem to highlight a ton of issues like ‘Buttons and Checkboxes are built using div elements’ or most inputs lacking clear focus styles,” Gutenberg technical lead Matías Ventura said. “An element like the Calendar for choosing a post date seems entirely inoperable with keyboard on Craft, for example, while WordPress’ has had significant effort and rounds of feedback poured into that element alone to make it fully operable.”

WordPress developer Anthony Burchell commented on how using a relatively new proprietary CMS seemed counter to W3C’s stated goal to select an option on the basis of longevity. Craft CMS’s continued success is contingent upon its business model and the company’s ability to remain profitable.

“FOSS have the same opportunity of direct access to developers,” Burchell said. “I recognize there are many accessibility shortcomings in popular software, but I think it’s more constructive to rally behind and contribute, not use a proprietary CMS that boasts beer budget in their guidelines.”

On the other side of the issue, accessibility advocates took the W3C’s decision as a referendum on Gutenberg’s continued struggles to meet WCAG AA standards. WordPress accessibility specialist Amanda Rush said it was “nice to see the W3C flip tables over this.”

“Gutenberg is not mature software,” accessibility consultant and WordPress contributor Joe Dolson said in a post elaborating on his comments at WPCampus 2020 Online. He emphasized the lack of stability in the project that Studio 24 alluded to when documenting the reasons against using WordPress.

“It is still undergoing rapid changes, and has grand goals to add a full-site editing experience for WordPress that almost guarantees that it will continue to undergo rapid changes for the next few years,” Dolson said. “Why would any organization that is investing a large amount into a site that they presumably hope will last another 10 years want to invest in something this uncertain?”

Dolson also said the accessibility improvements he referenced regarding the audit were only a small part of the whole picture.

“They only encompass issues that existed in the spring of 2019,” he said. “Since then, many features have been added and changed, and those features both resolve issues and have created new ones. The accessibility team is constantly playing catch up to try and provide enough support to improve Gutenberg. And even now, while it is more or less accessible, there are critical features that are not yet implemented. There are entirely new interface patterns introduced on a regular basis that break prior accessibility expectations.”

WordPress is also being used by millions of people who are constantly reporting issues to fuel the software’s continued refinement, which increases the backlog of issues. Unfortunately, Studio 24 did not properly evaluate Gutenberg against the proprietary CMS’s in order to determine if these software projects are in any better shape.

Instead, they decided that Craft CMS’s community was more receptive to collaborating on issues without reaching out to WordPress. Given the W3C’s stated preference for open source software, WordPress, as the only CMS under consideration with an OSD-compliant license, should have received the same accessibility evaluation.

“I can’t make any statements that would be meaningful about the other content management systems under consideration; but if WordPress wants to be taken seriously in environments where accessibility is a legal, ethical, and mission imperative, there’s still a lot of work to be done,” Dolson said.

Studio 24’s evaluation may not have been equitable to the only open source CMS under consideration, but the situation serves to highlight a unique quandary: when using open source software becomes the impractical choice for organizations requiring a high level of accessibility in their authoring tools.

“Studio 24 ultimately determined that working with a CMS to make it better was more possible with a smaller, proprietary vendor than with a large open-source project,” accessibility advocate Brian DeConinck said. “Project leadership would be more receptive, and the smaller community means changes can be made more quickly. That should prompt a lot of soul-searching for…well, everyone. What does that say about the future of open source?”


19 responses to “W3C Selects Craft CMS for Redesign Project”

  1. “Studio 24 ultimately determined that working with a CMS to make it better was more possible with a smaller, proprietary vendor than with a large open-source project,” accessibility advocate Brian DeConinck said. “Project leadership would be more receptive, and the smaller community means changes can be made more quickly.

    That sums the experience of many dealing with the Trac, where bugs and proposals are wontfixed or are left to rot for years and years because they don’t align with core devs values.

  2. I think it’s the best time to ask everyone involved with Gutenberg to rethink their strategy on who their target group[s] is/are.

    We need two s-e-p-a-r-a-t-e groups for Gutenberg – one is the devs/coders/geeks/designers, those who built the site and the bloggers/journalists/news editors/ writers/creators – those who constantly use the platform to publish and write content, not “building” designs and layouts.

    I can’t teach a professional journalist to “build” their content as they are used to text editors from 40 years.

    This comment form doesn’t use blocks, it is using normal text editing UI and UX which we are used to from dozens of years.

    Gutenberg is leading WP to an ultimate fail and it is time for change within the Gutenberg projects. Blocks – yes, current stage of the geeky unicorn writer that can code, write, design all at once is nowhere to be found.

  3. As an agency owner I can understand why they wound to want to go any where near gutenberg. The constant changes draw much comment from our clients and we are frequently deposing comments like “it’s a lot harder than it used to be”, “I hear WordPress has become herder to use” and “I used to know how to work with WordPress”. That comment is never reaching the community as the clients speak to us not on GitHub, wp tavern, WordPress.org. We’re not passing that feedback on anymore as it fell on deaf ears the first time so what’s the point? The old editor might have been a mess when you tried anything complicated but the concept of what it did was simple. Gutenberg has failed in this regard for many of the hundreds of clients we’ve trained. People don’t think in blocks of content, only developers do that. Regular users just get lost. I think Studio24’s decision is entirely justified and not at all surprising.

  4. I made comments on twitter.

    But my advice to the WP community is simple.
    1. Stay the course.
    2. Keep an eye on the W3C and the project. It is easy to talk the talk but not so easy to walk the walk. W3C has a history of failed projects and unanticipated forks in the road. Frequently take stock on how it’s going for them. And when the inevitable problems and delays come up – and they will – start to pile on the pressure.

  5. Thanks for your coverage of the W3C redesign project Sarah, it’s nice to see our progress being discussed more widely.

    Due to a range of factors, we believe Craft offered a better solution to W3C for this project. It wasn’t just down to accessibility (but that became the most important factor).

    Your article is pretty critical, though you do also provide some balanced viewpoints. On testing WordPress, we have years of experience building sites in WordPress and we started assessing Gutenberg even before its release to see how we could use it in the future. If anything we tested WordPress a lot more.

    At the time of reviewing accessibility (in June) we reviewed the current backlog of issues reported by the community and had real-world users test the editor. This, our experience, and subsequent coverage by people like Joe Dolson, does indicate Gutenberg still has some way to go to be a reliable editing tool for users with accessibility needs.

    I applaud the efforts in the community to improve this and am excited about the WordPress Accessibility Day which is later this week https://wpaccessibilityday.org/

    I want to make clear our decision not to use WordPress on this project is not intended to be a negative comment on WordPress, which I believe is very valuable software and one we use on many client projects, such as recently for UK Parliament https://www.studio24.net/work/parliamentary-digital-service/

    It’s also important to note we are only one type of user of WordPress (a digital agency who builds custom themes and websites for clients). Gutenberg will be the right tool for other users in other contexts. We plan to carry on testing Gutenberg in the future to see if we can find ways to better use it for our work.

    I do think this has highlighted the importance of accessibility in CMS authoring tools, which I hope helps improve the CMS industry for many – not just WordPress. Craft’s investment in accessibility is a great step forward and one that I hope other CMS businesses invest in publicly https://craftcms.com/blog/accessibility

    If anyone wants to keep up to date with the rest of the project please do visit https://w3c.studio24.net/

    • Simon, worth noting WPTavern is owned by Matt Mullenweg. No surprise they are covering this heavily when nobody else really cares. Most in WP outside of Matt’s sphere (grip?) of influence agree with you on the problems pointed out as part of this w3c selection process. Completely valid.

  6. The approach of WP Tavern to this issue seems to me curious, and unlikely to persuade more people to adopt WordPress. To my mind, when someone tells you why they didn’t like your project, that’s valuable feedback.
    Of course, they could be wrong or have made mistakes, but will the official news outlet writing multiple stories in which a major theme is “they did it wrong, they’re wrong” do much to change that? It seems to me it could also back-fire. People might begin to suspect that if you get too near WordPress and find there’s something you don’t like, you’d better beware. You might find that news stories about you start being fed into the dashboards of millions of websites. Best just to stay away completely!

  7. WP should not overlook two other topics pointed out in their requirements:

    “A flexible templating system that allows us to write any HTML we wish, with no or little interference from the CMS”

    This is the exact opposite of what WP/Gutenberg does, and what Craft (using Twig or GraphQL) is built for.


    This is where Craft is best in class, and WP offers exactly zero. (No, those plugins do their best, but cannot compensate without core support)

    Personal note:

    Add WP’s lack of support for complex, cross-referenced data models on top.

    Plus the lack of an underlying MVC framework, making custom developments nerve-wracking and costly.

    So i dont’t think it is only about accessibility.

  8. So they ruled out WordPress due to Gutenberg accessibility issues months ago and wouldn’t revisit it …

    … But they have selected CraftCMS based upon the assumption that version 4 wont have accessibility issues when its released 6months time?

  9. While I highly doubt those leading WordPress down this path will care, I’m just glad to see such a notable rejection caused specifically by Gutenberg, and that the reasons include core concepts of Gutenberg and the rapid development itself, not just the accessibility issues which may, possibly, be fixed (and then possibly reintroduced along with the next changes).

  10. Last week we published a post urging W3C to revisit Gutenberg for a fair shake against the proprietary CMS’s or consider adopting another open source option.

    The burden of convincing should be on WP and the Gutenberg team, not on the agency building the website. Gutenberg was released almost 2 years back and has had all this time to establish its credentials. Purely as a developer I have liked the concept of a block – WP was in need of a standardized way to get around the mess of shortcodes left behind by builders and plugins, and blocks offer a pretty clean solution for that.

    What has always rankled though is the extreme presumption that Gutenberg is what the world of users really desires. To that end the Gutenberg UI has been built with shortcomings that make one think of Balmer Peak (https://xkcd.com/323/).

    This decision should serve as a rude wake-up call for the powers that be. It is OK to be protective of your baby, and your baby indeed might be better than others at reciting the alphabet. But if you are expecting your baby to master calculus in infancy, you need a reality check.

  11. That’s how the process works when you decide hiring an agency. You look for the people you want to work with – here Studio 24 – and then trust their judgement, their level of confidence and follow their recommendation.

    The agency then reviews the magical three whatever tools according to their comfort level. They are the once that need to get the work done.

    It’s easier for them to say “No” to the block-editor of early 2020, and simultaneously trust Craft of April 2021. It’s easier to deal with a smaller team to adjust the CMS than to deal with one that has to make decision for millions of other users and has an ecosystem of themes and plugins.

    We can hope that by April 2021, the new HTMl-block-based templating in Full Site editing will be out of beta. Block patterns, also HTML and block-base are for the content creator to just fill in the blanks of their layouts. They only made it into Core in last version (August 2020), and can use some iteration. Things are in flux with WordPress right now.

    At one point Studio 24 needed to pull the trigger and decide on what they are comfortable making the best site for W3C with their current resources. They are after all a for-profit company and have a budget to adhere, too. I don’t see this decision as a judgement on WordPress as a whole. It’s a decision that WordPress is not the right tool for this project. A decision we make at our agency several times a month, too. Sometimes WordPress isn’t the right tool.

  12. “Things are in flux with WordPress right now.”

    WordPress has been in flux for the duration of the block editor, and not just since it was integrated into core with the release of WordPress 5.0. There were many months leading up to that release, for those following along on Github, where it was difficult to parse exactly where things were heading.

    For years it had been possible to write a well-coded custom theme and set a client up with a website, with confidence it was safe to run core updates without major issues. WordPress was a mature project that generated very little in the way of unexpected maintenance costs, a major selling point for any organisations working on a shoestring budget.

    A simple example of the kind of anxiety that now hangs over every core update: earlier this year, the Button block was replaced in the block inserter panel by a Buttons block. The Button block continued to exist but became a child of the Buttons block.

    The result of this change, for anyone who had opted to manage block availability by using the allowed_block_types filter, was buttons were suddenly no longer available in the editor (existing buttons were still obviously rendered on the front-end). Defining ‘core/button’ against that filter had previously ensured the Button block remained available in the editor, but now it was a dependent of the new Buttons block ‘core/buttons’ also needed to be on the allowlist for allowed_block_types.

    I never expected I’d need to add two definitions to an allowlist to permit a single block. I also can’t read the future, so hadn’t added ‘core/buttons’ to custom themes for sites launched during the previous year.

  13. I have to admit, I’m a little bit confused by this — and the first — post.

    A digital agency that the W3C selected in its RFP process has decided to use another CMS for its project. Why does WP Tavern care so much and why is it trying to undermine that decision?

    I don’t know anything about this agency, but its portfolio is solid and I take it at its word that this is the best solution for this project.

    Moreover, the way Craft is being portrayed isn’t really accurate. No, it isn’t OSS based on the OSD license, but the source code is available. Moreover, Craft has been around for quite some time and its developers have been around even longer — those of us who used ExpressionEngine back in the day used their plugins/extensions. In fact, Craft was created because EE was stagnant and not modernizing with the times.

    Craft is a niche CMS but it could be argued that it serves its target users — agencies like Studio 24 who need to create a custom solution but don’t want to build a custom CMS — better than WordPress for lots of reasons.

    More to the point, Craft is agreeing to work with the agency to improve accessibility (something that will impact all of its users, not just Studio 24) on schedule with the timeline of the project. It would be an unreasonable ask for a project like WordPress.

    So I don’t get it. This is one website and one agency. Why the criticism/investigation?

    Maybe the question posed by the person quoted at the end of the article should be the real focus: why is it easier for an agency to work with a team like Craft or Statamic than it is to work with WordPress?

  14. It’s great to see an agency be so open about their concerns re: Gutenberg – and this will hopefully be a wake up call to the core Gutenberg team that devs are shunning WordPress because of Gutenberg.

    Of particular interest were the comments around how difficult it is to make custom Gutenberg blocks profitably.

    I’ve been working with Gutenberg since its launch nearly 2 years and I dread to think how much time I’ve spent (or rather, wasted) fixing things that updates of Gutenberg have broken.

    This W3C project could and should have been built on WordPress, and it probably would have been if Gutenberg wasn’t so un-developer friendly.

  15. I am an owner of a web design company. I have spent more than 20 years in the web industry. We build dozens of WordPress sites each year. Every single one of them has Gutenberg disabled. The designers hate it. The devs hate it. The clients hate it.

    When we want a block editor we use something like WPBakery which is far easier for designers, devs to work with. Even the clients can wrap their heads around it. It also is less inclined to break when there is an update. The Gutenberg project is not a bad idea in itself but it’s overly complicated and it’s been badly executed since the start.

    Sadly, there is no sign that common sense is going to prevail any time soon, so I guess that we’re stuck with it.

  16. It has been obvious to anybody with experience in software development (me: just 53 years) that Gutenberg was a classic example of Second System Syndrome (https://en.wikipedia.org/wiki/Second-system_effect), doomed to failure, and that WordPress’s betting on it was a huge strategic mistake. You’re now seeing the completely predictable consequences.

    Does anybody here read code? I thought not, or mostly not. Take a look at:


    These files are both in excess of 1 megabyte (1.4 and 1.9) and 35000 lines (39,143 and 57,212) lines of JavaScript with the rare, occasional comment. Does anybody know what this does? Is there a formal specification for what it should do? If not, is there any way to test it for correctness?

    I thought not.

    With the cramming of Gutenberg down the throats of WordPress users, the disdain of WordPress for its customers has become overt and the customers have reacted as customers are wont to do: choosing another vendor more responsive to their needs.

    While the arcane and incompetently implemented architecture of WordPress makes it difficult to migrate to another content management system, after a while people will say “Enough: just export everything as a flat text file and let’s have done with this clown show.”

    This was entirely avoidable, and if the Inner Party at WordPress had read the myriad one- and two-star reviews of Gutenberg before cramming it down, it needn’t have happened. But they didn’t, and it did, and so now is the time to turn our backs upon this, snuff the candle, and walk away. It was fun until they wrecked it. Farewell.


Subscribe Via Email

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

%d bloggers like this: