[upstream] Include an accessibility tester in CKEditor (axe, Tota11y, HTML Code Sniffer)

Great idea!

+1 for the principle.

Renaming for consistency with #2239419: Include CKEditor's AutoGrow plug-in.

Updating issue summary with the tasks we need to carry out. Adding the library assets are atomic enough that they can be separate task issues.

The README included with a11ychecker says:

"**Running on local filesystem:** You cannot run Accessibility Checker on a local filesystem, since Quail uses an `XMLHttpRequest` for fetching its resources. This is not allowed when working with the `file://` scheme."

This is something we might want to document for developers.

Also, it seems we could use a different a11y testing library instead of Quail. From the a11ychecker plugin page:

The default implementation uses Quail as its accessibility tests library, but you can integrate any other similar library to achieve comparable results.

To make this work by default in core, we'll certainly need to include at least one a11y test library; it may as well be Quail.

In a follow-up issue, we could investigate adding an API (by plugin or hook) to allow contrib modules to provide other testing libraries or services. Possible candidates include aXe (open source library, Mozilla Public License) and Tenon.io (commercial API service).

I think Quail makes most sense, because:

• it's the library they tested against/collaborated with the most, so it's going to be the most reliable option
• it's maintained by former Drupalista Jesse Beach :) — which means any problems we may have are more likely to get resolved sooner, and any upstream work we may want to contribute, will be easier to do, because she knows the Drupal Community's Ways

And as soon as we can use Fetch API I'm sure the code can evolve to use that instead of XMLHTTPRequest

And as soon as we can use Fetch API I'm sure the code can evolve to use that instead of XMLHTTPRequest

That's very, very far out.

Re: #12 That will be an upstream issue for Quail one day, but not a blocker for us here.

Working on this

So, here is a first stab at this. I recompiled ckeditor with the new plugins. Since this includes a diff on a minified 700kb jquery.js file and a new sprite image, the patch is huge.

- This patch still needs tests. I'll add those later.
- I don't think we need to add Quail, since the plugin comes with a quail library included.
- I still need to add a configuration form. Let's discuss first what we want to configure.

I've also include a patch without the ckeditor change, for easier review.

+++ b/core/modules/ckeditor/src/Plugin/CKEditorPlugin/AccessibilityChecker.php
@@ -0,0 +1,71 @@
+class AccessibilityChecker extends CKEditorPluginBase implements CKEditorPluginCssInterface {

One class? That's it?
Awesome!

Vote 1 for making this enabled by default in standard profile's editors

wow. This is very cool.

Glad to see the many votes of support, but…

Since this includes a diff on a minified 700kb jquery.js file

Increasing the size of CKEditor for *everyone* by 700 KB is not acceptable IMO. We should then load it as a CKEditor plugin, separately, and hence not increase the size of our CKEditor build.

Hi Wim,

apologies for not being clear. I meant that the ckeditor.js (not jquery.js) needs a small change to include the plugin. Drupal's original minified ckeditor.js is currently 544kb. With the new plugin added, it is 727kb (so an increase of 183kb).

Removed duplicate comment

Related issue: https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/202

I agree that the best approach would be including it as a plugin.

With the new plugin added, it is 727kb (so an increase of 183kb).

That's still a too significant increase in size.

I agree that the best approach would be including it as a plugin.

Glad to hear you confirm it :)

I imagined that Quail would be a separate library in core/assets/vendor/quail. Apart from addressing the performance concern, a separate Quail library would be good for other use-cases:

• Use Quail with other rich-text editors. Contrib modules will likely provide more integrations built upon editor.module, and Quail could be used with those too. Quail already includes example plugins for Tiny MCE and Aloha editors.
• The Accessibility contrib project also uses Quail to provide accessibility reporting on content. It would make sense to let this use the same copy of Quail as the rich-text editor uses.
• Developers can test theme templates, forms, etc., without involving CKEditor (e.g. running Quail via Grunt).
• We might use Quail for automated a11y regression tests. (One day, fingers crossed!)

