Here’s a mini review after a quick play with a preview of the new CKEditor Accessibility Checker plugin for content creators. The plugin is provided by CKSource who lead the development of the open source CKEditor and provide additional commercial grade services.
Two early editors emerged as leaders, at least when I last looked over 5 years ago; CKEditor and TinyMCE. Both are still going strong and now have many solid features. While these editors provide a familiar experience when creating rich content, there was a problem. Accessibility. Or rather there were 2 accessibility problems.
Firstly, the toolbars were initially implemented as bit images and provided no keyboard access. I’m pleased to say that has now been fixed and in CKEditor for example you hit Alt+F10 to get focus into the toolbars. There are other accessibility features including keyboard shortcuts and even an Accessibility Help screen accessed via Alt+0
The 2nd accessibility issues is harder to solve. It’s the accessibility of the content created by authors using the editor. While the CMS developers like Drupal may make every effort to ensure the end user experience is fully accessible, they cannot fully control user generated content. As the editor manages which tags are added it can ensure a certain level of accessibility including WAI ARIA but authors can still make common accessibility errors, For example it’s easy to create a bad structure by skipping heading levels. Or the perennial chestnut forgetting to add an alt attribute to important pictures.
CKEditor Accessibility Checker
One solution to the problem of catching author errors is to provide a tool that authors can use to check their content before they submit it. This is the approach taken in the CKEditor Accessibility Checker plugin. While there are several HTML validation tools and services that could be used the quail checker
To try the Accessibility Checker I first played with the comprehensive sample and then knocked up a little test. The sample provide some Wikipedia style content with 7 errors flagged by the Quail accessibility checker used for validating the markup.
In order to get an experience of the effort involved in using the Editor and Accessibility Checker I created a simple webpage with some dodgey initial content for the editor. This shows how painless it is. In addition to the CKEditor initialisation and textarea element replacement code, it is only required to include jQuery and declare use of the Accessibility Checker plug in.
<title>CKEditor with a11yChecker</title>
<meta name="description" content="CKEditor with a11yChecker ">
<meta name="author" content="Steve Lee">
<textarea name="editor1" id="editor1" rows="10" cols="80">
<h4>H4 naughty as skipped h3</h4>
<p>No alt attribute on this <img src='img/noalt.jpg' /></p>
<table><tr><td>whoops no th</td></tr></table>
<p><span style="background-color:darkgray; color:gray">Can you read this?</span></p>
Note that the checker makes an XHR call to Quail so the sample had to run from a server, not file:///. An easy way to do that is with nodejs and hapi configured as a simple static server. I also used the new Visual Studio code editor to edit and run it. All in all that’s a nice easy and portable way to get a nodejs server up and running
var Hapi = require('hapi');
// Create a server with a host and port
var server = new Hapi.Server();
// Add a route for a simple static file server
While the first three accessibility errors in my dodgy markup were found the contrast fail was not, even though this is listed in the Quail documentation. I checked with TPG’s WAT to ensure it was indeed a WCAG AA and AAA fail. I tried adding it as a new CKeditor style but that made no difference. Perhaps Quail does not map the colour names to values? I assume it works with inline styles. I didn’t spend anymore time investigating this.
Some errors are no doubt hard to find as the editor contents are one part in a larger page context. If the wider page context is ignored then some structural errors will not be found. The edit page context is likely to be different to the view one. Also, if the same content is used in several page contexts the structural integrity may vary.
The Accessibility Checker plugin is a good solution for ensuring user supplied content is accessible or otherwise checking in browser edited markup. The UX is good, though I did not check the accessibility of the UX itself. Quail is a good open source accessibility validator, is configurable and supports test for both WCAG and Section 508. The Accessibility Checker documentation claims it can be used with others checkers so perhaps it would work with Tenon.io, though that requires a subscription. The Quick fix feature make it even easier for authors to use
Currently Accessibility Checker is a commercial offering from CKSource but they said they plan to make it open source under GPL, like CKEditor itself. I see there is a Drupal plugin for using CKEditor so no doubt the Accessibility checker could be added as well, making Drupal even more accessible.