January 2nd, 2014: Updated to fix tabindex issues with forms added via the Gravity Forms widget.
Stop! This method is no longer recommended.
For accessibility reasons, adjusting the tabindex for Gravity Forms should be avoided. Giving the form priority over other interactive content is detrimental to users that rely on keyboard navigation.
This is most common when loading a Gravity Form on a page which is loading a non-GF form (like the WordPress comment form). You’re typing away on your Gravity Form and tab to the next field. Awesome. Except the next field is a completely different form. This snippet sets the starting index of your Gravity Form inputs ridiculously high so such conflicts never happen again.
{Gist removed. This article has been deprecated.}
How do I install this snippet?
Easy peasy. Just copy and paste the code above into your theme's functions.php file.
How to I use this functionality?
This snippet is plug-n-play. No changes needed (unless you’re still seeing tabindex conflicts which is highly unlikely). If you are, just update the 1000 in the snippet to a higher number until the conflict disappears.
Hi, I tried this code and it worked great. However, it screws up wherever I use dynamic lists.
I’m using this plugin: https://wordpress.org/plugins/list-field-number-format-for-gravity-forms/
Whenever you click the (+) to add another list item, the tab indexes are cloned from the previous line. So, instead of tabbing you from field A, to b, to c, all the way to the end of a line, it tabs you to all the fields listed in column a, then column b, then c, etc. Not an ideal situation. Is there a way to fix?
Unfortunately, this is something that you would need to work with the plugin developer on. :/
Thanks for the reply David. That makes perfect sense now.
I did then look at it & wonder if you could actually hook into a hook that was already firing. But I added some debug in there and sure enough we do get called twice… the first time on the ‘all forms’ hook with a form ID and then the second time into the form-specific hook without a form ID.
Thanks again for you help
Glad to help, Jon. :)
I love this and it works great – thank you.
I’m a bit unclear about why we need the if() clause though.
I see that we register against the GF hook for setting the tab index and we return the greater of 1000 or the global GF tab index.
But the if() clause seems to say that, if you’ve come here with a reference to a specific form, then register an additional hook for just that form to call this same function.
But we’ve already got this hooked function which is registered against ALL forms – so why the need to register another hook for one specific form? And it’s clear that this existing hook is triggered correctly for that specific form already – given that we’re in the function right now.
Does that question make sense? Seems to me that you could get away without the if() and the extra add_filter() that it executes.
You are free to remove this. What it does is provides an additional layer of specificity which gives the filter more “authority” to override tabindexes set in user error.
many many thanks! worked like a charm. truly appreciate your time in providing this useful tool at no cost. god bless.
Glad to help, Kevin. :)
This worked great and is 2 years old… Why has gravity forms still not implemented this…???
The short answer is, it’s complicated. GF has a very large user base. Even small changes can create big problems. Glad you found this useful. :)
Perfect! Thank you!
Thank you, fixed my problem exactly!
Thanks for sharing..! Awesome.
My pleasure, glad it helped you. :)