I wrote the tasks for the issue summary, without really understanding how the CKEditor build system worked. Sorry if that caused confusion.

@Wim; would you be so kind to explain what needs to be done te facilitate this? Either by updating the issue description or by sending me an e-mail. Thanks!

It sounds like the size of the library can (technically) be reduced. https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/202#issue...

Here's to hoping that version 1.0.1 is the first version that can suit all the use cases we've described above.

#24++

So:

1. Add Quail as an independent asset library. Add the assets in core/assets/vendor/quail, and list it in core.libraries.yml. However, the a11ychecker plugin does not yet support loading Quail from a separate location. There is https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/202 to solve that.
2. Add the a11ychecker plugin to core/assets/vendor/ckeditor-a11ychecker. (Just like we have core/assets/vendor/jquery and core/assets/vendor/jquery-form etc.)
3. However, we want that plugin to be minified, because it will be loaded directly by CKEditor, so Drupal's asset pipeline is never involved. I talked to the CKEditor team, and we could do it by running sh build.sh, which will minify all plugins, and we could then extract the one we want. Or, the much easier option: just download and extract http://ckeditor.com/addon/a11ychecker's tarball, and put it in that location.
4. Repeat 2–4 for http://ckeditor.com/addon/balloonpanel, which is a dependency.

That means this issue is hard-blocked on https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/202.

(Sorry for the slow reply, I was blocked on a reply with advice from the CKEditor team.)

So, clearly this is now blocked on upstream, on https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/202.

Just in case someone will want to have these features right away. There are contrib module for CKEditor Ballon Panel and for CKEditor Accessibility Checker.

Similar to this issue having had its version changed
from 8.2.x-dev » 8.3.x-dev
would someone please be so kind as to review
the list of Drupal 8 core issues
sorted with:
- Open
- Version "8.x"
- Tag "aria"
https://www.drupal.org/project/issues/search/drupal?status[]=Open&versio...

Would 'you' please change the version on any 8.2 issue
that you feel can justifiably be changed to 8.3
so that any 8.3 developers who do not look at 8.2 issues
will be aware of them.

I myself am in no way qualified to do that,
or I surely would.

Thank you for your time, attention, and help.

PS: This is the issue search for
'Open', '8.x', & 'accessibility'
if you have a few extra, um, minutes (or should I say 'hours'?)
to address those issues similarly. Thank you.

https://www.drupal.org/project/issues/search/drupal?text=&assigned=&subm...

#31: I don't understand your comment. How is it related to this issue?

Also: all issues must be filed against 8.2.x if they can be committed to 8.2.x. Bug fixes must land in 8.2.x first (and are then cherry-picked to 8.3.x). Tasks/feature requests must be committed to 8.3.x.

@BarisW - thanks for prompting the CKEditor upstream issue for progress.

https://github.com/cksource/ckeditor-plugin-a11ychecker/issues/204#issue...

Just noticed that QuailJS is no longer being developed - there's a deprecation notice on the QuailJS Github repo.

Given the realities of the market and the limited time that the Quail team can devote to this project, we are initializing deprecation for this project. Folks are welcome to fork it or volunteer to maintain it, but realistically, there are better options out there.

Hi all! Would you advise against using the a11ychecker CKEditor plugin (and module?) altogether, or is the Quail issue just a blocker for it being included in Core?

Also, #7 says you cannot run a11ychecker on a local filesystem -- does that mean there would be disruptive breakage if I'm working in a local environment, or does it degrade gracefully and the warning is just an FYI that this particular functionality won't work -- or something else entirely?

Thank you! I love the idea here, and I hope it can work out!

