editoria11y

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

1. It checks automatically, as-you-edit, in CKEditor5 and Gutenberg. 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.
    

Editoria11y is included in the Drupal CMS Accessibility Tools recipe available on install.

Demos

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

• 
  Interactive Demo
   
• 
  Video: authoring interface tour (thanks to Gareth Alexander)
   
• 
  Video: 2.1.x (previous version) authoring interface and site reports
   

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 be fake headings
  • All-bold paragraphs with no punctuation that may need heading tags
  • Suspicious patterns of paragraph prefixes that may need list tags (e.g. *, •, ☑️, 👉, or incrementing numbers/letters)
  • Tables without headers, and overrides for the CKEditor5 table plugin to insert new tables with header rows or columns by default
  • 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 prefer to watch: Installation & Configuration Tips Video.

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 (or the Drupal CMS "Accessibility Tools" recipe) should work decently on most sites, but the following items should be reviewed:

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. 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"), or set the checker to only check regions your editors can modify (e.g., "main, #footer-content"). Please do not skip this step! You will prevent frustration for your editors, and viewing the nodes will populate your reporting dashboard.
3. 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.
4. 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 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

• Nate Millins' Editoria11y SI connector module uses SiteImprove data to highlight broken links inline.
• The Editoria11y library is developed in parallel with the Sa11y accessibility checker, and they have almost identical core test suites. Editoria11y focuses on providing a minimalist GUI and provides additional admin-facing tools like site-wide reporting and dismissal governance; Sa11y provides additional author-facing tools like color checking and readability scoring. There is a Drupal wrapper for Sa11y.
• Decorative Image Widget makes alt text required unless the user checks a box to affirm the image is decorative.

Note that modules that claim they can fix issues automatically based on AI or the like, or provide untested at-runtime theme modifications, are not recommended by many disabled Web users.

Advanced configuration and custom tests

The library configuration guide has details and examples for parameters not exposed in the GUI, including how to write custom tests and how to open tabs and accordions before highlighting hidden alerts. There is also a video guide to the JS events and test system.

The module ReadMe has instructions for modifying these parameters within a Drupal theme or module.

Project Info