Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author ovann86

    (@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'>";

    Thread Starter l r

    (@lainyrache)

    Thank you for taking the time for such a detailed reply! That is really helpful and interesting.

    Yes I was concerned about the tabindex for accessibility reasons. I have always been suspicious of tabindex as it disrupts the natural flow of the web page. However I’m ashamed to say I wasn’t aware of the usefulness of tabindex=”-1″ and from your reply and the supporting articles I am converted.
    There will be an accessibility audit and user testing on the site I am working on, so I will let you know if anything comes up about the tabindex.

    And thanks again for making this plugin!

    Plugin Author ovann86

    (@ovann86)

    Hey,

    Yes please let me know if someone can make a good argument about tabindex.

    Someone else asked the same thing – Im guessing some of the tools blindly say ‘don’t use tabindex … ever’.

    I’m going to try adding in a filter that will allow people to remove this by adding code to their theme’s functions.php file.

    I’m very keen to hear if your accessibility audit brings up any new issues for GF or this plugin.

    I know there’s a handful of issues in the GF core files I needed to manually change – like duplicate ID’s on multi-page forms. And I suspect some of the ‘grouped’ fields like ‘address’ are problematic for accessibility. – Group fields need to be wrapped in a fieldset, labeled at the top as a group then as individual fields – which I dont think GF or this plugin has done yet.

    Let me know if you hear anything else. Otherwise I’ll let you know when you can turn tabindex off without hacking the plugin code.

    Plugin Author ovann86

    (@ovann86)

    Hi,

    Many versions back I added a filter to allow people to disable this tabindex=-1

    I DO NOT RECOMMEND DOING THIS. All signs point to this making forms LESS accessible – noting that tabinex with a value of -1 is appropriate for these sorts of on page alerts.

    From the FAQS page …

    How do I disable the tabindex on the validation message

    I DO NOT recommend removing the tabindex.

    After considered research I am of the belief that tabindex with a value of =-1 is perfectly fine, and infact quite helpful in making critical messages such as a validation message appear immidately for screen reader users.

    With that said, if you want to disable it you can add this code to your theme’s functions.php file, below the starting <?php line.

    add_action('itsg_gf_wcag_disable_tabindex', function () {
        return true;
    });
Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Tabindex on validation errors’ is closed to new replies.