Addressing #38: Here is the patch of POC version of axe-core ckeditor integration.
Credits for the @azuma , @t0r, @artemboiko for the work on the integration.
So here some additional info:
https://github.com/artemboyko43/ckeditor-axe - Repo of the ckeditor4 axe-core plugin itself
https://github.com/semkulich/ckeditor_axe - Repo of the Drupal integration module for the plugin
https://github.com/iVegas/ckeditor_axe_env - Repo for the dev environment

Steps to review basic functionality (based on the demo_umami profile installation):
- apply the patch;
- install the module;
- edit the Basic text format and add the axe button on the panel. save changes;
- make sure that aggregation of the css/js files disabled, then cache rebuild;
- go to the one of the articles edit page;
- set the same value of the ID attribute on the two different tags within the body field in the source view mode. save changes;
- open the edited article edit page again
- press on the axe button
- select one of the available levels of the validation or keep the default options, press ok;
- now the window with the existing violations would appear;

Known issues of the current integration module:
- currently, no behavior implement for the content without issues;
- no configuration for the default text format after module installation;
- css/js aggregation issues

Hope this patch would be useful for further improvements of the a11y tool for the ckeditor.

And the patch is here)

I'm definitely in favour of having this functionality available, especially based on the axe core, now that quail has been deprecated. I understand the motivation of wanting this in core, but wouldn't it make more sense to get this working as a contrib module first, and then try to get it into core once it's been tested/used/validated as a standalone module first? Many other initiatives have gone this route, including Workspaces.

It's way easier to get people using this as a contrib module first IMHO. I'd be happy to help get this set up as a standalone project based on voleger's work in the most recent patch.

@mandclu This does exist in contrib form: https://www.drupal.org/project/ckeditor_a11ychecker

One thought -- I don't know if this is feasible, but for organizations with an accessibility mandate (e.g., government organizations), it would be great to have an option to prevent publication of a node if it doesn't pass an accessibility check.

@mgifford Is there anything we can do to get HTML_CodeSniffer into a stable state covered by the security policy?

I know my organization is definitely interested in including an accessibility checker on our sites, but not being covered by the security policy is a major issue.

axe is great, but if HTML_CodeSniffer is more likely to happen then I'd be all for that.

New release of CKEditor Accessibility Auditor (which uses HTML_Codesniffer) to make it ready for Drupal 9.
https://www.drupal.org/project/ckeditor_accessibility_auditor/releases/8...

There's now a stable release for CKEditor Accessibility Auditor:
https://www.drupal.org/project/ckeditor_accessibility_auditor/releases/8...

I much prefer the UI of the ckeditor_a11ychecker module, regardless of the QuailJS issue. We only enable the accessibility button in ckeditor for trusted users.

The CKEditor Accessibility Auditor flags way too many minor issues and is too complex for many content editors to the point where they just don't use the tool.

Example Tests

Note: our site theme is also applied to the WYSIWYG so colors, fonts, etc are an exact match to what will be displayed on the site. This is important when doing color contrast testing (that might depend on font size).

TEST 1: Created a two text paragraphs and then inserted an H6 heading in the middle:

• ckeditor_accessibility_auditor: flagged 0 errors, 5 warnings, 23 notices. It seems to be checking the entire Drupal editor form rather than just the text within ckeditor (It sees a "Dummy Title" h1 tag for example that it is unable to point to). Several warnings of "This element's text is placed on a background image. " One of the warnings was "This h6 element should be an h2 to be properly nested." which isn't necessarily true depending on the context of the body field on the page.
• ckeditor_a11ychecker: reported no issues.

TEST 2: added an H2 element above the first paragraph.

• ckeditor_accessibility_auditor: 0 errors, 6 warnings, 23 notices. Same as above but another "This element's text is placed on a background image. " warning.
• ckeditor_a11ychecker: "Header level 2 can not be followed by levels from 4 to 6" highlighting the H6 with a Quick Fix to change it to H3 if desired. No other issues.

So for content editors, ckeditor_a11ychecker was a *much* better experience.

