0

hCaptcha is a fairly popular captcha solution (see a demo.

Their systems works roughly like this:

  1. Websites add a div to a form with a sitekey and also add hCaptcha's JavaScript
  2. hCaptcha adds an iframe and 2 textareas to the form.
  3. When a visitor solves the hCaptcha, the two textareas are filled with a token that is submitted to the site
  4. The site can send the token in a server-to-server call to verify the user passed the captcha

The texteares added in step 2 look like this:

<textarea id="h-captcha-response-0da5o6pd30l5" name="h-captcha-response" style=""></textarea>
<textarea id="g-recaptcha-response-0da5o6pd30l5" name="g-recaptcha-response" style=""></textarea>

According to the pa11y these textareas are not accessible. Screen readers need to know that these form elements are not meant for human input, but are instead just for the functioning of the site. I believe one solution could be to add the HTML attribute aria-hidden="true" to both of these textarea elements.

Is there any solution that consumers of hCaptcha can do? Or what would the best thing for hCaptcha be?

TylerH
  • 20,799
  • 66
  • 75
  • 101
greggles
  • 2,089
  • 5
  • 20
  • 38
  • Could you share your code (minus your key)? The text areas should not be visible. hCaptcha's documentation says that a hidden token is added to the form, but it looks like it's being made visible on the demo site. – Ezra Jan 10 '22 at 05:02

1 Answers1

0

Because these textareas are only used by hCaptcha and not meant to be interacted with by the user, they should be hidden. By using display: none on each textarea, hCaptcha will still be able to include the hidden token in the form submission without causing the accessibility issue.

It's not clear what framework you're using, but the output should look something like this:

<textarea id="h-captcha-response-0da5o6pd30l5" name="h-captcha-response" style="display: none;"></textarea>
<textarea id="g-recaptcha-response-0da5o6pd30l5" name="g-recaptcha-response" style="display: none;"></textarea>
Ezra
  • 1,118
  • 9
  • 13
  • They are not visible to sighted users, but because they lack the aria-hidden=true HTML parameter (or similar solution) they are visible to visitors using a screen reader. – greggles Jan 10 '22 at 14:35
  • Right, `display: none;` also makes those fields hidden to screen readers, according to WebAIM: https://webaim.org/techniques/css/invisiblecontent/#:~:text=display%3Anone%20or%20visibility%3A%20hidden&text=The%20content%20is%20removed%20from,want%20hidden%20from%20all%20users. – Ezra Jan 10 '22 at 15:30
  • 1
    I agree with @Ezra. `display:none` is the best solution. You can't use `aria-hidden` by itself because that would **not** prevent the screen reader user from TABBING to the textarea. It would only cause the element to not be announced by the screen reader which makes the situation worse - you can TAB to an element but nothing is announced. You'd need `tabindex="-1"` in addition to `aria-hidden`, but `display:none` handles all of that for you. – slugolicious Jan 10 '22 at 16:55
  • I would argue that any screen reader that allows any user access (reading the content, focus, modifying) to `display:none` elements is broken but if such tools indeed exist, maybe those broken tools honor `aria-hidden="true"` instead? – Mikko Rantalainen Sep 05 '22 at 12:20
  • This question just earned the "Popular Question" badge from Stackoverflow because a lot of people visit it. That seems to indicate a lot of people care about the evaluation of accessibility in automated scanners even if it is "technically not a problem." I hope HCaptcha will reconsider and change their HTML. – greggles Jun 29 '23 at 16:07