reCAPTCHA accessibility solution

Estimated reading time: 2 minutes

What the problem is

Whilst updating accessibility statements for key websites in our portfolio, I came across a  new error courtesy of a free Google service named reCAPCHA.

reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.

Some of our WordPress sites use the reCAPTCHA tool in conjunction with webforms to validate user submissions. Using the WAVE web accessibility evaluation tool to complete an audit it highlighted a “Missing form label” error within the reCAPTCHA HTML.

  • What it means:
    • A form control does not have a corresponding label.
  • Why it matters:
    • If a form control does not have a properly associated text label, the function or purpose of that form control may not be presented to screen reader users. Form labels also provide visible descriptions and larger clickable targets for form controls.

Simply speaking, the code generated by Google itself is missing several ARIA attributes required to comply with basic Web Content Accessibility Guidelines (WCAG).

How we solved it

After some preliminary Google searches I found a couple of forum threads attempting to tackle this specific problem. Most were a little out-of-date, some attempting to resolve it for Drupal instances and others involved hacking the WordPress plugin reliant on reCAPTCHA.

Attempting to follow a best-practice approach I added a new JavaScript file ‘custom-scripts.js’ to our existing WordPress child-theme:

jQuery(window).on('load', function () {
    let textarea = document.getElementById("g-recaptcha-response-100000");
    textarea.setAttribute("aria-hidden", "true");
    textarea.setAttribute("aria-label", "do not use");
    textarea.setAttribute("aria-readonly", "true");
});

And modified the ‘functions.php’ file to include this new jQuery depended JavaScript within the footer:

add_action( 'wp_enqueue_scripts', 'my_custom_script_load' );
function my_custom_script_load(){
     wp_enqueue_script('my-custom-script',get_stylesheet_directory_uri().'/js/custom-scripts.js',array('jquery'),false,true);
}

Feel free to share

These minor code changes now ensure that when running the WAVE tool again this accessibility error no longer appears. A win for everyone!

Thank you to Hristo for resolving my reCAPTCHA iFrame issue and proposing the jQuery fix.

Hopefully this solution benefits others and please leave a comment if you know of another solution.

Related links

WAVE web accessibility evaluation tool

Guidance on the new EU accessibility regulations (UoE wiki page – EASE authentication required)

Google reCAPTCHA service

Contact Form 7 WordPress plugin

By Stewart Lamb Cromar

Too geek to function.

3 comments

  1. This is great and thoroughly explained. It could also be wrapped up inside a small plugin for users who don’t want to (or cannot) edit theme files.

    Of course, this would not be necessary of those brilliant engineers at the Google could just fix their code.

  2. This cool and works well but I think it should be pointed out that it can cause errors on pages without recaptcha if it’s loaded globally for every page and doesn’t cover situations where you may have 2 forms with recaptcha on the same page.

Comments are closed.