I agree that I would love to see a proper AXE-based tool. But lets remember to focus on the content editor experience when adding something like this to core. Too often I see accessibility reporting taken too far with so many minor warnings that it ends up being ignored.

Also, testing accessibility within CKEditor when sites often have a different Admin theme from their main theme will be problematic for issues like color contrast (link colors, etc). We'll need to properly set expectations on what rules are being tested. An accessible body field content doesn't necessarily mean the node page itself will pass accessibility. In our case we just want to flag content-related issues such as wrong heading levels to the editor.

The ANDI accessibility checker might be something to consider (https://github.com/SSAgov/ANDI). It's developed by the U.S. Social Security Administration and I've found it to be one of the best a11y checkers.

Editoria11y maintainer here. I'd argue for a new, "light" checker with as few false positives as possible, that runs automatically as users type. I've found checkers that hide behind a button tend to get ignored, and all the existing checkers have too-cluttered interfaces for non-technical users. I am not knocking them -- I LOVE them as a technical user and rely on them all the time -- but they are overwhelming for content authors.

Also worth noting -- I don't think we should be afraid to fork/adapt old code. The new tests that get added to checkers are ever-more-in-the-weeds issues with ARIA and the like. Tests that work today for things like heading nesting order and table headers are not going to change.

Honestly our time might be best spent helping with this same issue for CKEditor 5 -- might as well fix this for everyone, not just Drupal, and then just include that new native checker. I was hoping to finish my WordPress port of Editoria11y this spring and then turn my attention to this...

Re: the comment from @mpotter about heading warnings, I personally thinking it's entirely appropriate to throw a warning (not an error) about using an h6 in content without any indication that this heading level is semantically correct. But it probably isn't worth squabbling over these kinds of details.

It would be possible to further customize CKEditor Accessibility Auditor, but as @mgifford has indicated, it would involve either dramatically restructuring the output of HTML_CodeSniffer, or potentially even forking it.

I haven't had a chance to use Editoria11y yet (but plan to shortly), so my opinion so far is based on the project page. Based on what I can see, this seems like a much better approach. I've updated the project page for CKEditor Accessibility Auditor to indicate that Editoria11y is likely a more robust solution for most use cases.

I agree with @itmaybejj that at this point, we should probably be thinking about the introduction of CKEditor 5 and what that would mean for anything that might be introduced in this thread. It seems like Editoria11y shouldn't be impacted by what version of CKEditor is in use, so I can see it still having value, especially because it should scan all page content, not just what's in the WYSIWYG.

I like the idea of more generally helping CKEditor 5 to identify accessibility issues as content is being created, but Drupal could also layer on something that would do a broader scan of all page content.

I forked the code from the repos shared by @voleger above. It worked but the pop-up was buggy. I updated to the latest libraries for axe-core and for ckeditor4. The plugin itself is here https://github.com/ejdunn2001/ckeditor-axe the module is here https://www.drupal.org/project/ckeditor_axe. It seems to be working but it isn't displaying the results. I definitely am going to need some help and/or advice on this one.

So many interesting plugin options (yay / ugh haha) -- for real though, this comment is me bumping the "Needs issue summary update" tag:

I think, either:
(1) Update with the options currently being considered

Or

(2) If the list of "in the running" plugins is itself TBD, we could simply say that in the summary, and remove what's listed in the summary right now (or move to "original issue summary" section).

-------
I'd be happy to help, especially if people pick "option 2" -- right now I just feel like I'm too behind to have a handle on what plugins are under consideration.

++ for #65

Editoria11y experience is great!
Focusing on content editors and provide them with friendly explanations.

CKEditor has been removed from core, CKEditor 4 is removed from Drupal Core in 10.0.0

@mgifford Does an accessibility tester exist for CKEditor 5?

Makes sense!

Tagging accordingly, to make it clear there's nothing actionable here right now.

[updated issue summary]

...happy to report that Editoria11y now
works out of the box as a Ckeditor5 accessibility checker, which might provide a solution for your upstream problem.