The user_login form is the only form in Drupal core that defines a tabindex attribute:

function user_login(&$form_state) {
  ...
  $form['name'] = array('#type' => 'textfield',
    '#title' => t('Username'),
     ...
   '#attributes' => array('tabindex' => '1'),
  );

  $form['pass'] = array('#type' => 'password',
    '#title' => t('Password'),
    ...
    '#attributes' => array('tabindex' => '2'),
  );
  ...
  $form['submit'] = array('#type' => 'submit', '#value' => t('Log in'), '#weight' => 2, '#attributes' => array('tabindex' => '3'));

  return $form;
}

Specifying the tabindex is however not required as the natural order of the fields (username, password, submit) in the markup already provides the desired usability/accessibility.
Moreover, the presence of the tabindex makes it a bit unnecessary hard/messy to add an accessible CAPTCHA element between the password field and submit button: #128550: Tab Key on User Login Form passowrd field jumps to 'submit' button instead of captcha field. I guess there are other cases of form_altering that suffer from the same problem.

The attached patch removes the tabindex attributes from the user_login form.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Status: Needs review » Reviewed & tested by the community

Interesting bit of history, lying there. Those should obviously go away.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

soxofaan’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Reviewed & tested by the community
FileSize
1.12 KB

Thanks,
any chance the backport for D6 can get in?

Damien Tournoud’s picture

I support the backport too. It shouldn't hurt.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Well, I guess you could have altered the tabindex just as well. Anyway, makes sense to commit to Drupal 6 too. Done!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.