The World Wide Web Consortium ( W3C ), the international standards organization for the web, is redesigning its website and will soon be selecting a new CMS. Although WordPress is already used to manage W3C’s blog and news sections of the website, the organization is open to adopting a new CMS to meet its list of preferences and requirements.
Studio 24, the digital agency selected for the redesign project, narrowed their consideration to three CMS candidates:
Studio 24 was aiming to finalize their recommendations in July but found that none of them complied with the W3C’s authoring tool accessibility guidelines. The CMS’s that were better at compliance with the guidelines were not as well suited to the other project requirements.
In the most recent project update posted to the site, Studio 24 reported they have shortlisted two CMS platforms. Coralie Mercier, Head of Marketing and Communications at W3C, confirmed that these include Statamic and Craft CMS.
WordPress was not submitted to the same review process as the Studio 24 team claims to have extensive experience working with it. In the summary of their concerns, Studio 24 cited Gutenberg, accessibility issues, and the fact that the Classic Editor plugin will stop being officially maintained on December 31st, 2021:
First of all, we have concerns about the longevity of WordPress as we use it . WordPress released a new version of their editor in 2018: Gutenberg. We have already rejected the use of Gutenberg in the context of this project due to accessibility issues.
If we choose to do away with Gutenberg now, we cannot go back to it at a later date. This would amount to starting from scratch with the whole CMS setup and theming.
Gutenberg is the future of WordPress. The WordPress core development team keeps pushing it forward and wants to roll it out to all areas of the content management system (navigation, sidebar, options etc.) as opposed to limiting its use to the main content editor as is currently the case.
This means that if we want to use WordPress long term, we will need to circumvent Gutenberg and keep circumventing it for a long time and in more areas of the CMS as time goes by.
Another major factor in the decision to remove WordPress from consideration was that they found “no elegant solution to content localization and translation.”
Studio 24 also expressed concerns that tools like ACF, Fewbricks, and other plugins might not being maintained for the Classic Editor experience “in the context of a widespread adoption of Gutenberg by users and developers.”
“More generally, we think this push to expand Gutenberg is an indication of WordPress focusing on the requirements of their non-technical user base as opposed to their audience of web developers building custom solutions for their clients.”
It seems that the digital agency W3C selected for the project is less optimistic about the future of Gutenberg and may not have reviewed recent improvements to the overall editing experience since 2018, including those related to accessibility.
Accessibility consultant and WordPress contributor Joe Dolson recently gave an update on Gutenberg accessibility audit at WPCampus 2020 Online. He reported that while there are still challenges remaining, many issues raised in the audit have been addressed across the whole interface and 2/3 of them have been solved. “Overall accessibility of Gutenberg is vastly improved today over what it was at release,” Dolson said.
Unfortunately, Studio 24 didn’t put WordPress through the same content creation and accessibility tests that it used for Statamic and Craft CMS. This may be because they had already planned to use a Classic Editor implementation and didn’t see the necessity of putting Gutenberg through the paces.
These tests involved creating pages with “flexible components” which they referred to as “blocks of layout,” for things like titles, WYSIWYG text input, and videos. It also involved creating a template for news items where all the content input by the user would be displayed (without formatting).
Gutenberg would lend itself well to these uses cases but was not formally tested with the other candidates, due to the team citing their “extensive experience” with WordPress. I would like to see the W3C team revisit Gutenberg for a fair shake against the proprietary CMS’s.
W3C Is Prioritizing Accessibility Over Its Open Source Licensing Preferences
The document outlining the CMS requirements for the project states that “W3C has a strong preference for an open-source license for the CMS platform” as well as “a CMS that is long-lived and easy to maintain.” This preference may be due to the economic benefits of using a stable, widely adopted CMS, or it may be inspired by the undeniable symbiosis between open source and open standards.
“The industry has learned by experience that the only software-related standards to fully achieve [their] goals are those which not only permit but encourage open source implementations. Open source implementations are a quality and honesty check for any open standard that might be implemented in software…”
WordPress is the only one of the three original candidates to be distributed under an OSD-compliant license. (CMS code available on GitHub isn’t the same.)
Using proprietary software to publish the open standards that underpin the web isn’t a good look. While proprietary software makers are certainly capable of implementing open standards, regardless of licensing, there are a myriad of benefits for open standards in the context of open source usage:
“The community of participants working with OSS may promote open debate resulting in an increased recognition of the benefits of various solutions and such debate may accelerate the adoption of solutions that are popular among the OSS participants. These characteristics of OSS support evolution of robust solutions are often a significant boost to the market adoption of open standards, in addition to the customer-driven incentives for interoperability and open standards.”
International Journal of Software Engineering & Applications
Although both Craft CMS and Statamic have their code bases available on GitHub, they share similarly restrictive licensing models. The Craft CMS contributing document states:
Craft isn’t FOSS
Let’s get one thing out of the way: Craft CMS is proprietary software . Everything in this repo, including community-contributed code, is the property of Pixel & Tonic.That comes with some limitations on what you can do with the code:
– You can’t change anything related to licensing, purchasing, edition/feature-targeting, or anything else that could mess with our alcohol budget.
– You can’t publicly maintain a long-term fork of Craft. There is only One True Craft.Statamic’s contributing docs have similar restrictions:
Statamic is not Free Open Source Software. It is proprietary . Everything in this and our other repos on Github — including community-contributed code — is the property of Wilderborn. For that reason there are a few limitations on how you can use the code:
Projects with this kind of restrictive licensing often fail to attract much contribution or adoption, because the freedoms are not clear.
In a GitHub issue requesting Craft CMS go open source, Craft founder and CEO Brandon Kelly said, “Craft isn’t closed source – all the source code is right here on GitHub,” and claims the license is relatively unrestrictive as far as proprietary software goes, that contributing functions in a similar way to FOSS projects. This rationale is not convincing enough for some developers commenting on the thread.
“I am a little hesitant to recommend Craft with a custom open source license,” Frank Anderson said. “Even if this was a MIT+ license that added the license and payment, much like React used to have. I am hesitant because the standard open source licenses have been tested.”
When asked about the licensing concerns of Studio 24 narrowing its candidates to two proprietary software options, Coralie Mercier told me, “we are prioritizing accessibility.” A recent project update also reports that both CMS suppliers W3C is reviewing “have engaged positively with authoring tool accessibility needs and have made progress in this area.”
Even if you have cooperative teams at proprietary CMS’s that are working on accessibility improvements as the result of this high profile client, it cannot compare to the massive community of contributors that OSD-compliant licensing enables.
It’s unfortunate that the state of open source CMS accessibility has forced the organization to narrow its selections to proprietary software options for its first redesign in more than a decade.
Open standards go hand in hand with open source. There is a mutually beneficial connection between the two that has caused the web to flourish. I don’t see using a proprietary CMS as an extension of W3C values, and it’s not clear how much more benefit to accessibility the proprietary options offer in comparison. W3C may be neutral on licensing debates, but in the spirit of openness, I think the organization should adopt an open source CMS, even if it is not WordPress.
I would make the same call. I think there is a large cognitive gap between the folks thrilled by Gutenberg Editor and the folks that can’t use it. I am one of the people that can’t use it, even though I’ve used WordPress for 15 years professionally. The interface does not work well on my machines, it crashes my browser, and I can’t support that as a developer. Not an opinion, I’m literally unable to support that which I can not operate.
They hit my sentiment exactly:
Regardless of if it makes sense (I can see it making sense to be easier to user, even if Gutenberg doesn’t accomplish that), this is why a lot of developers and wp-admins are pissed, it means the time of easy, basic content editing has a deadline. December 31, 2021.