Steps to reproduce on fresh Drupal site using default install profile;

  1. Create and article node node/add/article
  2. Do not enter the title yet
  3. Optional; Enter the text into the article body
  4. Select a file to upload
  5. Click the "Upload" button
  6. Wait for the file to upload
  7. Click the "Save" button
  8. Wait for drupal to tell you that the title field is required
  9. Enter a title
  10. Without tabbing or clicking elsewhere, hit the "Enter" key
  • Expected behaviour; The node is saved with the title body and file.
  • Actual behaviour; The node-edit form is returned, without the file, not-yet saved.
  • Browsers; Chrome on Mac OS X, and probably most browsers.

I think this is because the "Remove" button is the first button in <form>. It may be able to modify which button the browser uses to submit the form by using tab-index or similar. Otherwise this is pretty difficult to fix.

Comments

effulgentsia’s picture

effulgentsia commented
Component: markup » forms system
Priority: Minor » Normal
Issue tags: +markup

Subscribe. I disagree about this being minor. I'd love to know from front-end developers and accessibility folks if there's any best practices / standards on how to solve this without introducing some other undesired accessibility shortcoming (for example, I suspect removing buttons from tab-order entirely introduces its own problems). Seems like a problem lots of websites must encounter and somehow deal with.

Even though we haven't adopted #898538-7: Remove markup, CSS and JavaScript components officially yet, trying it out here, to see how it goes.

Everett Zufelt’s picture

Everett Zufelt commented
Issue tags: -Accessibility

As far as I can see this isn't an accessibility issue.

The standard for accessibility is that form fields are in the same tab order as visual order, or at least that it makes logical sense. That the submit save button is what action is activated (if any) when 'enter' is pressed in an input field (with the exception of multiline text fields).

* not an accessibility issue meaning that this is what is generally expected by users of forms in general, so there are no special accessibility issues to take into consideration.

effulgentsia’s picture

effulgentsia commented
That the submit save button is what action is activated (if any) when 'enter' is pressed in an input field (with the exception of multiline text fields).

I think this is the issue though. You press ENTER in the title textfield, but the form has 2 submit buttons: one for removing the file, and one for saving the node. Logically, we know that "Save" is the "real" submit button, but the browser doesn't know that: it sees 2 submit buttons, and submits the form as though the first one were clicked (in this case, the "Remove" button). @Everett: can you confirm that this really isn't an accessibility problem, or else re-add the "accessibility" tag?

Everett Zufelt’s picture

Everett Zufelt commented

It is definitly not an accessibility problem, everyone will be confused equally by this unexpected behavior.

Bevan’s picture

Bevan commented

I agree that everyone who uses the keyboard to submit the form may encounter this issue. I didn't tag it with "Accessibility" because only vision-impaired users may experience this, but because heavy keyboard-users may experience it. Most people use the mouse to click buttons and submit forms — not the keyboard (which is why this was marked minor). However the keyboard is an equally important input device used to access the system. Though I don't really care whether we call it an "Accessibility" issue or not.

Everett Zufelt’s picture

Everett Zufelt commented

@Bevan

It really doesn't matter to me if we call it accessibility or not. I just removed the tag because it isn't really something that requires special attention from the accessibility folks. You seem to have done a good job identifying the problem, which is unexpected behavior when enter is pressed in a form with a file field.

effulgentsia’s picture

effulgentsia commented
Issue tags: +D7UX usability

Thanks for the clarification, Everett. Now that makes sense to me why it's not an accessibility issue. Rather, it's a usability issue. We have several usability tags. Not sure if I picked the right one.

knaffles’s picture

knaffles commented

subscribe

effulgentsia’s picture

effulgentsia commented

By the way, I've been working on some Views UI issues, where we run into the same problem on several forms. In general, this problem is pervasive. The first button in markup order is often not the one whose action is most logical for a textfield ENTER press. In a couple weeks (after DrupalCon), I'll post a summary of what I've found, and some code that can solve the problem for users with JavaScript. For users without JavaScript, this remains a very tricky problem, and one we may want to consider a lot deeper in redesigning our approach to forms in D8.

casey’s picture

casey commented

#1190592: Provide a $form['#default_triggering_element']

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.