Documentation: Tab order in the create form

[DonRichards]

The tab order doesn't exist and hitting tab jumps around. Tabbing jumps straight to content model then save, skipping everything in the middle.

To recreate

go to /index.php/node/add/islandora_object
Start filling out the form and hit tab to jump to the next line.

[mjordan]

Funny, not getting anything useful to address this by googling/duckduckgoing. I would figure there had to be module for that.

[mjordan]

There's https://www.drupal.org/node/1973218#tabbing, but seems like overkill to have to write JavaScript on a per-form basis, especially on a highly variable form like the add/edit form.

[DonRichards]

@mjordan tabindex of a form

$form['sheet_wrapper'][$node->title]['amount'] = array(
    '#type' => 'textfield',
    '#title' => t('amount'),
    '#size' => 3,
    '#maxlength' => 3,
    '#description' => t('amount of errors'),
    '#default_value' => isset($node->sheet_wrapper[$node->nid]['amount']) ? $node->amount : 'abc', // default value
    '#prefix' => '<td>',
    '#suffix' => '</td>',           
    '#attributes' => array('tabindex' => '6'),    //<<<<<---- ADD THIS LINE
    );

Apologies, I copied this right out of a form page. Adding the "attributes/tabindex" should fix this.

[mjordan]

Given that site admins can add new fields, remove existing ones, etc., any '#attributes' => array('tabindex' => 'x') code we inject with hook_form_alter() or whatever will be very brittle. How would we make sure that whatever we added would continue to work as expected?

[mjordan]

Was thinking about this. Since you can alter a form to inject the tabindex attribute into any element, if you can get the weight of all the form elements in a rendered form like the node add/edit form, you should then be able to alter that form to inject the tabindex values so they correspond to the ordering of the form elements. That would at least 1) align the tabbing order with the layout of the form and 2) generalize the altering of tabindices so that they are way less brittle than hard-coded ones. Not sure how that would work for multivalued fields like the ones @DonRichards shows above since it appears that the tabindex attribute applies to the entire form element, not to its subelements.

[DonRichards]

I think that's at least a start. Where would this code/config need to be?

[mjordan]

@DonRichards I'm tabbing through both the node add and edit forms and am not experiencing what you describe. For me (using Firefox and also Chrome on Ubuntu), starting in the title field and tabbing moves focus down the form in the way I'd expect, and doesn't jump around unpredictably.

Can some other people try on different OSs/browser combinations to see what happens?

[manez]

Just tested this on a brand new build in Mac/Chrome and and Mac/Safari, and I'm not reproducing. There is a slight difference, in that Chrome hits "show row weights" and Safari skips it, but they both go in the order I expect.

[DonRichards]

When you use http://future.islandora.ca/ you get the same result?

[manez]

I do - down to Chrome/Safari treating "show row weights" differently

[DonRichards]

ok, I got something odd going on here. I just tested this on my office computer and it's behaving as expected but not on my laptop. So I"m not sure the rhyme or reason. So this could be a "me" issue or a hint to something else. I'm leaning towards a "me" issue right now. I think I'll close this until I can find a way to deliberately cause tab orders to fail on a different machine.

[DonRichards]

@mjordan @manez Thanks for walking through this with me. I hate when it turns out to be nothing but I'm really appreciative when people take the time to "unpack" a problem.