Comment Form Accessibility Compliance

Hi @imarkinteractive

our honeypot is hidden and therefore needs no label as this is for screen readers.

See your own link:

Labels are not required for image, submit, reset, button, or hidden form controls.

Looks like this is bug in WAVE. Maybe there are only checking for a hidden attribute and not for aria-hidden="true" what we are using.

There is an ongoing discussion which needs feedback if switching would be helpful here without breaking spam protection or accessibility.
https://github.com/pluginkollektiv/antispam-bee/issues/292

Would be great if you can test with this change and report back.

All the best
Torsten

Its a false positive, as thought.

Here is an article, where someone discussed it already and also got contact to WAVE about it: https://equalentry.com/equal-entry-website-mistakenly-called-out-as-inaccessible/

If you want to get rid of the message, then you could add a <label for=”id…” aria-hidden=”true” style=”..”>Hello Bot;)</label> for the textarea and hide it as you already hide the textarea.

Or…just ignore WAVE. WAVE is aware of this problem since 2020 already and dint fix it. So, better use Lighthouse.

• This reply was modified 2 years, 10 months ago by xwolf.

Actually, it’s not a false positive, the textarea needs an accessible name to pass validation.
There is an easy fix for that.
I commented in GitHub
https://github.com/pluginkollektiv/antispam-bee/issues/292

Looks like we will add the label then. Thanks again @rianrietveld !

The issue moved to this place:
https://github.com/pluginkollektiv/antispam-bee/issues/434

All the best
Torsten

Actually, it’s not a false positive

Actually it is. The article cited above contains an answer from the developers from WAVE:

… text input that is hidden with aria-hidden=”true” and tabindex=”-1″. This field does not appear to be presented to users, so the error can be ignored …
In WAVE we have chosen to identify potential errors and issues with all page elements, even if they are hidden. We’ve found that in the vast majority of cases where hidden elements have identifiable issues, these issues are at some point presented to end users (such as via dynamic page changes, by the user disabling styles, etc.). We know that there are sometimes exceptions (such as yours) where hidden elements may not be presented to users via aria-hidden and/or tabindex. In the somewhat rare cases where such elements are hidden in an accessible manner, they can often be removed entirely from the page or the accessibility can readily be added to them. In your case if you can add aria-hidden and tabindex, then it’s probably reasonable to assume you can also add a or aria-label to address the detectable error pattern.

From: https://equalentry.com/equal-entry-website-mistakenly-called-out-as-inaccessible/

TL;DR: Error can be ignored, but the error can easily be prevented if we add the label.

So, we add this label and hopefully do not get more false reports confusing the people.

Thanks @xwolf and @rianrietveld !

Without this great community help we couldn’t understand and fix these things so fast.

Hopefully the spammers do not try to use this label in any way …

All the best
Torsten