Accessibility Issue Triggered

Interesting, last time I tested I didn't seem to run into a problem; and in my testing on both the Drupal 7 and Drupal 8 versions I seem to have a valid label associated with the field:

<div class="url-textfield"><div class="form-item form-type-textfield form-item-url">
  <label for="edit-url">Leave this field blank </label>
  <input autocomplete="off" type="text" id="edit-url" name="url" value="" size="20" maxlength="128" class="form-text">
</div>
</div>

Are you sure this warning is coming from one of the Honeypot fields? Also, can you provide a definitive set of steps to reproduce the issue? E.g. use checker xyz, install Honeypot module, check this box, go to this page, run checker on it...

We are seeing this issue as well. It is showing this content on the page:

<div class="url-textfield form-group js-form-wrapper form-wrapper" style="display: none !important;"><input autocomplete="off" data-drupal-selector="edit-url" class="form-text form-control" type="text" id="edit-url" name="url" value="" size="20" maxlength="128" /></div>

Unfortunately, I also don't have a recommendation for a specific solution here. Here is the code that I believe is generating this markup, and therefore the issue, inside honeypot.module:

    // Build the honeypot element.
    $honeypot_class = $honeypot_element . '-textfield';
    $form[$honeypot_element] = [
      '#theme_wrappers' => [
        'container' => [
          '#id' => NULL,
          '#attributes' => [
            'class' => [
              $honeypot_class,
            ],
            'style' => [
              'display: none !important;',
            ],
          ],
        ],
      ],
      '#type' => 'textfield',
      '#title' => t('Leave this field blank'),
      '#size' => 20,
      '#weight' => 100,
      '#attributes' => ['autocomplete' => 'off'],
      '#element_validate' => ['_honeypot_honeypot_validate'],
    ];

I discussed this in #accessibility in the Drupal slack and it sounds like a screen reader would typically never see this field because of the display:none, however it may be the case that the checker is not checking the CSS, and only looking at markup.

That aside, it should be the case that adding aria-hidden to the parent div should be a quick / easy fix for this. I've attached a patch with that approach.

Thanks for bringing this to the accessibility channel in Slack, @josephdpurcell.

The belt-and-braces approach of using aria-hidden and display: none is fine. Both will hide it effectively from assistive tech.

The aChecker tool used in the issue summary does NOT test the CSS-processed DOM, according to this 2013 article -
Web Accessibility Testing Tools: Who tests the DOM?

It would be good to have a real <label>, in case of any human users encounter it with CSS turned off, and without assistive tech. Some users with cognitive impairments occasionally turn CSS off to avoid distracting visual styles. I don't understand why the #title doesn't get rendered - possibly something to do with the way #theme_wrappers is used?

@andrewmacpherson - it does have a real label:

<label for="edit-url">Leave this field blank </label>

Anyways, the patch seems adequate as a belt-and-suspenders approach to me.

This patch did not pass the WCAG 2.0 test with achecker.com.

I'm attaching a new patch that leverages the "H65: Using the title attribute to identify form controls when the label element cannot be used" strategy documented here: https://www.w3.org/TR/WCAG20-TECHS/H65.html. I will report back whether this allowed the check to pass.

I forgot to add the interdiff against patch #4, also I put the title attribute on the wrong element.

The attached patch corrects this, and I'm attaching an interdiff with #4.

I just confirmed the #8 patch passes the accessibility check.

It's likely that the aria-hidden is not required, it was just the "title" attribute on the input element, because the original issue is the missing label, which is satisfied by the "title" attribute.

I believe this can be reviewed, and perhaps we should remove the aria-hidden to keep this patch simplistic?

As mentioned in #5, the form label can be kept by adding form_element to the #theme_wrappers, before the container. This way the normal form element rendering applies - ensuring the label is kept, and is then wrapped by the container div (see attached image for example output).

Forgot the patch :)

Updated patch filename comment ref

Thanks Rikki!

The patch in 12 fixes it.

(I had somehow not noticed the display none when i noticed this as a potential accessibility issue myself... presumably there aren't non-CSS-interpreting bots that read and interpret text, and being extra-compliant won't reduce Honeypot's effectiveness...)

Thanks for the patches and testing, everyone! This is now in the -dev branch.

Do you know when this patch will be included as part of the stable build so that I can remove the dependency patch in composer?

I looked in version 1.27 & 1.29 and this accessibility patch has not been merged into the stable version.
- https://www.drupal.org/files/issues/2018-03-16/honeypot-aria-hidden-on-text-field-2944843-8.patch

Sometime in the future; right now I would rather not release a new tagged version just for this one change, but I will likely release a new tagged version in the next few months.

fixing accessibility tag

Hi, I see patch 12 was merged in but not patch 8 which is a different fix. This actually fixes the reported accessibility issue with honeypot.module when performing an ADA scan. Any change of getting this patch added as part of your next release?

Reference:

Do you know when this patch will be included as part of the stable build so that I can remove the dependency patch in composer?
I looked in version 1.27 & 1.29 and this accessibility patch has not been merged into the stable version.
- https://www.drupal.org/files/issues/2018-03-16/honeypot-aria-hidden-on-text-field-2944843-8.patch