ovann86

Hi,

I’m curious what removing this tabindex would achieve – could you fill me in? Is this an accessibility issue? Is it conflicting with something else on your page?

As you would already have noticed, this plugin removes the tabindexes that are usually applied to Gravity Forms form fields. The tabindex you’re referring to however is a -1 and is there as one of the measures to make the error validation message take the focus as soon as loads. By doing this, if there are errors an AT user should instantly know that the form submission (or page change) was not successful, know why and be able to navigate to the fields with errors.

This focus is applied only when the error message is displayed and is done by:

• Using tabindex='-1' on the error message DIV
• Using aria-live='assertive' role='alert' on the error message DIV
• Using JavaScript to set the focus to the DIV, using window.location.hash = '#error';
• Using jQuery to set the focus to the DIV, using $(this).find('.validation_error').focus();
• Using jQuery to set the window position to the top of the DIV, using $(this).scrollTop($('.validation_error').offset().top);

So there’s already a lot of measure in place to make this behaviour work, and I’m willing to remove it from the source code – but I just want to make sure it’s the right thing to do.

Here’s what WebAim have to say about tabindex -1
Keyboard Accessibility – Tabindex

and another article that briefly covers when it is OK to use tabindex -1

Don’t Use Tabindex Greater than 0

From reading these, I’m thinking people generally hate tabindex because it’s been used wrong too often, but it’s still a valid technique when programmatically setting the focus using -1. The issue with this of course is it makes the user skip past the ‘skip to contents’ – but the other measures (listed above) already do this – but that’s OK because we really do want AT users to know that there were errors rather than have to hunt through the page content every page load to see if the error message is there.

So please, let me know your perspective, the pro’s and con’s or if you have knowledge of where this causes accessibility issues. From here I’m seeing it is valid HTML, passes the WCAG 2.0 AA spec and using Firefox,IE,Chrome and JAWS performs as expected.

In the meanwhile, if you want to remove it from your copy of the plugin, you can edit the gravity_forms_wcag20_form_fields_plugin.php file, at line 67 change

FROM

$message .= "<div class='validation_error' tabindex='-1'>";

TO

$message .= "<div class='validation_error'>";

Hi,

Can you share the URL of where it’s installed or email it to me at admin at itsupportguides dot com ?

I want to check the the jQuery that that this is loading, and the jQuery is on the page. Also if there are any other JavaScript/jQuery errors on the page that may be stopping it from running.

Hi,

No, not at the moment and I’m not sure it’s something I will be able to implement … sounds tricky !

I believe the ckeditor WYSIWYG has support for image uploading, but I would have to figure out how to hook into the uploading, tell it where to save the images, add it to the WordPress media gallery, and then once the image is uploaded tell ckeditor the upload path so it can add it to the content.

If you’re up to the challenge give it a go and I’ll be happy to integrate it into the plugin.

Failing this, I’ll see what I can do … but not feeling confident.

Hi,

Could you please update to the latest version and see if there issue is still happening.

In the latest version I moved jQuery to load in the footer, not sure if this will have any effect on the issue you’re experiencing though – but worth the try.

Just to confirm, you are seeing this error message on the front end – not the back end form editor?

Going to assume this is resolved and close the ticket.
Let me know if it’s still any issue.

Hi,

Sorry for the delayed response.

I’ve updated the plugin so that the jQuery script loads in the footer (using the wp_footer action).

I’m hoping this resolves the issue you’re seeing.

I can see it’s already resolved one other issue, where the script was loading multiple times if there were multiple WYSIWYG fields – so that’s a bonus.

Update to version 1.1.2 and let me know how you go.

Also, thanks for the good idea.

I like to see links to external websites (like these are) open in a new window.

Hi,

I’ve added a feature in version 1.4 that makes these links open in a new window.

Upgrade to version 1.4 then try enabling the ‘Open Disqus usernames in new window’ option from the options page (‘Comments’ -> ‘Disqus Latest Comments’).

Let me know how you go.

Hi Steve,

Sorry for the delay in responding.

Contribution is more than welcome!

I wrote this plugin to support a project I was working on, so I can say as a fact that I’ve only looked at the standard fields that my project was using. I did read somewhere not to bother using the grouped fields like ‘address’ because they’re an accessibility nightmare – maybe something worth adding to the to do list if it is issue.

There’s two other bugs reported, I’ll let you know once I’ve sorted those out and update the copy on GitHub. (I’m almost certain the copy on GitHub is out of date.)

PS: I’m glad I’m not the only one that sees versioning on GitHub as a pain – it means I end up with a version on my development environment, the wordpress SVN and GitHub – argghh !

Hi,

Definitely my fault.

Because Disqus provides the terms terms in English I’m using jQuery and JavaScript to change the terms after the content has loaded.

I had used .text() to find and replace that part of the text, but forgot they were links was links – so changed it to .html() and it seems to be OK now.

Did you want to give version 1.3.1 a try and let me know?

Hi,

I’ve added some options to the backend that will allow you to change the Disqus time terms.

Update to version 1.3 and check out the new options in the WordPress administration -> ‘Comments’ -> ‘Disqus Latest Comments’.

You will need to provide your alternative term (language) for each of the default terms, e.g. hour ago as well as hours ago.

It’s very quickly put together and only very briefly tested – please let me know how you go.

Thank you for your quick response!

I appear to have got what I wanted by using the configuration below.

It loads ‘template1.php’ if I don’t specify template= in the query string, and if I specify template=template-html.php it loads the html template.

Note I’m using $_GET[‘fid’] instead of a specific form id so it can be applied to any form. My system will be creating and deleting templates on an ongoing basis, and the template can be applied to any of them.

Thanks again !

global $gf_pdf_default_configuration;

 $gf_pdf_default_configuration = array(
 	'template' => 'template1.php',
	'pdf_size' => 'A4'
 ); 

  $gf_pdf_config[] = array(
  	'form_id' => $_GET['fid'],
	'template' => 'template1.php'
);

 $gf_pdf_config[] = array(
  	'form_id' => $_GET['fid'],
	'template' => 'template-html.php'
);

Hey,

It looks like it’s missing a comma – there’s a dot there instead by mistake.

Could you try

$content = str_replace("<label class='gfield_label' >".$field_label,"<label class='gfield_label' for='input_".$form_id."_".$field_id."' >".$field_label." <span id='field_".$form_id."_".$field_id."_dmessage' class='sr-only'> - " . sprintf( __( 'must be %s format', 'gfwcag' ), $date_format ) . "</span>",$content );

Note that comma after the first $field_label

Failing that, if you can export the form and email it through to [email protected] I’ll take a look at what’s going wrong.

Resolved by using the gform_entry_field_value filter to display the field as a clickable link.

Hey,

I updated the plugin, and once again today to version 1.2.1.

This is probably going to be an ongoing process, which I hope results in something I can pass onto the Gravity Forms developers for it can be done in the core version. (imagine that – a forms software that can claim 100% accessible – would be a real selling point for them!)

I noticed my multi-page forms still don’t pass the automated checks, something about duplicate ID’s. – I think each page DIV (including the hidden pages that aren’t being displayed, hidden using css) have duplicate ID attributes .. not sure if a plugin can fix that, potentially something worth raising with the developers if there’s no real reason why it’s done like that.