Implement accessibility checker for CKEditor 5

[Reinmar]

As discussed in https://github.com/ckeditor/ckeditor5/issues/1908 we designed features in CKEditor 5 in a way which helps the users to create accessible content. However, in order to ensure that the content produced by CKEditor 5 is accessible, we'd need a similar solution to CKEditor 4's accessibility checker.

---

If you'd like to see accessibility checker for CKEditor 5 add 👍 to this post.

[108signals]

We'd love to see CKEditor 4's accessibility checker ported over to CKEditor 5. Our customers (public organizations) require that all of their content is accessible and publicly available.

[mgifford]

I wouldn't recommend this @JayNathSF as it is still based on QuailJS last I checked. Would be much better to move to axe, HTML Code Sniffer, Tota11y or Sa11y

Let's not continue to ship unsupported JavaScript.

[mgifford]

Also worth checking out the We4Authors Cluster &.Test 7 - https://www.funka.com/en/accessibilitytest

[mgifford]

Also, flagging the conversation from CKEditor 4 - https://github.com/cksource/ckeditor4-plugin-a11ychecker/issues/242#issuecomment-763055511

Tota11y is used in Sa11y and Editoria11y

HTML CodeSniffer is used in CKEditor Accessibility Auditor

Surely there are enough good ideas here to pull something together for CKEditor 5 that is better than what was available for CKEditor 4.

[dylanb]

axe-core is used in CMS and editor integrations that are not open source and/or free and has features that are well designed to be used by such an integration

1. axe-core automatically turns rules on and off based on whether you are analyzing the entire HTML page or just a section of it so it should give your content editors exactly the right results depending on what you analyze.
2. axe-core allows individual rules to be run with a simple configuration and also allows individual rules to be turned off with a simple configuration that can be passed to the run function. So turning off color contrast for example is really easy if that is not something an editor can influence.

[itmaybejj]

Editoria11y maintainer here. Would love to help.

Ideally in my opinion there would be live ambient hinting rather than a manual check button. We really could integrate certain checks and hints into the tools themselves. Most authors in my observation don't click manual check buttons; that's why I created an automatic checker. Certainly not authors who haven't been to accessibility trainings...

E.g. -- If the editor makes a whole short paragraph bold, throw a tooltip in that moment asking if they want to make it a heading. And if they are creating that heading after an h2, maybe float h2 and h3 to the top of the list, as the others are probably mistakes -- and break the list up with a "not recommended" divider! And if they create a table, create it with header rows by default; put the burden on them to remove the headers. And if they are adding an image, don't have them leave the alt field blank to mark it as decorative -- make the field required but have a separate toggle to "mark the image as decorative so it is ignored by screen readers."

Which is to say: a lot of what I am checking for is situations where the defaults and options lead people astray. I'd much rather help integrate those hints at the content creation moment than reimplement a manual checker.

[108signals]

@itmaybejj great analogy of spell checking and doing accessibility check in real-time to improve utilization.

Curious if Editoria11y is already integrated into CKEditor (my understanding is Drupal ships with it but I haven't used Drupal in a few years).

And really exciting to see your expertise in this area and your offer to help!

Let us know if we can help in any way.

[mgifford]

As far as a clarification @JayNathSF Drupal doesn't ship with it, but there is a module to add it in to CKEditor for Drupal.

My goal would be to have something like this integrated into CKEditor 5 and have that enabled for Drupal Core at some point.

[itmaybejj]

Yeah; Editoria11y's Drupal integration triggers after the page renders (outside of the checker). I consider that a stopgap step forward.

That said...my school-of-hard-knocks education in assembling Editoria11y was that checkers all follow a similar pattern inside the black box:

1. Start a scan in response to some trigger
2. Traverse the DOM and run some if statements (most are no more complicated than "does each image have an alt attribute and is its content not on this list-of-garbage regex?")
3. Inject markup into the page.

Which is to say: once you get past the "scary black box" factor, there's no need to become dependent on an externally library. You will have to write your own triggers and popup integrations anyway (1 & 2), so it might make sense to just think about what tests are relevant to content inside a CKEditor box (it's less than a quarter of AXE, trust me), and then yoink and adapt those specific if statements from an open source library to directly integrate into your plugin if no library is a perfect fit (or has been abandoned).

Performance is such an issue in these things btw -- I spent a ton of time optimizing to not have my library make the page janky -- but my tests only run once, not over and over while a user is editing. In your case -- there's no need to run all the tests over and over again. I imagine it would make sense to run one full sweep when the editor opens, and then monitor the cursor position and only re-run relevant tests for the just-active element type when the user clicks, taps or presses enter, spacebar or tab; maybe combined with a bit of a debounce so it doesn't run while they are typing fast.

And then you could use or parallel CKEditor's native tooltip architecture to make a native-looking tooltip trigger:

[olets]

And if they are creating that heading after an h2, maybe float h2 and h3 to the top of the list, as the others are probably mistakes -- and break the list up with a "not recommended" divider!

I recognize this probably isn't the place to write out a wish list, but since this specific thing was mentioned:

This would be a dream come true for my team. It's something we talk about and work on ad hoc solutions for repeatedly. Support for it would be strong point in favor of using CKEditor.

[itmaybejj]

It's CK4 -- dunno how much code translates -- but this group already has working code for it: https://github.com/a11yfirst/ckeditor-plugins/tree/master/plugins/a11yfirst-headings

[mgifford]

Also worth noting this approach from the We4Authors Cluster https://accessibilitycluster.com/main-results/live-testing-while-authoring

[mgifford]

Also this Drupal module implemented HTMLCS - CKEditor Accessibility Auditor - don't think it works with CKEditor 5 yet.

[mattsimpson]

This is still a really important feature for us, and something we really liked and benefited from in CKEditor 4. Is there any plans on reintroducing this functionality?