Where did this come from?
This proposal stems from the Form Error Design Wiki where we gathered feedback from accessibility stakeholders (such as Everett Zufelt) as well as UX stakeholders (yoroy, bojhan). This wiki was a new attempt to build consensus around an old problem that started in the issue queue in 2009 and had 265 comments without resolution. Let's solve this for D8!
- More than color: Drupal must use more than color alone to indicate which fields have errors. This is a major WCAG violation that we didn't solve for Drupal 7.
- Links jump to errors: The $messages area at the top of the page will provide links to jump to errors as WCAG suggests.
- Full error text inline: At the location of each form field, its error text will be presented in full. The markup order will likely put the error message between the field's label and the field itself. The links from the $messages area will jump to the field label first so users can review the label, then the error, then the field where they can fix the submission.
- ARIA described-by: Use ARIA described-by to semantically associate the error message with the field in a machine-readable, assistive technology-friendly way.
- Improve readability
- "Prevents flooding the top of the page with long error messages" - yoroy
- On small screens and devices, users will be able to find relevant error messages for each field without scrolling up to the top.
The goal is to implement a new presentation of form errors in the core forms system. This will resolve a long-standing accessibility problem. In addition, we will improve UX at the same time. This issue supercedeswhich has been marked as duplicate but can be referenced for the previous discussion.
What is proposed?
Move form error messages to an inline location next to the form field and label. Example screenshot:
The $messages area at the top of the page will have a brief indication of the number of errors with links to each error'ed field. The full text of each error will be inline.
This design is "Case 3" that was discussed in a Form Error Design Wiki. The wiki page has many more screen mockups of form errors in different situations such as combined form elements and mobile sized displays.
User interface changes
Steps to reproduce:
- Pull 8.x head and apply path from #212
- Install Drupal
- Log in as user 1
- Go to Admin >> People (admin/people)
- Click 'Add user' (admin/people/create)
- Submit the form (note: firefox and chrome don't allow submission with empty required fields)
- See error when form reloads
Screenshot before applying #283 patch
Screenshot after applying #283 patch
In previous versions of Drupal, calling form_set_error() and form_error():
During validation would prevent submission, mark the offending element, and use drupal_set_message() to display an error message.
During submission would only use drupal_set_message() to display an error message, and the element would not be marked in any way.
In Drupal 8, calling form_set_error() and form_error() (now FormBuilderInterface::setErrorByName() or FormBuilderInterface::setError()) will only have an effect during validation.
Calling them during submission will do nothing. Those instances should be replaced by a drupal_set_message() call directly.
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,594 pass(es). |
[ View ]
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,452 pass(es). |
[ View ]