About

Keep it simple.

Editoria11y (editorial ally) is a user-friendly accessibility “spellcheck” that addresses three critical needs for content authors:

  1. It shows results inline. Content authors do not need to be trained or remember to click a button, visit a dashboard or wait for a crawl. Tips and alerts automatically appear when relevant.
  2. It focuses exclusively on straightforward issues a content author can easily understand and easily fix. Comprehensive testing with other tools and techniques is a critical part of making a site accessible, but many of the results are not the content author’s responsibility.
  3. It highlights in context. Modern content management systems assemble pages from many separately-edited blocks, widgets and elements. Only a fully-assembled “page” can be checked for things like the heading outline order.

Editoria11y does not modify your content. It is not an overlay; it is an author-facing tool that helps authors make content accessible from the start.

Try a clickable demo of what a logged-in author would experience.

The authoring experience:

Alert toggles are placed on on previewed and published pages. They can be clicked or hovered to show details and tips:

Tooltip reads "Heading tag without any text" and is followed by an explanation that headings provide a navigable table of contents for assistive devices, with an example of a good heading structure.
three toggles, a checkmark, a red outlined 4, and a 1 on a solid yellow circle
An issue count is placed on a toggle at the lower-right corner of the page.
Screenshot of panel showing 3 issues detected
Clicking the toggle opens a control panel, with buttons to step through alerts, visualize the page outline and review image alts.

Carefully chosen tests

Marked with (m) are “manual checks,” which are placed on content that may be OK as-is, depending on context. Authors are able to hide or dismiss manual checks. Definite problems, such as links with no text, can only be hidden by the site administrators.

  • Page structure that is meaningful for screen readers and search engines
    • Headings with no text at all
    • Tables without header cell
    • Tables with empty header cells
    • Document headers (“Header 3”) inside table cells
    • Skipped heading levels (m)
    • Very long headings that might not be actual headings (m)
  • Text alternatives for images and media
    • Images without an alt element
    • Images marked as decorative using an empty alt element (m)
    • Images with a filename as alt text (m)
    • Images with very long alt text (m)
    • Alt text containing redundant text (m)
    • Video embeds, reminding the user to add closed captions (m)
    • Audio embeds, reminding the user to provide a transcript (m)
    • Social media embeds, reminding the user to provide alt elements (m)
    • Embedded visualizations that usually require a text alternative (m)
  • Links that meaningfully describe where they go
    • Links with no text
    • Links with a filename as their label (m)
    • Links made of only generic words: “click here,” “learn more,” “download,” etc. (m)
    • Links that open in a new window without warning (m)
    • Images in links with alt text that appears to be describing the image instead of the link destination (m)
    • Links to PDFs and documents, reminding the user to test the document for accessibility or provide an alternate format (m)
  • Visual-only formatting
    • Lists made from asterisks, numbers and letters rather than list elements (m)
    • LARGE QUANTITIES OF CAPS LOCK TEXT (m)
    • Possible heading: suspiciously short blockquotes (m)
    • Possible heading: short, all-bold paragraphs (m)

Editoria11y does not flag design issues (color contrast) or development issues (invalid ARIA). It is meant to work alongside, not replace, tools designed for designers and developers.

Install & configure

If possible, use a turnkey integration:

The Drupal and WordPress integrations add additional server-side features, such as synchronized issue dismissals, site-wide issue dashboards, role-based permissions, and admin-facing configuration pages.

Once you have installed the checker, be sure to explore your site. There are quite a few configuration options available, chiefly to prevent throwing alerts on page elements or content that appear on every page and/or cannot be fixed by content authors.

To build a custom implementation, create a local copy of the checker from the Github Repo (or reference a CDN version) of “editoria11y.min.js,” and then create a new “Ed11y” instance:

<script src="/YOUR_FOLDER/editoria11y.min.js"></script>

<script>
   const ed11y = new Ed11y({
     // your configuration options
   });           
</script>

The default settings work for most content management systems, but you may need to set some custom configuration to constrain the checks to editable content, adjust the colors to match your theme, and control which users are presented with issue dismissal tools.

Note that it is possible to run the checker headlessly to build a custom interface, and to send results to an API.

Recent Updates

  • Drupal GovCon 2023
    Session 1 Content Creators Want Automatic Accessibility Checks An in-depth look at how inline checkers like Sa11y and Editoria11y work differently from developer-focused manual tools and crawler-based dashboards. Session 2Editoria11y v2: Building a Drupal-integrated Accessibility Checker A developer’s tour of the JavaScript, Web Components, JSON API and Drupal features that make up the Editoria11y checker.
  • Under-the-hood tour
    “Editoria11y v2: Building a Drupal-integrated Accessibility Checker,” was presented at DrupalCamp NJ 2023. Slides (Sheets) / Slides (.pdf)
  • Towards v2
    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… Read more: Towards v2
  • ​Introducing Editoria11y
     Creating highly accessible Web content is complicated, and tends to start with a lot of training. Familiar practices must be discouraged: New practices must be encouraged: Certainly some of our trainings are rolled out because we are teaching new concepts, but at some point the question needs to be asked: how much of the need… Read more: ​Introducing Editoria11y

Credits

Editoria11y is maintained by Princeton University’s Web Development Services team.

Editoria11y began as a fork of the Sa11y library, which is led by Adam Chaboryk at Toronto Metropolitan University. The libraries share most tests, and our teams work together on new features!

Sa11y itself began as a fork of Tota11y by Khan Academy.