Accessibility: Form elements do not have associated labels

Hi @tada1

this does not look like the output of our plugin. May I ask you to add the website where this happens, please, so I can check? Or can you double check if it is our plugins used on this site?

If yes, could you please share your theme and active plugins, so I can try to reproduce the problem? Maybe there is a conflict …

Thanks in advance!

All the best
Torsten

Hi,

Thanks for your response.

I double-checked the theme and plugin (Antispam Bee 2.11.1). There is no comment-field-override in the theme.

The code which I am referring to is in the antispam_bee.php -file
in the replace_comment_field_callback() – function.
line 1269 – 1290: there is the first textarea with the dynamic properties and the second textarea with the static properties.

2 textareas and only one label and the one which is hidden has the label associated and the visible one with dynamic properties not. I am pretty sure that this causes the problem.

All the best

Hi @tada1

2 textareas and only one label and the one which is hidden has the label associated and the visible one with dynamic properties not. I am pretty sure that this causes the problem.

I understand where you are coming from, but I think this could be a bug in Lighthouse. Let me explain:

The label is coming from WordPress itself:
<label for="comment">

The “for” attribute is aiming at an ID.

ASB is adding a new “honeypot” comment field which is visually hidden via inline CSS:
<textarea id="comment" aria-label="hp-comment" aria-hidden="true" name="comment" autocomplete="new-password" style="padding:0 !important;clip:rect(1px, 1px, 1px, 1px) !important;position:absolute !important;white-space:nowrap !important;height:1px !important;width:1px !important;overflow:hidden !important;" tabindex="-1"></textarea>

It actually has a label via aria-label attribute and is hidden via aria-hidden="true".

To prevent styling issues, we now use inline JS to switch the IDs (line 1275-1278) back between real comment form field and honeypot.

It looks like Lighthouse has a problem with the JS here and is testing the markup before applying the JS. Or is ignoring the ARIA markup?

If you have a GitHub account, please find these discussions:
https://github.com/pluginkollektiv/antispam-bee/issues/434
and
https://github.com/pluginkollektiv/antispam-bee/issues/292

Maybe adding hidden instead of aria-hidden could help here, too?

If you have an idea to fix this without breaking the spam protection, please add your insights on GitHub (or here) and we will happily make this 100% again ??

I will check this next week in more detail too.

All the best
Torsten

Hi again,

I found the solution, but it is a bit tricky.
1. aria-hidden and hidden is not applicable in this case, the error “Form elements do not have associated labels” is only about the association of the label and textarea
2. My solution for this error is the following approach:
usually the connection is between ref on the label and id of the text-area. With aria-properties you can reverse it. So I added aria-labelledby=”comment-lbl” to the first textarea in antispam_bee.php and made a comment-form textarea override in my theme and put an id=”comment-lbl” to the standard label of the text-area. So the label references the hidden textarea with the standard way ref and id and the real textarea is referenced reverse with labelledby and id. This brings 100% score for me in the Lighthouse-Test and I think it probably will not break the spam-protection.

Cheers =))

Hi @tada1,

thank you for this solution!

I have opened up a GitHub issue, so our other team members can look at it:
https://github.com/pluginkollektiv/antispam-bee/issues/468

Hopefully we can fix it this way and still provide the same spam protection.

Thanks again!

All the best,
Torsten