I’m currently using gravity forms and struggling with the accessibility of it. It sounds like there are no plans to make it accessible, but I know a lot of people use this plugin, so let’s make the best of it.
Why Gravity Forms?
I recognize that gravity forms is not fully accessible, so why use it?
The answer: it’s currently the most user-friendly plugin out there.
However, if you have know HTML and you have access to your config file, definitely check out setting up accessible forms using Contact Form 7.
Overall, gravity form isn’t too far off.
The only issues I’ve found have workarounds or will be implemented soon I hope (at least in terms of the output. No comment on the admin panel side of things). All detailed below.
Follow the Usual Best Practices
I am not going to cover the usual best practices when using forms, such as how to organize the content or further belabour the point of not using (re)captcha, since I’m covering specifically using the gravity forms plugin. Obviously, you will still want to follow best practices when creating forms.
HTML5 Input Types
Turn on the ‘Output in HTML5’ under the settings page. Then use the most appropriate fields, especially those under the advance fields. You can make use of the newer input types, such as URL or email.
To help your users, you can use input masks wherever possible so that users don’t have to worry about entering data in a specific format, allowing the form to force it into the correct format.
If you want to support HTML5 elements pre-IE10, then make sure you’re running HTML5shiv, Modernizr, or something similar if it’s not built into your theme.
Avoid the “Presets”
I say use the most appropriate input so that you’re using HTML5 input types, but avoid the gravity form preset groups, such as ‘name’ (which inserts 2 (or more) fields for first and last names) or address (which adds all the standard postal address fields).
You also want to avoid the pricing fields, because
there is no proper one on one label-input relationship.
Thanks to Rian who pointed this out (in the comments).
Fieldset Improv
One of the accessibility techniques tells us that we should be using fieldset and legend to group related fields. The group might be a set of checkboxes, radio buttons, or logically related inputs (such as a mailing address).
Unfortunately, even though gravity forms provides an easy way to add multiple checkboxes and radio buttons as well as some preset groups, it doesn’t group the inputs in a fieldset and with a legend for the description.
However, you can do this manually. Gravity forms provides an “HTML Box” option where you can include the HTML you need, and because it simply inserts whatever you put in the box, your HTML elements do not need to be opened and closed in the same box (as long you can get it to properly validate).
In the “opening” HTML content box, include this code:
[code language=”html” gutter=”false”]<fieldset class="gfieldset">
<legend>Fieldset Description</legend>
<ul><li>[/code]
And yes, the <ul> and <li> are necessary, because each gravity form “section” is in a <li> and if you don’t have both, your page either won’t validate and/or the browser will automatically close your <fieldset> for you. (Thanks to Tuomo for pointing out the need to add the <li> as well.)
Insert all the fields (or just the set of radio buttons or checkboxes), then insert another HTML block to close your fieldset.
[code language=”html” gutter=”false”]</li></ul>
</fieldset>[/code]
Finally, because gravity forms will suddenly add bullet points to lists inside a HTML content box, add some CSS to your page to remove the list style type:
[code language=”css” gutter=”false”]list-style-type:none;[/code]
The easiest way is probably to do it inline within each <ul> that you need it for, but if you want to do it with a CSS rule, then it’s just a tad more complicated because gravity forms has a lot of style rules, many which already have !important in them.
If you only have one or two forms, you can use the ID selector of the form, since that’s the easiest way.
[code language=”css” gutter=”false”]#gform_1 .gfieldset ul li {
list-style-type: none !important;
}[/code]
If you prefer to have just one rule for all your forms, you can add the following CSS rule across the site:
[code language=”css” gutter=”false”]body .gform_wrapper div.gform_body ul.gform_fields li.gfield.gfield_html .gfieldset ul li{
list-style-type: none !important;
}[/code]
Note that both still rely on your having the gfieldset class in the fieldset tag.
If you need further explanation on how to overwrite CSS rules, check out the W3C’s explanation of CSS priority level of selector.
Disabling TabIndex
If you include links anywhere in your form, they will be skipped when tabbing through the form because gravity forms inserts tabindex based solely on the input elements added through the gravity form widgets.
While you need to do this for every instance that you insert a gravity form, you can do it through the gravity forms shortcode. For example:
[code language=”html” gutter=”false”][gravityform id=1 tabindex=false][/code]
That’s it.
If you want to do it for all forms and want to edit your functions.php file, then you can use the snippet of code provided by the help documentation on tabindex.
What’s Still Missing?
The only thing I haven’t been able to do is to add ARIA attributes to fields. The only one that needs adding pre-validation is aria-required for required fields. (Unless turning on the HTML5 output uses polyfill, in which case role=slide with aria-valuemin & aria-valuemax need to be added for range input.)
After validation, aria-invalid=true should be added for every field that has input not meeting its constraints and the ARIA role alert should be added to HTML element with the error message.
As per the using WAI-ARIA in HTML document, ARIA should not be explicitly set for any of the other input types unless in combination with the list element.
I submitted the request to the development team and this is the response I got:
This should be doable for us. I will look into what it will take to implement it. -Alex Cancado, Gravity Forms
Therefore, I’m hopeful that it will be added.
In the mean time, you could have a small piece of JavaScript that would insert the aria-required attribute (if not present) when the required attribute is present. The ones for the alert role and aria-invalid attributes are included in the examples of the documents linked above.
Conclusion
Gravity forms is great on the user-friendly side, but is still lacking in accessibility. However, I wrote this post because I know a lot of people are restricted in what they can access and what plugins they use.
Still, if you can edit your config file, I’d definitely suggest giving Contact Form 7 a try. (I’ll be doing that myself next week.)
Hi Cynthia,
Thanks for posting this!
Your solution for adding a fieldset and legend is a great one.
Maybe you could add that with combination input fields, like the address, there is no proper one on one label-input relationship, so avoid adding those for an accessible form, better use a plain text field for that.
This is also the case with the Name field. The option normal and extended don’t provide a one on one label-input relationship.
Also the price (amount) input fields make a mess of this.
Lately I discovered Contact Form 7, that plugin recently added accessible WAI-ARIA to the forms. And it gives you complete controle over the HTML you add.
A second plus for this plugin is that the backend is accessible.
But you are right, Gravity Forms is a great flexibel and user friendly plugin, it just needs some work.
Kind regards,
Rian Rietveld
Thanks! I’ll be sure to update the post with your comments.
Thanks for the Contact Form 7 info as well. I suppose it’s been some time since I last checked CF7, so it’s great to know that it’s become more accessible and flexible. I’ll definitely check it out.
While I haven’t tested this in about 9 months, Visual Form Pro used to output excellent, accessible, valid HTML forms.
Thanks for letting me know. Will check it out
hey Cynthia,
I just looked briefly at Visual Form Builder Pro, it seems actually quite good!
No WAI-ARIA , but an good accessible backend.
There is a demo you can try at http://demo.vfbpro.com
The generated seems HTML good, although every tabel/input is put into list items, personally I don’t like that, but it’s not wrong.
The plugin has a lot of options like Gravity Forms, as I can see it in a quick scan it can do about the same.
There is hope 😉
Thanks for the info. Though if there is no support for wai-aria, I’m more likely to go with the CF7 option.
Thanks for this post. Just wondering, any advance from the Gravity Forms people about ARIA support? I’m working on a project with high accessibility requirements, and we’re using Gravity Forms. There’s things such as required which would be great, but there’s other stuff – such as catering for radio button groups, and AJAX submissions – that would also need ARIA attention. I know GF enough to know it should be possible to hack this with filters, but I don’t want to reinvent the wheel if the wheel’s being shipped imminently! Can’t find any mention from GF about this, so wondered if you’d heard anything…
Thanks for the comment. Unfortunately, I have not heard of further support on this. However, if you are using Gravity Forms, I suggest that you submit a request for specific changes you would like to see. Something along the lines of “please add [specific ARIA property]…” with code snippet examples.
Hi Gyrus,
Im also working on a GF project with high accessibility requirements.
I created a plugin that goes a long way towards making GF more accessible – check it out and if you can think of any improvements or want to contribute to it please let me know.
https://wordpress.org/plugins/gravity-forms-wcag-20-form-fields/
Thanks for letting us know about this.
Hey Cynthia, thanks a lot for this article. It’s nearly addressing the exact issue I’m currently facing. I want to create a set of dropdowns, which all belong to a specific image. I think the best solution would be to, as you mention above, group both image and dropdown within a html field. My problem however is that for some reason I cant get the data validation for the html tag to work (I want to use this form in combination with woocommerce products, so it’s important for me to know what the customer selected in the dropdown & what image it belongs to).
Thanks a lot for your help 6 looking forward to hearing from you.
Hi Amir,
Thanks for writing. Could you give a bit more detail on what you mean by data validation? As far as I know, Gravity Forms itself does not do any validation (though it will do conditionals). When creating your notification, it should be easy enough to display the values your customer has selected.
Unfortunately, I’ve never used it in combination with woocommerce, so if it’s something specific to woocommerce and how gravity forms works with it, I can only suggest to contact woocommerce or post your question on the appropriate forums, or perhaps one of the relevant stackexchange sites. I know a lot of people use woocommerce, so I wouldn’t be surprised if someone else might have an answer for you.
Sorry I can’t be of more help.
Unfortunately, the method for creating fieldsets produces invalid HTML as GF ends the HTML block with . So the opening fieldset tag is within one list item, and the closing tag is within another.
Sure wish they’d come up with some other way to do fieldsets or at least groupings.
Hi Steve, Looks like whatever tag you were talking about got stripped out of the comment. Does it not work even if you end the HTML block with an opening ul tag like I mention on my post? That was really important when I was testing it last. GF may have updated something to change that.
I believe I ran into the same problem as Steve Johnson did back in April. My issue was with GF wrapping the HTML blocks with li elements. Therefore if I wanted to open the fieldset tag in HTML block and close it in another, I created invalid HTML.
I was able to work around the problem however. Please check out my markup here: http://pastebin.com/xxe4mQxV In parentheses you’ll find the GF created li elements. All other HTML is the markup I have in my HTML blocks.
It’s very hacky yes, but it works.
Thanks for the pastebin link. Definitely helpful. I’ve updated my post to also have the opening and closing li tags in addition to ul. Thanks again for the workaround.
Does anyone know how to make the “Add Item” and Delete Item” icons in list fields accessible via the keyboard?
Hi Peter, are you talking about in the form making part of Gravity forms? The blog post focuses on the resulting form, not on the admin side. You might search the gravity forms forum and post in there, or ask the developers. Unfortunately,it’s much more difficult to change the accessibility of the admin side unless you customize the code, so it’s up to the developers to make that more accessible.
No, I’m talking about the form itself, not the admin side. I did contact the vendor, and they are trying to come up with a solution.
Still relevant in 2020, thank you!
Still relevant in 2021, thank you!