Show accessibility issues while saving node content not after published content

Created on 24 August 2022, almost 2 years ago
Updated 4 April 2023, about 1 year ago

Show accessibility issues in page before saving content or publishing node.

✨ Feature request
Status

Closed: works as designed

Version

1.0

Component

Feature and test requests

Created by

🇮🇳India ashetkar

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇮🇳India SHIJU JOHN

    Hi John,
    I have a similar requirement to prevent publishing a content if any accessibility issues in the page. Is there any method which I can call for this validation from this module? Please suggest

    Best Regards,
    Shiju John

  • 🇺🇸United States itmaybejj

    @Shiju --

    If somebody wanted to extend to add that functionality, I would recommend bouncing through the Node Preview page:

    1. Take away direct publish button on the node edit form -- make it so the user must publish from the Node Preview (or a moderation/workflow action no the saved page).
    2. Add a JS event listener for ed11yResults, one of the JS events provided by the base library.
    3. Once ed11yResults has fired, you can pull the Ed11y.errors count from the results. Example code can be found in the JS I've written in the WordPress port that runs the library headlessly inside the editor. If Ed11y.errors is greater than zero, then there are red alerts on the page. I do NOT recommend using Ed11y.totalCount, as that will include "manual check" warnings to review things that are often OK -- e.g., nobody could ever publish a node with a link to a document if you blocked on warnings.
    4. Use the Ed11y.errors on the node preview to determine whether or not the user can publish from there.

    I have to say -- preventing publishing does make me nervous. You run the potential of preventing someone from publishing a page with a false positive on a complex custom widget. I'd recommend having some sort of bypass/override, even if it's just "you need to be an admin."

  • 🇮🇳India SHIJU JOHN

    Hi @itmaybejj,
    Thank you for your response on this. I am planning to give a bypass/overide option of this in my settings. I am thinking to add a form alter '#validate' in wysiwyg text area field like below.

    $form['my_element'] = [  '#type' => 'textfield',  '#title' => t('My Element'),  '#validate' => ['my_custom_validation_function'],
    ];

    Also I want to write a custom validation like below

    function my_custom_validation_function($element, &$form_state) {
      $any_ed11y_errors = \Drupal::service('ed11y-validator.js')->getJsSettings()['ed11y_errors'];
    
      // Validate the form element based on the JavaScript variable.
      if ($any_ed11y_errors) {
        form_set_error($element, t('Please fix the accessibility errors before publishing this changes.'));
      }
    }

    Finally in Javascript file I want to check the ed11y errors and pass to Drupal

    Drupal.behaviors.myBehavior = {
      attach: function(context, settings) {
        const ed11y = new Ed11y(ed11yOptions); 
        settings.ed11y_errors = ed11y.errorCount;
      }
    };
  • 🇺🇸United States itmaybejj

    That...looks really plausible. Hmm.

    If you get it working, I would love to see the code. I may be able to roll it in as an optional feature, or at least add it to the documentation as a starter-kit for other folks.

Production build 0.69.0 2024