Form Error Design Wiki

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Let's use this wiki page to share and tweak proposed designs for accessible form field identification.

The issue queue discussion in issue #447816 comment #260 raised a lot of questions. Let's try to develop a design that handles all the cases discussed. Once we have consensus and the Accessibility and UX teams give feedback, we can then open a new issue with a more concise plan of action and roll patches. Let's get this done for D8!

Case 1: A simple, very short form

Screenshot mockup for case 1 (description below)

Description: The screenshot shows a "Request new password" form where the user has entered an e-mail address that is not recognized. So the $messages area at the top of the page shows the complete error text, "Sorry, name@site.com is not recognized as a username or e-mail address". Lower on the form, the 'Username or e-mail address' field is surrounded by a red box and text next to the label says, "Error (show)". The word 'show' is a link which shows the complete error text in place when activated.

Clicking the 'show' link displays the full error:
Screenshot mockup for case 1 with 'show' link activated

When the 'show' link is activated, the full error text is displayed in place next to the field label.

Case 2: A very long form

Top half of screenshot mockup for case 2 (description below)
Bottom half of screenshot mockup for case 2 (description below)

Description: The screenshot shows a very long "Site information" form where the 'Default 404 page' field has an error near the bottom of the form. As before, the $messages area at the top of the page shows the complete error text, "The page /path/to/404 is either invalid or you do not have access to it". Six fields down on the form, the 'Default 404 page' field is surrounded by a red box and text next to the label says, "Error (show)". As before, if that link were activated the full error text would be displayed in place.

Case 3: Multiple errors, some #required fields and other validation errors

Screenshot mockup for case 3 (description below)

Description: The screenshot shows the 'Add person' admin page submitted with 2 errors. The $messages area says, "2 Errors: E-mail address and Password". Each of those field names is a link to the field. Lower on the form each of those fields has a red box around it and an indication of the complete error is next to each field's label. So the 'E-mail address' field says "Error: E-mail address is required". The 'Password' field says "Error: The specified passwords do not match".

Case 4: AJAX/AHAH interaction operations

I suggest that we create a Drupal.formSetError() javascript function that can be called by client-side validation logic to set an error on and form field. It will add the markup including the full error message next to the field label. The UI for client-side validation will be indistinguishable for the user from server-side validation (other than the timing of when they see the error indication).

Case 5: Combined form elements (e.g., password confirmation widget)

As illustrated in Case 3 above, the error message text only appears once at the first occurrence. The same error should not be repeated on the 'Password' and 'Confirm password' fields or any multi-part form fields.

Case 6: Visually constrained forms (e.g., user login block)

Screenshot mockup for case 6 (description below)
Description: The screenshot shows the User login form in a block. The $messages area says, "Sorry, unrecognized username or password". The Username field has a red box and the error text that says, "Error (show)". As before, 'show' is a link to display the full error in place.

When the 'show' link is activated, the full error text is displayed in place next to the field label. This is especially helpful for visually-constrained forms or users working on a mobile device where the $messages area may be off-screen at the time:

Screenshot mockup for case 6 with 'show' link activated providing the full error message next to the field label

Case 7: Forms without connection to primary messages output area (e.g., forms in blocks)

Case 6 immediately above provides an example of this. A form in a block will still have a short textual error indication next to the field label. It will start out saying "Error (show)" and when the 'show' link is clicked the full error text is displayed. Users on a mobile device may use this error message and never see the $messages error because of layout placement determined by the theme.

Case 8: Form elements following a strict presentation standard (e.g., textarea, text-format-enhanced text area)

Screenshot mockup for case 8 (description below)

Description: Errors in textareas are treated the same way. As shown in the mockup above, a single error is reported at the top in the $messages and the field itself is surrounded by a red box and has "Error (show)" next to the label.

Case 9: Long form elements in height (scrolling the error message out of the viewport)

Screenshot mockup for case 9 (description below)

Description: When a field with an error is scrolled partly off the screen, the red box the whole way around it helps to give a visual clue for sighted users that the portion of the field they are seeing is a field with an error.

Comments

(feel free to click Edit and add your own comments or ideas to this wiki page)

AttachmentSize
error-color-mockup-1.png87.23 KB
error-color-mockup-1-show.png88.6 KB
error-color-mockup-2-top.png85.08 KB
error-color-mockup-2-bottom.png75.03 KB
error-color-mockup-3.png103.88 KB
error-color-mockup-6.png94.06 KB
error-color-mockup-6-show.png39.06 KB
error-color-mockup-8.png83.58 KB
error-color-mockup-9.png81.64 KB

Comments

Alternative: No errors in $messages, all errors inline

bowersox's picture

@Bojhan raised the idea of always placing the errors inline at the location of the field, and never listing out the full error text up in the $messages at the top of the page. Essentially the idea is to always apply "Case 3" from the post above. The $messages area would just have a count of the number of errors, while the actual error would be next to the field.

That is a worthy idea that we should seriously consider. Does anyone have arguments for or against this alternative?

[Update: To clarify, the $messages area would still have a count of the number of errors and a link to the field(s) with an error.]

