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 issue 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.
*) See Related / Child issues for crossed out parts.
- 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.
This issue involves accessibility, usability, all four themes, and the Form system, so there are a lot of stakeholders involved:
- Accessibility topic coordinators
- mgifford and jessebeach
- Bartik theme maintainers
- jensimmons and emma.maria
- Classy theme maintainers
- Officially none, however, mparker17 has been talking to mortendk and JohnAlbin for direction.
- Form system maintainers
- There are five, three of which are active in Drupal, and one who worked on this issue:
- Seven theme maintainer
- Stark theme maintainer
- User experience and usability topic coordinators
- yoroy and Bojhan
- Move form error messages next to the form field and label.
- Provide a brief indication of the number of errors with a link to each error in the messages area at the top of the page.
References and prior work
You should take a look at these before starting work:
- The Seven styleguide has a design for an error with a single form control, but not a design for a complex form control (e.g.: checkbox / radio group, fieldset, password confirm). See Related / Child issues
- emma.maria has indicated that she wants to see how Seven looks before proposing any changes to Bartik.
- mortendk has provided feedback on the styles for Classy in #388.
- The maintainer of the Stark theme has not yet provided any feedback on this issue.
Decide on a resolution
The resolution was "Case 3" from the Form Error Design Wiki.
Note this wiki page has many more screen mockups of form errors in different situations such as combined form elements and mobile sized displays.
Also note that we now move forward without error containers, because the design got this issue stuck for ages.
- The resolution was "Case 3" from the Form Error Design Wiki.
Style Seven's single-form-element errors Update Seven's styles to address the ugly-background-and-border problems by changing
border-color: #f9c9bf;, and changing the width of the border / border-radius as per #186 and #188.
Post screenshots for Seven so we can get a UX review. Get feedback from @Bojhan or another UX expert on whether the error on the imagefield reported in #435 is acceptable or not.Disussed with @LewisNyman Fix/Add inline errors for file/image fields. Fix errors showing up seperately for nested elements at the top of the page, they should become links. Get correct error link title for managed files, multiple value fields (and possibly others) Update tests Fix the styling of errors for textareas with formatting options. Get a general UX review from @Bojhan or another UX expert. Get feedback from Bartik theme maintainers and make appropriate changes. Migrate styles common to both Seven and Bartik back to the Form Subsystem.
- Get RTBC sign-off from all offical stakeholders.
Historic notes on compound-element errors
All compound-elements now have working inline errors.
- Some form elements consist of multiple controls. Additional problems with these elements will be handled in separate issues (see below). The ones we know of in Drupal core are:
- Checkbox groups
- Radiobutton groups
- Password-confirm widgets
- A number of people have expressed concern about the ugliness of errors in Seven, especially with the fact that there are big/multiple red borders.
- The current, ugly look and feel came out of the Form Error Design Wiki, case 3, which the resolution that the community chose to move forward with.
- emma.maria pointed out that comments #186 and #188 address the ugly-border problems making it thinner and using a lighter color.
The element styling with a red wrap went missing, but this actually makes it easier to move forward now.
- emma.maria has reached out to the designers who came up with the Seven Styleguide to ask for a design for this type of control.
- mparker17 has some other questions / concerns / considerations about compound-element errors. See Related / Child issues.
How to manually test this issue
8.0.xHEAD and apply the latest patch
- Install Drupal
- Log in as user 1
- Download and install dmsmidt's Errorstyle module from GitHub https://github.com/dmsmidt/errorstyle (forked from vijaycs85's original)
- Choose your preferred theme from
- Go to
- Submit the form
- See all the errors.
User interface changes
- Form error messages are displayed below to the form field.
- A brief indication of the number of errors, and a link to each error is displayed in the messages area at the top of the page
- In previous versions of Drupal, calling
- 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.
- During validation would prevent submission, mark the offending element, and use
- In Drupal 8, calling
FormBuilderInterface::setError()) will only have an effect during validation.
Calling them during submission will do nothing. Those instances should be replaced by a
Not all of the following people might have committed code yet, but have provided extremely helpful help:
- mparker17 for managing this issue a long time, patching and creating screenshots
- emma.maria who has been invaluable in helping to organize and co-ordinate this issue.
- vijaycs85 for throwing together and maintaining the errorstyle module to help test.
- YesCT who has been invaluable in helping to organize and co-ordinate this issue.
- dmsmidt for patching, creating a lot of screenshots and doing extensive testing and improving the test module
Related / Child issues
This issue supersedes, which has been marked as duplicate but can be referenced for the previous discussion.
It has been decided to move the following issues outside of the current scope you can ignore them while testing:
- Better style errors on fieldsets.
- Better style errors on radio / checkbox (groups).
- Determine if both a normal message and inline error message for AJAXified fields is a problem. See:
- Update the message at the top page when there are errors in an AJAXified field, related:
- Radios / Checkboxes focus styling wrong when marked as having an error
- Links to a CKeditor don't work because the original field is hidden
- All fields should have titles to be able to show error links / Title finding logic should also search for titles of parent elements. Related to:
- Discussion: UX improvement: Place inline errors before the field and after the label.
- Style Stark theme inline errors.
- What to do with form element errors without a message.
- Label "for" attribute and inline error link hash are wrong after a failed AJAX file upload.
- Fix inline-errors on image/file upload fields.
... however, they do not block this issue from being committed.
Before applying the patch:
After applying the patch:
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,206 pass(es).|
|FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,193 pass(es), 6 fail(s), and 0 exception(s).|
|FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,201 pass(es), 6 fail(s), and 0 exception(s).|