Editoria11y Accessibility Checker

Editoria11y ("editorial accessibility ally") is built around three key needs for ongoing content quality assurance:

1. It checks automatically. Authors do not need be taught to (and remember to!) press a button or visit a dashboard.
    
2. It checks rendered content, allowing it to detect issues that only appear after Drupal assembles the page.
    
3. It focuses exclusively on content issues: inserting alerts and tooltips to assist authors at fixing the things that are their responsibility, without confusing or annoying them with code or theme issues. Editoria11y is meant to supplement, not replace, testing with comprehensive tools and real assistive devices.
    

Demo

Note that these demonstrate what an author would experience; the Editoria11y checker would not appear for anonymous users on a real site.

• Base library interactive demo
   
• Drupal implementation interactive demo including the site-wide reporting dashboard
   
• Video intro from GovCon 2023:
  
  Start at 13m for a quick interface tour
   

The authoring experience

When authenticated users with appropriate roles are viewing pages, Editoria11y's toggle indicates what was found (no issues, some definite issues found, only some manual checks needed):

When the toggle is clicked, alerts are placed on elements with issues, with tooltips that explain the problem and what actions are needed to resolve it. If the item might be a false positive, buttons are available to ignore the alert on this page for the current user or for all users ("Mark as Checked and OK"). By default, these alerts appear automatically the first time new issues are detected:

The main panel allows authors to step through the issues on the page, restore previously dismissed alerts, and visualize text alternatives for images on the page ("alts") and the document's heading outline.

When sync is enabled, all issues detected can be reviewed in the Reports section of the administrative toolbar:

The tests

• Text alternatives
  • Images with no alt text
  • Images with a filename as alt text
  • Images with very long alt text
  • Alt text that contains redundant text like “image of” or “photo of”
  • Images in links with alt text that appears to be describing the image instead of the link destination
  • Embedded visualizations that usually require a text alternative
• Meaningful links
  • Links with no text
  • Links titled with a filename
  • Links only titled with generic text: “click here,” “learn more,” “download,” etc.
  • Links that open in a new window without warning
• Document outline and structure
  • Skipped heading levels
  • Empty headings
  • Very long headings
  • Suspiciously short blockquotes that may actually be headings
  • All-bold paragraphs with no punctuation that may actually be headings
  • Suspicious formatting that should probably be converted to a list (asterisks and incrementing numbers/letters prefixes)
  • Tables without headers and tables with document headers ("Header 3") instead of table headers (<th>)
• General quality assurance
  • LARGE QUANTITIES OF CAPS LOCK TEXT
  • Links to PDFs and other documents, reminding the user to test the download for accessibility or provide an alternate, accessible format
  • Video embeds, reminding the user to add closed captions
  • Audio embeds, reminding the user to provide a transcript
  • Social media embeds, reminding the user to provide alt elements

Installation and configuration

If you are installing from the command line, do note the "eleventy" when spelling the module's name! Those are not L's.

Editoria11y's default configuration should work decently out of the box on most sites, but the following things should be reviewed before telling content authors it is good to go:

1. Review roles and permissions. Users must have the "View Editoria11y Checker" permission to see the checker, and there are separate permissions to enable the "ignore" and "mark OK" buttons, and to review the site-wide reports. The module attempts to enable the first two by default on roles with common node edit permissions; you should add "mark OK" to trusted roles and "view dashboard" as you deem fit.
2. Select a color theme that works well with your site. Light and dark are available in the GUI; custom colors can be injected using JS parameters.
3. On the module configuration page, set the checker to check regions your editors can modify (e.g., "main, #footer-content").
4. Click through key pages and at least one page for each content type on your site, paying special attention to custom views and embeds, to look for theme-level issues or false positives. Fix these issues before rolling the module out, or add selectors to the module configuration's "skip over these elements" list to suppress repeated alerts (e.g., "#sidebar-menu a, .custom-card-view h3"). Please do not skip this step! You will prevent frustration for your editors, and viewing the nodes will populate your reporting dashboard.
5. Tell us how it went! This module and its base library are both under active development. Send thoughts through the issue queue or find itmaybejj on the Drupal Slack

There are many additional configuration options available on the module page for more complicated situations: selectors for shadow components to check, changes to which document filetypes should be flagged, the ability to disable checking if certain selectors are present (code-only pages) or absent (user does not have an edit button on this content type), etc.

The ReadMe also details a method for developers to programmatically modify JS parameters at runtime, which can be used to inject custom defaults on multi-site installs, handle long skip-element lists without cluttering the GUI, modify the color scheme or even rewrite tooltip messages.

Also note that the library dispatches JavaScript events at key moments (scan finishes, panel opens, tooltip opens or shuts...), allowing developers to attach custom functionality. JavaScript on sites running Editoria11y can watch for these events to automatically open accordion widgets if they contain hidden alerts, to disable "sticky" site menus when the panel opens, or even to sync the count and type of alerts found to third-party analytics platforms.

See also

• Editoria11y began as a fork of Adam Chaboryk's spectacular Sa11y accessibility checker library, and we continue to pass new tests and optimizations back and forth.
• Decorative Image Widget makes alt text required unless the user checks a box to affirm the image is decorative.
• CKEditor Accessibility Auditor adds a button to run a manual check inside the node edit form, rather than post-render. Some editors like to run a check before advancing to the node preview page, where Editoria11y runs automatically.

Note that modules that claim to fix any issues automatically, rather than support the editor in creating accessible content in the first place, are not recommended.

For developers and themers

The library configuration notes has details and examples for parameters not exposed in the GUI, as well as tips for using JavaScript events to modify your page when items are highlighted.

The module instantiates the library, so setting custom options in a Drupal theme or module requires first telling the module to check for custom options by setting an "editoria11yOptionsOverride" global to true, and then providing the module with an "editoria11yOptions" function modify the options object. Works like this:

var editoria11yOptionsOverride = true;
var editoria11yOptions = function (moduleOptions) {
  let newOptions = moduleOptions;
  newOptions['baseFontSize'] = 16;
  return newOptions;
}

Project Info