Problem/Motivation
Honeypot field triggers an error in accessibility checkers. Specifically, there is no label or title attribute.
1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
Success Criteria 1.3.1 Info and Relationships (A)
Check 57: input element, type of "text", missing an associated label.
Repair: Add a label element that surrounds the control's label. Set the for attribute on the label element to the same value as the id attribute of the control. And/or add a title attribute to the input element. And/or create a label element that contains the input element.
Proposed resolution
I am not 100% sure how to best handle this, since the intent of the honeypot generated field is not for humans to complete the field. Possibly adding a title attribute to the field would satisfy the accessibility checkers ( previous evaluation done on https://achecker.ca/checker/index.php ).
This introduces a new potential issue, for people using assistive tech, is this field accessible? Would a human possibly encounter this field and dutifully complete it? Not sure how that would be handled.
Remaining tasks
Review accessibility standards ( WCAG 2.0 (Level AA)? ) and determine the best way to:
- Ensure that Honeypot can meet the standards.
- Ensure humans using assistive tech are not misidentified as bots.
Comment | File | Size | Author |
---|---|---|---|
#12 | honeypot-aria-hidden-on-text-field-2944843-12.patch | 450 bytes | rikki_iki |
| |||
#10 | honeypot form_element before container.png | 44.61 KB | rikki_iki |
#8 | interdiff-4-and-8.txt | 576 bytes | josephdpurcell |
#8 | honeypot-aria-hidden-on-text-field-2944843-8.patch | 904 bytes | josephdpurcell |
| |||
#7 | honeypot-aria-hidden-on-text-field-2944843-7.patch | 649 bytes | josephdpurcell |
|
Comments
Comment #2
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedInteresting, 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:
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...
Comment #3
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedWe are seeing this issue as well. It is showing this content on the page:
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:
Comment #4
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedI 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.
Comment #5
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedThanks for bringing this to the accessibility channel in Slack, @josephdpurcell.
The belt-and-braces approach of using
aria-hidden
anddisplay: 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?Comment #6
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commented@andrewmacpherson - it does have a real label:
Anyways, the patch seems adequate as a belt-and-suspenders approach to me.
Comment #7
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedThis 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.
Comment #8
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedI 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.
Comment #9
josephdpurcell CreditAttribution: josephdpurcell at Digital Bridge Solutions commentedI 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?
Comment #10
rikki_iki CreditAttribution: rikki_iki at PreviousNext commentedAs 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).Comment #11
rikki_iki CreditAttribution: rikki_iki at PreviousNext commentedForgot the patch :)
Comment #12
rikki_iki CreditAttribution: rikki_iki at PreviousNext commentedUpdated patch filename comment ref
Comment #13
mlncn CreditAttribution: mlncn as a volunteer and at Agaric for Drutopia, Portside commentedThanks 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...)
Comment #15
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedThanks for the patches and testing, everyone! This is now in the -dev branch.
Comment #17
armyguyinfl CreditAttribution: armyguyinfl as a volunteer and commentedDo you know when this patch will be included as part of the stable build so that I can remove the dependency patch in composer?
Comment #18
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedSometime 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.
Comment #19
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedfixing accessibility tag
Comment #20
armyguyinfl CreditAttribution: armyguyinfl commentedHi, 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: