Hello Adrian,
thanks for the amazing plugin!
I am trying to change the error message “There was %s error found in the information you submitted” or better the translated message (German).
I edited the .po and .mo file but it didnt work: Is there a better way to change the error message?
Would love to get your help.
Greetings from Germany,
Philipp
Accessibility issue: The fieldset element automatically has the implicit aria role=”group”. The role=”group” does not allow for the aria-required=”true” to be set on it. This needs to be on the fields inside the group which appears to be.
Recommended remediation: Remove aria-required=”true” on the fieldset element. Also we would like to bring Gravity Form up to WCAG 2.1
Hello,
I have translated this plugin to Finnish couple of weeks ago. Can you update the translations to this plugin officially? Thanks! Here are the finished and approved translation strings: https://translate.www.ads-software.com/projects/wp-plugins/gravity-forms-wcag-20-form-fields/stable/fi/default/
]]>Hello, we love this plugin as it makes GF more useful. Please make sure it’s tested up to date version so it will not be taken away from plugin repository. Also, do you have a GitHub for contributions? Thanks for the awesome plugin.
]]>Hello,
I’ve made translation files for french language. You can find it here :
https://www.dropbox.com/sh/odvueg4kaaib8nu/AAAZ0gR8jWrpiMshWKqq4qjha?dl=0
Strangly, my strings where always used in french, even when I was on the site in English. By adding the load_plugin_textdomain in the ‘init’ action, this fixes the problem :
/**
* Load plugin textdomain.
*/
add_action( 'init', 'gf_wcag_load_textdomain' );
function gf_wcag_load_textdomain() {
load_plugin_textdomain( 'gravity-forms-wcag-20-form-fields', false, dirname( plugin_basename( __FILE__ ) ) . '/lang' );
}
It seems to be a best practice.
Can you use this in a future update?
Thank you!
]]>I’ve been using this plug-in for a while and really appreciate the work that has gone into it. However, I’ve come across an issue.
One of my clients has a membership form. On this form, the pricing fields are set as radio buttons. While other groups of radio buttons and checkboxes are being wrapped in a fieldset on the form, it seems that pricing fields that are radio button groups are not. Siteimprove is flagging these fields as A violations under “1.3.1 Info and Relationships” and “3.3.2 Labels or Instructions” for “Form elements are not grouped”
Is there a fix for this?
]]>The HTML generated by GF for multifile uploads includes a button element overlaid on an input type=file element. This results in an extra tab stop. We were called out on that by the Department of Education Office of Civil Rights. Is there anything you can add to your plugin to help with that? Thanks for the great plugin!
]]>Hey Adrian – Thanks for all your wonderful GF plugins. I have been using many of your wonderful plugins (including this one) which add much needed functionality to Gravity Forms. For some time, I have noticed that most of your plugins for GF have been decommissioned from the www.ads-software.com, and my wordfence security plugin is flagging them as abandoned plugins and high risk, though they continue to work without problem.
I just need some clarity on the below couple of aspects, if possible. Kindly respond:
1. Any particular reason why these wonderful GF add-on plugins have been decommissioned from www.ads-software.com, which you can share with us? Did www.ads-software.com remove it due to lack of updates, or did you request removal of these plugins from www.ads-software.com?
2. Is there any security issue with these decommissioned GF add-on plugins of yours? Do we need to remove them necessarily or can we continue to use them if they still work?
3. Can we get updates/latest versions of these plugins from any other source or website? Is any support available for them still (if needed), even if its paid support?
My sincere apologies if this is is not the right forum to ask these queries, but I did not know where to contact you regarding this information, so asking here. Thanks.
]]>Hello!
Would it be possible to add a feature to this that changes default headings (h3’s) to h2’s? I’m sure not everyone will want h2’s, so that could be an issue, but using h2’s instead of h3’s makes it a little better. Forms can all be their own sections, easily navigable using a screen reader. Even better if the h3’s are styled to still look like the h3’s.
]]>Hi,
Hi,
I use Gravity Forms which creates forms that work fine for me with Jaws2019 screen reader.
However when I create a survey form (link in field above) the radio button fields, checkboxes are not reading by Jaws – I just get the text read to me but nothing about a checkbox or the status of the box.
I tried using this plugin to fix the issue but didn’t seem to make a difference.
Can you expand this plugin to fix these errors or have to wait for GF devs to fix the output code?
Problem exists in both Chrome and Firefox.
Dale.
I’m using Gravity Forms with Beaver Builder and I am able to style all of the error messages with the exception of the summary error list that the WCAG 2.0 Form Fields for Gravity Forms adds to the top of the form. Can you tell me where I can change the color of the text? It appears to be picking up all of the other font styling. Great plugin BTW!
]]>The plugin will not work when gravity forms are loaded via an AJAX call.
The root cause of this are the is_admin() calls in the plugin.
For more information please refer to the following links to see why relying on is_admin() (when doing AJAX for example) it’s a bad idea:
1. https://facetwp.com/is_admin-and-ajax-in-wordpress/
2. https://dev.to/lucagrandicelli/why-isadmin-is-totally-unsafe-for-your-wordpress-development-1le1
3. https://www.pluginvulnerabilities.com/2016/05/13/security-tip-for-developers-the-is_admin-function-doesnt-tell-you-if-someone-is-an-administrator/
I’ve stumbled upon this issue while working on a website which had the same form, once loaded normally (not via AJAX) and once more on another page, where the form was loaded via AJAX inside a popup.
How I fixed it (temporarily of course) ?
I added a get_is_admin() function to the plugin’s class:
function get_is_admin() {
return is_admin() && !wp_doing_ajax();
}
and then I replaced all the is_admin() calls in the class with self::get_is_admin() calls.
Of course, now, I need to disable plugin updates too for this plugin, on the site I made this fix, until this issue is fixed.
]]>Hi there! When using the File Upload type input; Webaim Wave shows an error:
An aria-labelledby or aria-describedby reference exists, but the target for the reference does not exist.
This occurs even on your demo site:
Thanks, awesome plugin!
]]>Gravity Forms does not appear to add a “for” attribute on the label when rendering the Consent field (found under Advanced Fields). Is connecting the checkbox ID to the label in Consent fields something this plugin could address?
]]>If you go to https://cityofwinterpark.org/departments/electric-utility/urban-forestry/ and expand the following form “Tree Removal Permit Application” on the list field called “Tree(s) Information” you will see that the plus sign has another plus sign overlaying the button. If you click the JavaScript doens’t work properly, it triggers another window to open up.
Any idea what could be causing it? If I disable the WCAG plugin it works fine.
Thank you!
]]>Does this plugin still play well with Gravity Forms, given that they’ve now added more accessibility to their plugin? https://www.gravityforms.com/gravity-forms-v2-4-7-released/
]]>There is already a ticket about this, but it’s closed to replies — however this issue is still there as of 1.7.0…
Could you please update add_filter( 'gform_tabindex', … )
to use '__return_false'
instead of create_function()
?
Thanks!
]]>Hi ,
I have some form fields which do not have corresponding labels. There should be a feature to add aria-labels to these fields to improve accessibility.
]]>First, thanks for the great plugin! It cleans up 99% of the accessibility issues I have had with Gravity Forms.
I did find out on the form with a credit card field, the the credit card number field fails a Google Accessibility Audit claiming no obvious label even though there is a for attribute that is correctly linked to the input ID.
The Year select in the Expiration Date does not have a label, as it is one of two selects (the other for month) grouped with the label – which is tied to the Month Field with it’s for attribute.
These are the only issues I have found. Are you still supporting this plugin? If so, is this a feature you will address in a future version?
]]>I am still getting an error when using the Multi-Select field as a drop down. It says it is missing a form label and that the form control does not have a corresponding label. Are there any fixes?
]]>Specifically the address field, the str_replace
to add the open fieldset tag seems to have changed from the string you are looking for. I was able to get it to work by editing line 263 and replacing with:
<label class='gfield_label gfield_label_before_complex' >{$field_label}<span class='gfield_required'>*</span></label>
Without this opening fieldset replacement, the plugin adds an </fieldset>
tag without an opening tag which throws HTML errors.
I’d like to submit a pull request for this plugin to address the issue here: https://www.ads-software.com/support/topic/create_function-is-deprecated-in-php-7-2-2/
It’s very important this gets fixed and is a one line change. The alternative is forking the plugin and making it available to the public on Github. It’s obviously better if you could support this change in a single canonical change.
You need to change line 61 from:
add_filter( 'gform_tabindex', create_function( '', 'return false;' ) ); //disable tab-index
to
add_filter( 'gform_tabindex', '__return_false
); //disable tab-index`
Thanks.
]]>Hey There,
When it comes to Gravity Forms, your plugin does great things for WCAG 2.0. However, I did notice an issue.
For a date field (mm/dd/yyyy) from advanced fields in GF. You add in the “aria-describeby=” field. When you add that description, WCAG flags an error for duplicate labels.
When you look at the code it seems as if you and gravity forms are including the “field_id_id_dmessage”
See the snippet below:
<input type=”number” maxlength=”2″ aria-describedby=”field_5_12_dmessage field_5_12_dmessage” name=”input_12[]” id=”input_5_12_1″ value=”” min=”1″ max=”12″ step=”1″>
Is there any way we can fix this? I’d be happy to discuss further in more detail with you.
Thanks!
]]>PHP 7.2 has marked create_function()
as deprecated, so this plugin will start throwing a warning if you update your PHP version. It’ll look something like this:
Deprecated: Function create_function() is deprecated in [path to your wp-content directory]/plugins/gravity-forms-wcag-20-form-fields/gravity_forms_wcag20_form_fields_plugin.php on line 61
Until the plugin is updated, change line 61 to:
add_filter( 'gform_tabindex', '__return_false' ); //disable tab-index
It was recommended during an accessibility audit to have each row of data numbered using the title tag.
They also recommended adding a scope=”col” to the th tag.
There was also some keyboard access issues around the radio buttons for other options and the add/remove buttons for the row.
Would this be something that could be added to the plugin?
]]>These were erring out prior to the plug-in install. But still having an issue post plug-in.
]]>When I submit a form with errors, I am shown a refreshed version of the page with the appropriate errors displayed. However, there are not any arai-descrbiedby attributes for fields with failed validation. I tested on a staging site w/ the TwentySeventeen theme and only Gravity Forms & WCAG 2.0 form fields for Gravity Forms plugins active and the issue persists.
Any assistance on this would be greatly appreciated!
]]>We recently did accessibility testing on our site with remote users with disabilities (specifically those who use screenreader software). The good news is, they found the forms very useable. So wonderful job, and thanks for creating this plugin, which has helped a lot!
However, we did get one comment that I wanted to pass along. Our testers gave the following feedback:
On the forms, the form fields for date and backup date read the format line as mustbemm/dd/yyyyformat as opposed to having it in separate words, must be mm/dd/yyyy format.
Thanks again!
]]>I installed the plugin, and it magically fixed most of my accessibility errors. Yay! But, a couple persisted… And they’re all caused by the multi-file upload fields.
Looking at the html, I can see there are two different <input>
s that make up the field. I’m not sure how this works or why there are two… but the first has aria-describedby="field_5_15_dmessage field_5_15_fmessage extensions_message_5_15"
and the second does not, therefore is resulting in an error in the accessibility checker I’m using.
Here is an example: https://www.huroniafestivalofartsandcrafts.com/test/
and this shows the error: https://wave.webaim.org/report#/https://www.huroniafestivalofartsandcrafts.com/test/
I’m guessing this is just an obscure scenario that hasn’t been caught yet…hopefully an easy fix?
]]>In the form preview, I see the placeholders, but on the front end, the placeholders disappear. This only happens on the First Name / Last Name field. I disabled all plugins, and by process of elimination, I found it was this plugin that was stripping out the placeholders.
The preview inspector looks like this:
<input type=”text” aria-required=”true” name=”input_4.3″ id=”input_14_4_3″ value=”” aria-label=”First name” aria-invalid=”false” placeholder=”First Name”>
The actual front end looks like this:
]]><input type=”text” aria-required=”true” name=”input_4.3″ id=”input_14_4_3″ value=”” aria-label=”First name”>