Posts Tagged ‘accessibility’

In Search of a Better Content Editor

Friday, November 25th, 2011

Is our reliance on CMS‘s like WordPress holding back the Semantic Web and undercutting our clients’ content?

My company uses WordPress for a lot of client projects. For us, it has many positives: It’s free, flexible, and easy to modify. Its huge library of plugins makes it great for quick-turn projects. Perhaps most importantly, its WYSIWYG editor makes it easy for clients and nontechnical staff to enter and edit content, without the involvement of web developers.

But recently, I’ve been wondering if that last positive isn’t quite so positive after all. While the WYSIWYG editor takes a great deal of effort off the shoulders of the designer/developer, what cost are we enduring by losing so much of the power and flexibility of HTML itself?

Much of the brilliance and power of HTML comes from markup that is difficult or entirely unavailable in today’s WYSIWYG editors. Elements like <abbr>, <time>, and <cite> are very important semantic tools that add meaning and accessibility to our content, but are unavailable without moving into the HTML editor. Microformats like hCard and hCalendar are unsupported. Even something as simple as proper use of rel attributes is difficult within the default editor.

How important is all of this? Do we consider semantics and machine-readability to be acceptable casualties for the ease we get by using a CMS? I don’t think so. With the increasing use of HTML5 and the emerging “app” mentality of web development (not to mention the old pillars of searchability, findability, and SEO), semantics and machine-parsing are more important than ever.

I can guarantee that CMS‘s and blogging platforms aren’t going away, and I wouldn’t want them to. There’s no question that the benefits outweigh the drawbacks for most web projects. Development time is always important, and as the web gets more social and conversational it will become increasingly important for writers and content managers to quickly and easily edit content without going through a lengthy content workflow.

So where does that leave us?

Perhaps the answer is simply to better educate the content managers on semantic HTML tags and proper use of the HTML editor. That would certainly be a great start. But in reality, it may be impractical to expect every writer and editor to be able to write properly formatted semantic HTML with microformats. It’s challenging to get web developers to do it right sometimes.

Maybe we need to insist that developers enter all content. From a workflow standpoint, this is hardly ideal, as developers add yet another (often expensive) step to the process, slowing down content deployment and eliminating one of they key reasons for using a platform like WordPress in the first place. Additionally, most developers I know don’t exactly jump at the idea of doing content entry.

Maybe the answer is a smarter WYSIWYG editor. TinyMCE (WordPress’s default editor) has dozens of configuration options. Maybe there are some additional elements buried in there somewhere. There are other editors out there, as well. Perhaps one of them has better support for semantic elements and microformats. Over the next few weeks, I intend to find out.

I don’t know the right answer, but I think the question deserves more thought than it’s currently being given.