I like this because I've seen

jmickela's picture

I like this because I've seen sites that just remove $messages from the template because you can't control what ends up there. Sure, you want form errors accessible to users, but you don't want site messages geared more for admins to be displayed, and right now you can't control that. It would be great to not have to worry about throwing out the baby with the bathwater by removing the display of $messages altogether.

I like that suggestion. It

yoroy's picture

I like that suggestion. It gives consistency and the approach for the $messages area is a good pattern, that scales well by only keeping count and providing jumplinks. This prevents flooding the top of the page with long error messages. Nice!

Always aiming for Case 3 first looks like a solid strategy to me. I'm sure there will be intracacies but as a guiding principle looks very sane.

tha_sun tweeted with another example

bowersox's picture

Daniel F. Kudwien @tha_sun tweeted:

Dude, nice inline form errors on @readability — #WANT for #Drupal core :) /cc @Bojhan @royscholten pic.twitter.com/lZULpTbo

screenshot showing an inline form error message cutely placed below the form field with an arrowing showing which field it applies to

Here is the tweet: https://twitter.com/#!/tha_sun/status/177095032329875456/photo/1

Further tweetage pointed out

yoroy's picture

Further tweetage pointed out the existing Inline Form Errors project: http://drupal.org/project/ife

ife

bowersox's picture

That module looks interesting too. Did anyone find screenshots of the "ife" module UI?

Great to spell out these examples.

mgifford's picture

Thanks for doing this work.

Couple things that probably should be explained.

1) How do we deal with vertical tabs (both when displayed & hidden)? I can see it being useful to highlight the stub on the right that contains the error or simply ensure that it's highlighted. Then there's the question of if there are two vertical tabs with errors.

2) What about with Views. It's an extreme case, but the error reporting should be able to be explained in terms of the views admin pages.

3) Mobile - not sure if there are any considerations here, but might be worth asking the mobile folks for how to optimize this for a small screen. What things should be thought of and what resources might be available.

Re: Great to spell out these examples.

bowersox's picture

1) Vertical tabs should indeed get an error indicator in the short summary text that appears on the tab. That way 2 or more tabs with errors can be found by users. Good point.

2) Views UI does not use core error reporting, as far as I know. It does use drupal_set_message() when you actually save the whole view, but otherwise all of the errors are AJAX-powered errors that are internal to the Views UI layout and powered by its own tools. So I think it's important for core to establish a good pattern that Views UI could choose to adopt later on.

3) Mobile themes and styles that come into core will need to adopt a nice presentation of errors. I believe this same approach of locating form errors inline at the site of the field (with a short message at the top of the page) will be a good thing for mobile experience.

Here's an example screenshot of an error message on a mobile device:
screenshot of a username and password login form with an error symbol and red error text right below the password field

Complex module examples

mgifford's picture

Seems like Views isn't a good example as they may well end up doing their own thing. I was mostly trying to put forward a complex Drupal form in a contrib module that may present challenges that some modules would have in managing the upgrade.

Trying to think of other UI elements to be considered...
Dates shouldn't be a problem. Same with radios/checkboxes.

What about hidden elements? Say HTML5's location. If you don't enable your location, but the location information is needed??

There might not be any good requirements here..

These look good for the most

EvanDonovan's picture

These look good for the most part; I like how so many different cases were considered. I agree that we should aim for Case #3 if at all possible. Case #1 just seems a bit redundant.

Was discussion of changing the error color from red to something else in scope for the original issue? I think there was a Development Seed theme that did that.

The only thing I would question is whether there is enough breathing space for the word "Error". Perhaps it shouldn't be inline with the form label, but go down to another line. Sorry that I'm not good enough at Photoshop to make a mockup of that alternative :)

Sounds like we've got

yoroy's picture

Sounds like we've got ourselves a direction to pursue here. To move this to implementation, I suggest opening a new issue for core, summarizing the conclusion we arrived at here (show only design 3, link to here if people want more background).

Bowersox, it would be great if you could do that initial writeup for the issue. Ping us in IRC if you want help, we'll start hunting for devs who can help with an implementation plan and or patch.

Great work in here, lets move this forward.

Feedback from Everett

bowersox's picture

At today's Accessibility Skype Meeting Everett Zufelt gave some helpful feedback on how this should be coded in markup.

Everett suggested that ideally we want the link at the top of the page (in messages) to take users to the field label first, and then have the error message next, and then have the field. That would be the ideal in the HTML source code order and in terms of where the link would land.

The ARIA Described-By value could include the element that wraps the error message. That way the form element would be semantically connected with its error message. ARIA Described-By can take one or many ID values. Of course one of those values might be the field label itself, or the field description/instructions. But in addition to that we can add the error message as another Described-By value. That way the set of Described-By elements would read the Label, the Error and the Description in that order.

(Everett or others, feel free to correct me if I've missed anything in my summary.)

New issue

bowersox's picture

A new issue for core has been opened, as Roy suggested:
http://drupal.org/node/1493324

Let's implement this!

Accessibility

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week