关于W3C重新设计项目不选择WordPress的问题

W3C的重新设计项目对于我们演播室24号来说是一个令人难以置信的令人兴奋的项目，能与一个我们整个职业生涯都很敬仰的组织合作是一种荣幸。但这也是具有挑战性的，因为许多方面都比我们通常所接受的更多的审查。在这个大流行的时期，随着焦虑和挑战的增加，在我们都生活的这个“新常态”中有效地工作，这也变得更加困难。

我们很高兴能迎接这一挑战。昨天，WordPress Tavern发表了一篇写得很好的关于W3C的文章，将WordPress从考虑范围中剔除，我想对此做出回应。

到目前为止，我们已经处理了大量的工作，从初始发现、用户研究、信息架构、内容设计到帮助推动项目向前发展的用户体验设计。

CMS平台的决定只是这一点的一部分，对于最终来说，网站是不太显眼的方面之一。正如你可以从Marie关于我们选择CMS的工作的报告中看到的，你可以看到我们帮助入围和选择CMS所经历的步骤。

对于我们和W3C的要求来说，交付可访问的、满足用户需求的HTML/CSS页面是这个项目最重要的部分，也是我们集中时间的地方。总而言之，我们在CMS平台选择上花了大约15天的时间。足以帮助评估有限数量的选项，但不足以对广泛的CMS中的可访问性状态进行彻底审查。

在我们最初的CMS审查之后，我们对CMS平台中突然出现的可访问性问题感到惊讶。由于W3C的原则和价值，这促使我们将可访问性置于其他需求之上。

Studio24是开源软件的坚定支持者，我们在客户工作中广泛使用WordPress。对于这个项目，我们承诺在我们有机会更好地了解客户需求之前，不会选择CMS。

WordPress的一个重要考虑因素是新古腾堡编辑的易访问性问题。许多人写了关于该项目存在的可访问性问题，以及在古腾堡改善可访问性的积极步骤。

古腾堡是一项令人兴奋且非常有趣的发展。许多CMS供应商都在寻找允许编辑器从组件或块创建更灵活内容的方法。然而，在如何使创新的用户界面变得可访问方面，这带来了巨大的挑战。WordPress决定使用JavaScript框架Reaction来满足这些需求。

在Gutenberg在WordPress 5发布前六个月，我们对它进行了测试。最近，我们为剑桥大学做了一个项目，为他们的校友杂志创建一个网站。这项服务于2020年4月推出，使用古腾堡来管理内容。这让我们很好地了解了古腾堡是如何工作的。在6月份，我们回顾了当前的易访问性问题积压(问题，一个11y项目)，并从有易访问性需求的用户那里得到了一些反馈，他们在使用当前用户界面时有困难。这是我们决定WordPress不适合这个项目的原因之一。

考虑到WordPress项目对Gutenberg作为WordPress未来的重要性，我们认为如果将来很有可能不支持经典编辑器，那么推荐使用Classic Editor是不合理的。目前，Classic Editor计划于2021年12月停产。

我们期待古腾堡的继续发展，并赞扬为使其更容易进入所做的努力。我们感谢自审查以来所做的改进，我们很高兴看到10月2日的WordPress无障碍日。

从商业的角度来看，我也认为古腾堡造成了一个复杂的问题，这使得许多为客户创建定制网站的机构使用古腾堡变得具有挑战性；在这些机构中，我们需要为单个客户项目创建大量定制的块和页面元素。

Reaction的使用使前端构建复杂化。我们有非常有才华的前端开发人员，然而，他们不是反应专家-他们也不应该是。我认为前端应该构建为符合标准的HTML/CSS，并在必要和适当的地方使用JavaScript来丰富功能。

到目前为止，我们还没有找到一种令人满意(并且有利可图)的方法来为商业项目构建定制的古腾堡模块。不过，我们不会停止尝试，并计划在未来与古腾堡进行更多的研发。然而，W3C项目感觉并不适合这样做。对于像这个项目这样涉及面很广的项目，开发时间确实成为一个因素。

Drupal也有这个复杂的问题，这使得开发站点变得比需要的更困难，这也是为什么我们也没有考虑该平台的原因。我已经和其他机构谈过，由于Drupal的复杂性，他们已经决定放弃Drupal。

W3C拥抱并支持开放网络。然而，作为一家机构，当涉及到我们用来建立网站的工具时，我们也必须务实。从我们对基于PHP的CMS的回顾来看，Craft和Static都满足了所有的关键要求，而且都是对开发人员非常友好的平台。对于一个我们需要移交给W3C在未来维护的工具来说，这是一个重要的考虑因素。

虽然他们的源代码是公开的，但他们确实有商业许可证，而且需要花钱(尽管金额不大)。收费使小团队能够开发出好的软件，所以我们在意识形态上并不反对这种商业模式。这两个平台在社区中都很受尊重，专业人士也很好地使用了这两个平台，运营着Netflix和Big Commerce in Craft，Spiegel Plus和Statama的FreshBooks等网站。

我们在这个项目的大部分中使用开源技术(HTML/CSS、JavaScript、PHP、symfony)。虽然Craft是一个专有的CMS，但这给了我们直接访问CMS开发团队的优势，这有助于提高这些CMS中的可访问性。我们希望这有助于推动CMS行业的可访问性。

将继续使用开放工具发布网络标准。技术报告页面由Symfony提供支持，规范将继续发布到GitHub，以促进公开讨论。W3C在公开场合的工作方式没有任何变化。

最后一句话。我们目前正在考虑采用无头CMS方案进行前端页面传递。这意味着以一种分离的方式使用CMS来管理内容，但使用单独的系统来交付前端页面。请注意，此解决方案不依赖于JavaScript(例如，单页应用程序，这与Headless很常见)。在这个选项下，我们将使用symfony来交付前端页面，这是W3C已经在网站的很多地方使用的成熟技术。

这可能会为W3C未来提供更好的灵活性，但代价是增加了复杂性。W3C站点已经由许多不同的系统组成，CMS只是构成w3.org上各种内容的一部分。

我希望这有助于更多地解释我们决定背后的思考过程，并解决WordPress Tavern帖子中强调的一些合理问题。