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.
WYSIWYG JavaScript editors
If your memory is as long as mine you will recall when WYSIWYG javascript editors first appeared back in the days when we spoke excitedly of DHTML (D = Dynamic = scripted). Designed for use in web programs such as Content Management Systems (CMSs, eg Drupal) these editors replace a basic HTML <textarea> with a rich editing experience somewhat similar to using a word processor, including toolbars. They hide the complexities of creating markup by automatically inserting tags into generated HTML which is then persisted in the CMS and displayed as part of viewed webpages.
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.
Accessibility woes
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.
CKEditor Accessibility Checker screen shot
As can be seen, a dialog popup provides the user interface with button for Next and Prev error, an explanation of the issue which is also highlighted in the content. A triangle on one edge of the dialog also acts as a pointer to the problem. All-in-all this is a good interactive experience for navigating and fixing issues. In addition, if the editor content is clicked to make a change the dialog shrinks down out of the way – a nice touch. Quick fixes are provided as extra javascript snippets in the sample code and make for an easy user experience. A complication here is that authors using CKEditor are intentionally insulated from the raw markup details so errors have to make sense with minimal reference to techy details and standards. I think a reasonable job has been done though some understanding of the underlying markup is required.
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>CKEditor with a11yChecker</title> <meta name="description" content="CKEditor with a11yChecker "> <meta name="author" content="Steve Lee"> <script src="js/ckeditor/ckeditor.js"></script> <script src="js/jquery.min.js"></script> </head> <body> <main> <form> <textarea name="editor1" id="editor1" rows="10" cols="80"> <h2>H2 Heading</h2> <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> </textarea> <script> CKEDITOR.replace( 'editor1', {extraPlugins: 'a11ychecker'} ); </script> </form> </main> </body> </html> |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
var Hapi = require('hapi'); // Create a server with a host and port var server = new Hapi.Server(); server.connection({ host: 'localhost', port: 3000 }); // Add a route for a simple static file server server.route({ method: 'GET', path: '/{param*}', handler: { directory: { path: 'public', index: true } } }); server.start(); |
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.
Final Thoughts
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.
Thanks for this info. Looking forward to trying it out. But it will be interesting to see how complicated the results that get generated by the checker are and whether “unsophisticated” content creators will quickly abandon the checker because it is too complicated. I suspect there will still need to be a fair amount of training involved for content creators to help them to understand how all this works.
I suspect you are correct. While some warnings will always be complex others might well be explained in easier terms, plus links to training materials could be included. AS it is the checker appears to simply show the Quail messages which are targetd at developers so there is work to do.