Open DannyLancaster opened 1 year ago
An example of how Drupal implement this: https://www.drupal.org/project/editoria11y
TinyMCE have this as a paid for feature of their latest editor
Maybe with the new integration of TinyMce some new settings could be added to the appSettings to allow people to add their own keys for the paid version (assuming that’s how it works). It would potentially make it easier for Umbraco to add it as a cloud feature should they want to in the future.
I've also created a draft PR for a11y checking in preview mode https://github.com/umbraco/Umbraco-CMS/pull/13328. Just a bit stuck on the gulp tasks.
To have the content tested while writing is something many authors are used to and appreciate when it comes to spell checking and similar functionalities. In the same way, accessibility mistakes can be pointed out and corrected immediately. This way, inaccessible content can be avoided and the burden of making accessibility tests and remediations tend to feel less cumbersome.
A live accessibility check can be done in the WYSIWYG editor while publishing, inspecting the content and supporting the author with help - texts and easy to understand suggestions for remediation.
Web author view
Example: TinyMCE accessibility checker plugin![image](https://user-images.githubusercontent.com/32459580/192260839-2bd4a1dd-cc6e-4856-9271-834d2657b800.png)
When you run the check, you get a warning with a short description and a link to more in-depth information for that specific rule.
The question mark leads you to the TinyMCE website that has descriptions of the ruleset that is checked. The Accessibility Checker aims to be WCAG2.1 AA compliant. https://www.tiny.cloud/docs/plugins/a11ychecker/
There is an online demonstration of the accessibility checker in TinyMCE: http://fiddle.tinymce.com/glhaab
Possible built-in success criteria conformance tests to be done:
<h1>-<h6>
to identify headings.<ol>
,<ul>
and<dl>
for lists or groups of links.<caption>
elements to associate data table captions with data tables.<th>
and<td>
.Tools like Sa11y and Editoria11y allow web authors to focus on what they can control. Most accessibility errors are introduced in the editor’s body field, so it is possible to target the WYSIWYG to that field and generate accessibility errors that target that section of the page specifically.
Sa11y - https://ryersondmp.github.io/sa11y/#install Editorially - https://itmaybejj.github.io/editoria11y/
Editoria11y needs to have JavaScript added to the HTML headers for the page:
Video documentation
https://youtu.be/mf5MQhgLW4g
Recommendations for implementation
To make sure the implementation of the features is not causing accessibility problems for web authors with disabilities: