James Robertson mentions the importance of a good authoring environment in CMS solutions.

Considering that the primary purpose of a web content management system is to help staff to write and publish content, the editor has to be front-and-foremost when it comes to selecting a product. And yet, many organisations specify little more than “the CMS must provide a web-based WYSIWYG editor”.

I also found Seth Gottlieb’s comments on the subject interesting, particularly:

Recently, a client was having his first look at the WCM system that we were implementing […] To him, the WYSIWYG editor was the CMS.

It’s amazing how many users see things this way purely because even when they really do need the full functionality of the CMS, users still use the editor more than 90% of the time. If you’re developing a CMS, the quality of the editor should be among your most important considerations because it’s what you’ll be judged on.

Coming back to James Robertson, I agree with most of his comments but one of the requirements struck me as a really bad idea:

• Ability to specify what window links appear in, including whether they are displayed in a new window, the size of the window, browser controls, etc. Ideally, this should be point-and-click for authors.

This may seem like a nice feature to have, and most editors provide a simple way to set the target of links, but it actually encourages users to make pages that aren’t accessible. In particular WCAG Priority 2 includes the requirement that:

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]

Granted, it’s exceptionally common1 for this rule to be broken, but including it as a core, default requirement when looking at WYSIWYG editors seems a little off. If the client already has a site that breaks this accessibility guideline then they problem need such a feature, otherwise you should probably be steering them away from it and configuring the editor to help users create accessible content as much as possible.

Other than that, it’s a pretty good list of basic requirements for a WYSIWYG editor. I’ve commented before on some key things to look at when evaluating WYSIWYG editors that comes at it from a slightly more technical side. Combine the two and you have a good system out of the box that can be customized and extended to provide the best possible editing experience for users.

1 – and exceptionally annoying↩