Module Description
Editoria11y ("editorial accessibility ally") is built around three key needs for ongoing content quality assurance:
* It checks automatically. Authors do not need be taught to (and remember to!) press a button or visit a dashboard.
* It checks rendered content, allowing it to detect issues that only appear after Drupal assembles the page.
* 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.
Version 2 is ready for use! Check out a demo simulating the authoring experience.
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:
Demo
Note that these demonstrate what an author would experience; the Editoria11y checker would not appear for anonymous users on a real site.
* Drupal v2 module demo
* Base library demo
* Drupal v1 video tour:
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:
* 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.
* 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.
* On the module configuration page, set the checker to check regions your editors can modify (e.g., "main, #footer-content").
* 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.
* 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.
Project meta Developer Info * Merge Requests/Issue Forks are preferred over traditional Drupal issue as we are using GitLabCI.
* It checks automatically. Authors do not need be taught to (and remember to!) press a button or visit a dashboard.
* It checks rendered content, allowing it to detect issues that only appear after Drupal assembles the page.
* 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.
Version 2 is ready for use! Check out a demo simulating the authoring experience.
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:
Demo
Note that these demonstrate what an author would experience; the Editoria11y checker would not appear for anonymous users on a real site.
* Drupal v2 module demo
* Base library demo
* Drupal v1 video tour:
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:
* 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.
* 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.
* On the module configuration page, set the checker to check regions your editors can modify (e.g., "main, #footer-content").
* 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.
* 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.
Project meta Developer Info * Merge Requests/Issue Forks are preferred over traditional Drupal issue as we are using GitLabCI.
Module Link
Project Usage
3279
Security Covered
Covered By Security Advisory
Version Available
Production
Module Summary
Editoria11y is a module that focuses on ongoing content quality assurance by automatically checking rendered content for accessibility issues and providing alerts and tooltips to assist authors in fixing them.
Data Name
editoria11y
OPENAI CHATBOT
OPENAI CHATBOT
