Two years ago we introduced the Editoria11y accessibility checker as a turnkey site plugin for Drupal that would offer authors automatic instant feedback, with helpful tips for improving their content.
We thought this would meet an unmet need. Existing options all required training and diligent use to be useful, and experience had showed us that trying to train and monitor thousands of content authors over a large organization was not an efficient way to tackle the problem. For a program to succeed, we were confident it needed to have a high level of automation, providing polite “just in time training” to content authors when it detected common mistakes.
It worked.
At Princeton, it largely reversed the direction of my communications. On platforms with it installed, we went from sending repetitive emails to content authors requesting alt text, link or heading improvements, to receiving questions from content authors about how to improve their writing to avoid it getting flagged so much.
Externally, the reaction was elation:
Introducing v2
We took a “tease and link” approach with the v1 tips: a short explanation of the issue, and a link for more details.
This was an improvement on tools written for developers: the tips were short and clear. But the decision of where to link was always an issue. Several government and higher education users felt the need to modify the tips to remove links to Princeton’s documentation, which made for extra work for them. So we rewrote the default tips to self-contained, with inline examples.
The distinction between red alerts (definite issues) and yellow warnings (possible issues) proved confusing, and at times annoying.
So we converted yellow warnings to “manual checks” to clarify their meaning, and added buttons to let authors dismiss alerts. “Ignored” alerts are only hidden for the person who clicks it; “marked OK” alerts are hidden for all site editors. Site administrators can choose who has permission to do each.
Creating a dashboard
A common lament by site owners was that the tool was doing a great job of finding issues all over the site, but there was no way to view a site-wide report.
The rewrite adds an option to sync findings back to a site’s database. Site owners can now browse findings by page or issue, and review which issues have been ignored or marked as ok – and restore the issue if they disagree!
Under the hood
V2 was nearly a full rewrite. Some of the new features include:
- Removing the jQuery dependency lets it be installed on more platforms, and provides a 2x performance improvement.
- The checker can now be configured to look within multiple independent parts of the page (e.g., article contents and the page footer).
- The checker can now test elements inside the shadow DOM, which is used by various Web components and JavaScript libraries.
- Many new parameters make platform integrations easier, such as auto-ignoring all issues on certain pages for certain users, if they are not responsible for content on that page but may still want to view results on demand.
- The checker now ships with multiple base themes, and parameters for customizing colors.
- Automated testing helps prevent code regressions.
New and updated integrations
- Drupal module
- WordPress plugin
- Instructions for integrating library with SquareSpace
Next steps
As with the year after v1 was released, now it is time to sit back and let authors test and provide feedback. Please do explore the checker library demo or the Drupal integration demo, and send in any bug reports and feature requests.