WAVE test failing

[Zodiac1978]

First reported here: https://wordpress.org/support/topic/comment-form-accessibility-compliance/

@Zodiac1978
The solution is to add aria-label="whatever" as attribute to the textarea.

The automated tool checks if a form control has an accessible name. In this case, even if the form control is hidden from sight and screen reader, it must have an accessible name to pass the WAVE test.
This can be easily solved by adding an aria-label like aria-label="comment"

<textarea aria-label="comment" id="two" 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>

The aria-label can be anything, because it is never announced or visible.
And then it passes WAVE :-)

I made a codepen with both options, with and without adding aria-label. The the first one fails, the second one passes in WAVE.

Originally posted by @rianrietveld in #292 (comment)

[Zodiac1978]

Thank you very much @rianrietveld !

I am still confused, because WAVE is telling us (emphasize from me):

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

Therefore the label shouldn't be required here, or not?

@2ndkauboy Any chance to get this in, even it is already in the comment form?

[rianrietveld]

@Zodiac1978 hidden refers to type="hidden" and in this case it's a textarea :-)

[Zodiac1978]

We could just add this here:

https://github.com/pluginkollektiv/antispam-bee/blob/master/antispam_bee.php#L1281

What about using hp-comment as the aria-label (for "honeypot comment" but not too much "telling")

[Zodiac1978]

Adding more details (emphasize mine):

… 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, what the PR is doing.