No matter how thoroughly a website is checked for accessibility by its creators, content editors play an important role in keeping it that way. Two little tools assist editors in their work, alerting them if content added through the CMS breaks certain accessibility principles. As a key building block in an inclusive publishing strategy, I look at the options and provide a turnkey solution for Kirby.
tl;drSa11y and Editoria11y are handy tools for editors to quickly verify their content’s accessibility. My kirby3-a11yprompter is a wrapper plugin to comfortably embed them into Kirby 3 sites.
It’s a well-established fact that automated testing is not enough to ensure a website’s accessibility (aka. a11y): see Manuel Matuzović’s completely inaccessible demo reaching a 100% Lighthouse score or the gov.uk team’s experiences catching just 30% of issues proving that point.
Yet, once a design and implementation have been thoroughly tested, automated helpers can assist editors by highlighting accessibility-critical issues from their edits. Or, as the authors of the Sa11y tool put it:
Sa11y is an accessibility quality assurance tool that visually highlights common accessibility and usability issues. Geared towards content authors, Sa11y straightforwardly identifies errors or warnings at the source with a simple tooltip on how to fix them.
Using such QA tool makes it easier to maintain technical accessibility without having to do a full audit or ask an expert after every edit.
The makers of Editoria11y – a fork of Sa11y with a slightly different focus – even call it “auto-correct” for accessibility. While it’s maybe not quite that, I see great value in these “assistants”, as they alert editors whenever they might break the accessibility of an otherwise well-built website (in more and more parts of the world, this even is a compliance requirement to avoid legal backlash).
What these tools do …and what not
To start with the latter part of the question: neither Sa11y nor Editoria11y are full-grown accessibility testing suites. They can not be used to ensure overall compliance with accessibility principles of a website (which, as stated above, is anyways impossible to do without manual review).
Instead, these nifty tools provide a helper icon (in the bottom right corner of the browser window; like good ol’ Clippy, but less annoying) that displays warnings and alerts whenever its built-in tests discover an issue. They can detect a range of mistakes related to HTML markup, text styling, colour contrast, etc. and provide a quick summary view to validate the content hierarchy of headlines.
Sa11y or Editoria11y, which one to pick?
Both Sa11y and Editoria11y can be traced back to Khan Academy’s “original” Tota11y, which laid the foundation for an in-browser a11y testing tool. As described in their announcement from 2015, it was however more directed at developers, not editors. It also appears to be no longer actively developed. On a side note, and unrelated to the tools discussed here, a11y.css deserves to be mentioned as well, as yet another tool based on the same principle.
While Sa11y, developed at Ryerson University, appears to have slightly more features in terms of what is being checked, e.g. a Readability score, and provides means to create custom rule sets, Editoria11y is developed at Princeton University (where it has been deployed to assist the content editors of over 400 websites) with an even stronger focus on end-user guidance. The fork’s exact difference from Sa11y is not documented, but their blog post with the extensive introduction of the tool and its rationale gives some hints:
We took its test architecture and user-friendly information-panel-with-tooltips approach, and spent half a year adapting the tool so that tests always ran automatically, optimizing its performance, tweaking the tooltips and creating a long list of configuration options a developer could use to quickly adapt it to any platform.
The UIs differ slightly regarding the level of guidance provided, while the help texts within Editoria11y are linked closely to Princeton’s editorial guidlines (not a problem at all, and these can also be overwritten, if desired). Both tools appear to be available chiefly in English (translations likely would have to come from the community), and at least Sa11y clearly states to be able to deal with websites in English, French and Spanish (this might be related to the Readability feature, though, as most of the checks should be language-independent); possible usability glitches on websites in, for example, German language would have to be examined.
It is extremely difficult to pick a favourite between these two. It really depends on the use case, on personal preferences, on the knowledge and technical skill level of the editors and other factors – potentially even on how well each solution plays with a particular website design. It is probably worth testing them both and maybe collecting feedback from the editors. If you gain empirical insight from testing this with non-techy people, it would be great to read from you in the comments below!
How to use them?
Ideally, the tools would be configured to only check the areas of a website that can be affected by an editor. There is no value in constantly alerting users to issues they can’t do anything about. Both tools provide ample configuration options to tailor the experience and either ignore certain areas or silence known errors, for instance.
Their use should best be paired with training the editorial staff, as it is a lot easier to interpret messages like “Alternative text missing” or “Incomplete headline structure” when users have a baseline understanding of accessibility concepts. Depending on the CMS used, it might be a slightly unusual workflow to use the frontend rendering to check such things; neither Sa11y nor Editoria11y are designed to work inside WYSIWYG editors.
From the developer’s perspective, setup is very straightforward: less than a handful of files have to be included in the HTML markup, along with possible settings variables. Thereafter, the tools are displayed whenever a page is opened. This code should be made conditional, so that it is only shown to logged-in users, not to the public-facing version of the website. Of the two tools, Editoria11y is even available as a turnkey module for Drupal CMS (and Wordpress announced as upcoming).
The A11yprompter plugin for Kirby CMS
While embedding Sa11y or Editoria11y is easy, nothing beats plug-n-play. I created A11yprompter (a11y as in accessibility, and prompter like the person assisting actors on stage), a plugin for Kirby 3, that facilitates just that: after installation and adding a short code snippet to the HTML footer template, logged-in users will see the tools instantly.
Kirby wrapper for automatic content accessibility checkers Editoria11y and Sa11y.
Since choosing between the two requires some evaluation, the plugin switches between Sa11y and Editoria11y randomly, until locked-in by means of configuration (see Readme for details; when configured explicitly, Tota11y is available for reference as well). In addition to accepting configuration variables for the test tools themselves, the plugin also permits limiting its appearance to certain user roles and/or page templates. Ideally, this would be configured narrowly to only provide assistance to the parts affected by editors’ work.
Ultimately, the kirby3-a11yprompter plugin is nothing more than a wrapper for these two libraries. No matter do you use Kirby or any other CMS, I highly recommend checking out these handy additions to promote website accessibility to editorial teams. And of course they are equally valuable for developers’ day-to-day maintenance work as well.
