reCAPTCHA accessibility solution
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)
Contact Form 7 WordPress plugin
Share
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.
Thanks for sharing this excellent solution. That WAVE error was driving me crazy!
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.
This is very useful and great post!
An elegant solution for WordPress sites with Google Recaptcha to pass the accessibility checker. Thank you!
This is very useful post
It’s not working for me.
I create a js file and add on functions.php the code but nothing still have issue with missing form label
Are you able to confirm if the js file is definitely being loaded on your live page? If you search the source code, there should be a reference to ‘custom-scripts.js’ near the bottom (in a script tag, before the closing body tag).
Thanks for this solution, worked like a charm.
Thank you. This worked great. I still can’t believe Google hasn’t fixed this.
Thank you so much! 2024 and still it’s helping people! Thank you!