Accessibility checker

The checker reads the content in the editor and reports what would make it hard to use with a screen reader or at low vision. It is built in and included in the licence, not a paid add-on. As of editor 2.6.7 it applies 18 rules, and most of them offer a one-click repair that fixes the markup while the author supplies the words.

It checks the content, not the editor: for how the editor itself behaves for keyboard and screen reader users, see Accessibility (WCAG 2.2 AA).

Using it

The toolbar button opens a panel listing what it found; selecting an issue highlights it in the document. Errors are things that leave content unusable for someone; warnings are things that make it harder.

// The checker is a plugin; it loads with all_plugins.js.
var editor = new RichTextEditor("#div_editor");

editor.accessibilityChecker.open();      // show the panel
editor.accessibilityChecker.toggle();    // show or hide it
editor.accessibilityChecker.close();

// Run it yourself - for example before saving - and read the result.
var result = editor.accessibilityChecker.run();
result.issues.forEach(function (issue) {
  console.log(issue.code, issue.severity, issue.message, issue.path);
});

// Block a save while errors remain, and let warnings through.
function hasBlockingIssues() {
  return editor.accessibilityChecker.run().issues.some(function (i) {
    return i.severity === "error";
  });
}

Every issue carries a code from the tables below, a severity of error or warning, a message written for the author, and a path identifying the element.

Images, links, colour and language

Headings and structure

Tables

Repairing an issue

A repair changes the markup; it never invents words. Where a rule needs text, pass it in and the checker writes it into the right place, then re-runs so the list stays true.

// Repair issue 0. The options an issue needs depend on its rule:
// the author supplies words, the editor does the markup.
var issues = editor.accessibilityChecker.getIssues();

editor.accessibilityChecker.repair(0, { altText: "Crew fitting the new roof" });   // image-missing-alt, image-alt-filename, image-alt-too-long
editor.accessibilityChecker.repair(0, { headingText: "Opening hours" });            // heading-empty
editor.accessibilityChecker.repair(0, { targetLevel: 2 });                          // heading-level-skip, paragraph-as-heading
editor.accessibilityChecker.repair(0, { captionText: "Sales by month" });           // table-missing-caption
editor.accessibilityChecker.repair(0, { markLayout: true });                        // table-missing-header, as a layout table
editor.accessibilityChecker.repair(0, {});                                          // fake-list, link-adjacent-duplicate: nothing to supply

Three rules have no automatic repair, and deliberately so: ambiguous link text, insufficient contrast and a duplicate id all need a human decision about wording, colour or which element keeps the id.

What it does not do

• It reads the content in the editor, not your published page: styles applied by your site can change contrast after saving.
• It cannot judge whether alt text is accurate, only whether it is present, not a file name and not excessively long.
• A phrase in another language written in the same script (French inside English) is not detectable; the language rule keys off the writing system.
• It is not a substitute for testing with a real screen reader before a launch.