WCAG violation: Relying on a color by itself to indicate a field validation error

This is for the form system, not field API.

Just as an additional detail, the red color is set in css via the system.css file.

.form-item input.error, .form-item textarea.error, .form-item select.error { border:2px solid red;}

Sorry we posted at the same time which reset it back, so I reset it again below to forms system. Sorry that was where I originally meant it to be.

hi.

I agree on the inaccessibility of conveying information only by color change. a big plus to that.

Just another thought that we could use drupal's form api to do the validation without needing to add in the jQuery validation plugin, but then I think we would have to make the Form API a little more robust to handle that case.

This is definitely a serious accessibility concern, however, from my knowledge of the forms API the solution will not be simple. As I understand it the current workflow is that during validation the class for the form field (label) is set to "error".

This provides themers an opportunity to visually style the form label, but does not provide for additional non-visual markup to be applied that would provide any indication to assistive technology users that their input was invalid.

I believe that providing the functionality to semantically mark a field as having invalid data should be a core functionality which should be handled at the point of the form being rendered into a markup language.

I currently do not have any recommendations for exactly how this should be best accomplished, if someone can point me to an overview of the forms API workflow then I can do some additional research and brainstorming.

This is an interesting issue - I think that (at least in Drupal core) form errors are always described by an error notification message at the top of the page, so for example with a password error you get the message "Sorry, unrecognized username or password. Have you forgotten your password?".

Of course, this does not always make it clear enough which field (or fields) the error concerns, hence the red border - and of course this information is not available to screen readers (and probably some people with low vision). I would suggest that we add markup to the form as part of the default form element theming (not via javascript). This should be straightforward enough - the question is what should this be, and where.

My sense is that the word "error" would be sufficient if we linked it to an anchor for the notification message that added it (for bonus points we could somehow emphasize the message when you follow this link, so that it is clearer if there happen to be several messages). My sense is that by default placement of the word "error" could be above the form item, or perhaps to the right of it. To the left would probably cause indentation issues, although perhaps we could experiment.

Are there any other projects besides jQuery's validation project which have done accessible form errors? What's worked for them?

I like the idea of using a link in the error message to allow users to easily jump to the invalid field. It may be helpful to also provide more information about what input is expected.

However, it is also necessary that the message container be easily identified by users, see #290343: Add icons to status messages., and #515236: theme_status_messages needs additional markup to be more apparent to assistive technology users.

Resources:

G85: Providing a text description when user input falls outside the required format or values | Techniques for WCAG 2.0
- http://www.w3.org/TR/WCAG-TECHS/G85.html

Curious, why do the required fields have to indicated? When I go to fill out a form (say, for renting a car), I assume I have to fill out all fields and expect to be told what is optional. Why don't we indicate optional fields instead of required?

+1

@Everett I agree that semantically marking fields as having an error should be part of core, in addition to just changing their class.

This is what Drupal 6 currently does for a required Title field that was left blank (it adds a class=error):

Here is one way to add an error into the label to make it more accessible:

An additional recommendation from our accessibility evaluation of Drupal 6 was to provide error messages at the top of the page in an ordered list and link them to the form fields where each error occurred. It was also recommended to precede that top error with an h2 heading such as <h2>Error</h2>.

Here is a small patch and screenshot which may help make the form_set_error() messages more accessible. I realise this doesn't address the other details brought up in this issue, and only intend it to be a part of the solution that is figured out here. Feedback?

edit: This conflicts with the toolbar module. This is a bug with Toolbar in my opinion, and I've filed a bug against it at #546126: Toolbar interferes with anchor links.

@brianV

Yes, I support the idea of links in the messages to each field with an error. I believe the anchors that you are linked to are not currently created. So part of this patch would need to be the code to create the anchors (eg, <a name="edit-field-id"></a>). That would be an addition to theme_form_element() inside includes/form.inc.

Does that fit with your plans? Thanks for this important addition.

@brandonojc

Can you clarify what you mean by 'the anchors that you are linked to are not currently created'?

The links point to the form element ids that the error is tied to. For instance, the 'Email Address' form element in the above screenshot has the ID of edit-site-mail:

The anchor link generated in the patch points to the ID for the form elements they are tied to.

@brianV

Yes, you're correct. The links work perfectly.

One possible hurdle: drupal_set_message() requires that $message begin with a capital letter and basically be a brief sentence without HTML inside. So I don't know whether this patch would be accepted. Anybody know?

I think this is a very valuable usability feature. We should find a way to make it happen. There are currently 267 calls to drupal_set_message() in core and many more in contrib, so let's not change the drupal_set_message API. Maybe we can simply get agreement on allowing the message itself to contain HTML with links. You might want to open a new issue just for this. I'm interested in doing what I can to help.

@brianV

Turns out roughly 20 drupal_set_message() calls in core actually contain a link. Here's an example from modules/system/system.admin.inc:

Grep helped find them (grep -ri "drupal_set_message.*href=" .). They all do start with a capital letter and end with a period.

Here's a suggested patch and a screenshot. I'd appreciate feedback. A few notes:

• The text that appears in $messages stays the same, but the field name becomes a link.
• Translations should use '<a href="!field_id">!name</a> field is required.' in place of '!name field is required.'.
• Usability could be further improved later with a javascript enhancement to put .focus() onto the target field rather than simply scroll to it.

Setting to Needs Review to run the patch through testbot.

The last submitted patch failed testing.

Please review this updated patch. It is the same as before in 17, but it modifies the corresponding tests to use assertText() instead of assertRaw(). This is because the message now contains markup, but please let me know if another approach is better.

I would love to get a list of 1-3 forms that are considered to be great references in the accessibility world, and that work and look stunning for other people too. Instead of inventing solutions, I'd also like to see what others are doing and if we can learn from them.

Personally, I'd think these links in a dsm() are a pain. If you failed to fill out 5 fields correctly, the user would have to go back to the top of the page after every form field, to figure out the next form field that was wrong. There should be better solutions so I'm tempted to mark this 'needs work'.

@Dries

G139: Creating a mechanism that allows users to jump to errors | Techniques for WCAG 2.0

The objective of this technique is to help users find input errors where the information supplied by the user is not accepted. This includes fields with
missing required information and fields with incorrect information. When users enter data input that is checked, and input errors are detected, a link
to that error is provided so that the user does not have to search for it. One approach is to use server-side validation, and to re-display the form (including
any previously entered data), and a text description at the top of the page that indicates the fact that there was an input error, describes the nature
of the problem, and provides a link the field(s) with a problem.

@Dries and @Everett

Here's an example of a form that uses best practices:
http://collaborate.athenpro.org/accounts/register/

Try submitting the form without the required fields filled out. The error message contains links to each of the effected fields. It uses Javascript to put the focus inside of each field. We could do that in Drupal as an enhancement for users with Javascript. For users without Javascript, the normal anchor link as shown in patch 20 would still be used.

Note that the example has a visual display for sighted users that is not as nice as Drupal's, so we would of course retain Drupal's good looks.

(P.S. Regarding h1 and h3, I asked why this form uses h3 on the error message when it follows h1 and they said this was actually an error per the W3C WCAG that there are going to work on fixing.)

That's a very nice example. Great that you can just click on the error and get right to the form element in question. Think that this is something that will benefit all users!

+1

Two functions worth investigating for further improvements to form validation accessibility are form_error() and form_set_error().

Also, all elements with an error should have their #error property set to TRUE.

The last submitted patch failed testing.

Please review this new patch. It now includes:

• Each form field gets its error message added into its label in a <span class="error">.
• The display looks good in Seven, Garland/Minnelli and Stark.
• Plus of course the functionality from above of linking to required form fields within the errors.

Let me know if you have any suggestions or feedback. This could be a big accessibility improvement for Drupal 7, and I'll do whatever I can to get this working in time.

Here are screenshots of how the form errors appear visually in Seven and Garland too!

Wow, I think this looks wonderful! I think this is (as is common) a significant usability enhancement, in addition to being an accessibility enhancement.

I have added a tag to request review from one of the UX guys, just in case there is something we might be missing here, but otherwise I think we are on a great track here.

Ok, I di really like this patch.

It applies well and I've got it up here with other accessibility patches for testing http://drupal7.dev.openconcept.ca/

Problem I found with Seven is that if you click on it you go too far. You click on the title and believe you're going to the form element, but it's under the menu bar on the top.

Pictures attached.

@brandon

I'm not sure if the checkbox, radio and fieldset form elements can have their #error property set to TRUE, but, if they can, this patch will need to modify theme_fieldset, theme_radio and theme_checkbox in the same way that it has modified theme_form_element.

hello.

I love the patch. it works very nicely on the test site above. this has to go to core asap. very nice solution indeed! tried with a screen reader, of course.

thanks
Mohammed,

@mgifford

Regarding things scrolling under the Seven toolbar, that is a problem elsewhere in Seven with other things that scroll into view. After this patch is in I would like to refine this with a Javascript enhancement by actually using .focus() so that the cursor goes inside the relevant form fields which will help.

@Everett

You are correct that this patch only adds nice visual error messages for elements that use theme_form_element(). In a future patch I would be interested in doing the same with theme_fieldset, theme_radio and theme_checkbox.

Thanks for all the feedback!

@mgifford

I filed an issue about this some time ago #546126: Toolbar interferes with anchor links.

Feel free to comment on it / exand it if you have more to contribute. I think that this is going to be a real problem with Seven.

This is looking good to me on http://drupal7.dev.openconcept.ca

Sorry, I find it somewhat strange that is is marked RTBC - when nothing of Dries his concern rightfully so, has been addressed.

Do we really want to follow G139 in this case? I am not sure, it impacts the UI considerably and I hoped we didn't have to do that. If we chose to go down the path, adding stuff to the UI for every accessibility issue, its going to be though to review this.

@Bojhan

I feel like Dries' concerns and questions were addressed. He asked to see references and good examples of this technique, and he pointed out that sighted users like himself would not find the links useful. The community responded by providing the W3C WCAG guidelines explicitly recommending these links, and by providing a working example of other software using this best practice. In the end, I believe the visual indicators in this patch will benefit all users, while the links themselves will primarily benefit assistive technology users.

@bojhan

Can you point out a concern that Dries had that was not addressed in the comments?

Also, not every accessibility issue requires a change to the UI, but some do. I see the UI change as worthwhile if it means that a greater number of users will be able to comfortably consume the information on a drupal site.

Dries comment applies equally to the status quo:

Personally, I'd think these links in a dsm() are a pain. If you failed to fill out 5 fields correctly, the user would have to go back to the top of the page after every form field, to figure out the next form field that was wrong.

Lets look at the current user experience here (assuming a long form and non-trivial error messages):
1. Read an error message from top of page.
2. Scroll down the page until you find a form field that has a red border.
3. Fix the issue.
4. Scroll back up to top for the next error.
5. Go to 1 and repeat.

This patch improves on this in several areas - you still get a summary of the errors at the top of the page, and you still get for items with a red border. However, you can now click on links to get directly to the form field with an error, rather than having to scroll up and down the page trying to figure out which form field that error applies to (difficult if there are many errors and/or similarly named fields).

In addition you actually get the error messages next to each form field, so you don't need to remember the error message you read previously (which is off-screen on long forms) and can also proceed directly down the page after fixing an error, rather than having to scroll up each time as you do now. This was not present in the patch that Dries looked at and directly addresses his second point.

Hence, I think this patch addresses Dries issue directly, because this is an issue with our current interface and is improved by this patch.

In general, I think this is a good idea. The only thing I'm uncertain about is the duplication of the error messages. I wonder if we should have a single, generic message at the top, but present the details errors next to the individual form elements? Would that still be helpful?

@Dries

Maybe we can get some usability input on that question. It would theoretically be possible to say "3 form fields have errors" at the top and have the detailed errors next to each field. That might be harder to code reliably because some parts of the form might set an error but don't provide a visual display of the error (including fieldset, checkbox, and radio).

Personally I could imagine some users who would want to see the detailed errors both places, so they could look in the red box at the top and succinctly see what all the problems are without scrolling. Whatever we end up deciding, I think this is an important advancement for accessibility and usability.

-1 for "3 form fields have errors"

I like to know which errors they have, that way, i know beforehand how much time it is going to cost me to do it again. (was it a mistake i made, or was it the captcha again??? do i need to re-enter my password??? is my name already taken and need i think of another one??? didn't it accept my SVG image???)

if you say "3 form fields have errors" the first question you ask is "which ones?" and "why do scroll trough the form to know which ones?"

@Dries

I think that it is valuable to have an explanation of the errors all in one place, and agree with the reasons given in comments #41 and #42 regarding this. I don't see a problem with repeating error messages once in summary and once with each field that has an error.

@Dries

I'm for leaving the patch as it is. I do think it may look a bit unusual when you've got a short form (like the login form for instance). However, for longer forms I can see it being critical to be able to see a summary on the top of the page and then individual messages near the fields with the errors.

I suppose one could create an form attribute to display the errors in an alternate way for shorter forms, but not sure it would give you much in terms of extra usability.

+1 I like the patch. I'm going to run it by our accessibility team to see what they think of it. I'm really happy to see all the work behind this, and disappointed that I have been working out at sea for the past three months and thus wasn't able to join in on it.

I asked my mom, who has a Phd in English. Her response was:

View unpublished content. The subject is understood as "You."

Also, waiting on response from accessibility team.

Sounds like this still needs review.

@anarchman, did you mean that you are waiting on feedback from an accessibility team in your organization? If so, can they send feedback in the next few days?

I'm trying to understand why this is tagged as awaiting accessibility review. In comments #27-35 we got a variety of feedback and positive agreement from users with screenreaders and different tools. Accessibility-wise, this patch is a big step forward for form error feedback.

Yes, waiting on feedback from them, but I personally agree with the patch as is, and I think they will too, so I see no reason not to commit, I just want to add a more 'weighty' opinion. I'm setting back to Reviewed & Tested and will add the feedback when it comes. Please feel free to change back if others feel this needs more eyes/review.

Okay, sounds good. We can always accept any more feedback and input if others have ideas...I think most people will find this is a big step forward.

The last submitted patch failed testing.

There are 2 exceptions that suddenly popped up in tests for "Content language settings" and "Translation functionality". Does anyone know if this was a temporary unrelated problem or if there's truly anything wrong?

Switched to 'needs review' to see if the bot gives the same result on re-test.

In my testing of this patch http://drupal.org/node/447816#comment-1979412 I wasn't able to duplicate the exceptions the bot was complaining about. So hopefully a retest is all that's required.

Would be great to get this in core though so that there is less fuzz about.

@mgifford Okay, I just requested a retest from the bot. I totally agree about the fuzz.

Setting back to RTBC. The same patch (above in #27) passes the bot again. I believe the errors were temporary and unrelated.

Coding style errors: else and else if need to start on a new line.

Cleaned up the fuzz, added the line breaks and re-uploaded the patch.

Sorry we busted the style guide. Old habits.

This newest patch looks good to me too. Thanks, Dries and mgifford, for catching that and making it better.

This was first RTBC now over two months ago. - Bump!

Um. You want to special case if ($element['#type'] == 'password' && $element['#name'] == 'pass[pass1]') this into theme_form_element ?????? That's a big big no. Can't you instead introduce a generic property and set it in the password element process function?

Please review the updated patch. It is identical to the prior patch but it removes 3 lines of code for the special case that @chx mentioned.

@chx, I agree. Thanks for reviewing this and pointing this out. I hope you get a chance to review this again and also take a look at the other handful of accessibility patches that have been RTBC for a while.

What is the impact of removing the special case? The original idea of the special case was that with password fields, which have a pass1 and pass2 for users to type the password twice, we would suppress display of errors on pass1 because often the same error is also set on pass2 (eg, "The specified passwords do not match.") Now that this special case is removed, we will simply display the respective errors for pass1 and pass2 as normal, even if sometimes the errors are the same.

I considered ways to use a generic property to otherwise suppress errors on pass1, but no good API for that exists. The form element labeling issue, #558928: Form element labeling is inconsistent, inflexible and bad for accessibility, might change that some day. But even so, it is probably better to display any errors on either password field. Because if the passwords don't match, it is just as likely that the first is mis-typed as the second. Similarly, if the passwords are too weak to be acceptable, the user will want to change the first and the second. So actually from a usability and accessibility perspective I believe it is better to simply show these errors in either case.

There was a change I think in form.inc that affects this patch that caused it to fail when I applied it.

Just rerolled it against the latest CVS.

Works fine on my local install. Just have the outstanding questions raised by @brandonojc to @chx that would be good to get addressed before I'd be fine with this being RTBC again.

The last submitted patch failed testing.

Bad bot?

@mgifford, I think it was just a bad bot. Let's try again. Just for good measure I re-rolled. This patch is exactly the same but applies more cleanly (without a hunk offset -18 lines).

The last submitted patch failed testing.

It appears this patch is not compatible with #582584: Move required form element marker into its own theme function. Is anyone familiar with what changes we'll need to make?

Yup. patch applied nicely.

Local tests of the Required field validation within the Form API in Simpletest worked just fine too.

bad, bad bot!

Please review this updated patch.

The only change is a 2-character tweak to a new test that was introduced by #582584: Move required form element marker into its own theme function in modules/simpletest/tests/form.test:

We need the added .* because our patch adds new markup after the span class=form-required but before the </label>. This one change fixes the 37 failing tests because this preg string is used inside a loop for multiple tests.

No idea why when trying the prior patch in comment #68 it worked for me. Thanks for catching is and re-rolling the patch.

This one works well and the bot likes it.

Rolling this back to RTBC and giving a +1 to #69

+2 let's get this in!

I was slightly lost with the current title (which was quickly remedied by the crystal clear intro to the issue!). Thanks for working on this!

For those coming late into this issue, there are screenshots at at #28 that show how various screens look when there's a validation error of some kind. When displaying a form initially, without any validation error, it's exactly the same as before; just a red star next to a field to indicate its requiredness. Overall, this looks like a massive improvement, both for blind and sighted users.

The one exception to the screenshots above is the password validation which, because the special-casing in theme_element() was removed per chx (rightly so), now looks like this: http://img.skitch.com/20091108-qakwq32395emmdiba9j6iq4hr9.png Which... ick. :)

I hate to hold up a patch on a cosmetic issue like this, but I think this is more than a cosmetic issue. '#type' => 'password' is just one example of a field that gets expanded into multiple fields through the Form API. Contrib could also make one that is '#type' => 'address' which is a combination of between 5-7 fields, depending on configuration options. "State is not valid" x 5-7 fields would not be remotely pretty, and would also be bad for accessibility, from what I can see.

Brandon, could you clarify what you mean by "I considered ways to use a generic property to otherwise suppress errors on pass1, but no good API for that exists."? It seems to me as though we need to make modifications if that's true. As chx pointed out in #60, this should be a simple change, or at least it would seem so on the surface. Maybe ping one of the smarties in IRC like chx or DamZ or sun and see if you can work through this.

My second question is what happens if a field ends up with multiple errors about it? For example, it's both too short and not a number? Is everything smooshed together on one line next to the field, or does it get displayed above it in a bulleted list, or..?

Can anyone explain me, why we need two indicators?

@webchick: It appears the patch in 69 was committed by Dries: http://drupal.org/cvs?commit=285916. So I'll address the questions posed and roll a follow-up patch to improve the password fields as suggested.

Re: @webchick #73 question 1) You are totally right about the "ick" factor. In the follow-up patch attached I've introduced a new form property #no_error_label. It is used by theme_form_element to skip adding the error message inside the label for that element. So to get rid of the duplicate "ick" we change form_process_password_confirm() to set #no_error_label=TRUE for pass2 but not pass1. That is safe because pass1 and pass2 both have errors set in password_confirm_validate(). I think this accomplishes what you want and I've attached an updated screenshot for comparison.

Re: @webchick #73 question 2) It appears that form_set_error() only allows 1 error message to be set on any single field. The if (!isset($form[$name])) test means only the first error is really set. Let me know if I misunderstood or if you know of an example of two errors set on one field.

@Bojhan: The best explanation was from @grugnog in #39 and by #44 it looked like most people felt that displaying the error in this location would be helpful for both accessibility and usability.

I'm pretty sure this patch addresses the concerns of the previous reviewers. I've confirmed that it works with the password error & added in a screen-shot with multiple fields with missing required data.

So I'm setting it back to RTBC.

In the screenshot, edit summary seems to be glued to the error message.

This needs a little bit more work.

From the original patch (in #69):

Could we please fix that? The code flow is ugly, there are unneeded repetitions of HTML code and form_get_error() is called twice on the same line?

Re: @webchick #73 question 1) You are totally right about the "ick" factor. In the follow-up patch attached I've introduced a new form property #no_error_label. It is used by theme_form_element to skip adding the error message inside the label for that element. So to get rid of the duplicate "ick" we change form_process_password_confirm() to set #no_error_label=TRUE for pass2 but not pass1. That is safe because pass1 and pass2 both have errors set in password_confirm_validate(). I think this accomplishes what you want and I've attached an updated screenshot for comparison.

No, password_confirm_validate() only sets the error for the parent field, but because of a logic block that I don't understand (and is undocumented) in form_get_error(), this error also apply to the childs because the password element you are testing this with is top level. This doesn't seem like the intended behavior. It should be the job of the password element to choose where to output the error (by calling form_error() on the correct field).

As such, #no_error_label seems completely unnecessary to me.

I'm new to this thread. I'm not sure how this pattern of linking to the form field from the error message can be applied to Field API.

Field values are validated, and error messages generated, in hook_field_validate(). This function explicitly doesn't assume a Form context (to allow validation during programmatic save). At this point, we have no form or elements ids, and we want no links in the message. The errors and messages are then passed to widgets, that simply tag the error on the right form element in their hook_field_widget_error().

This just doesn't look right on fields in blocks.

As an example (in the attached screenshot), I entered an invalid password in the login block. The result was a relatively large wall of text above the password field.

Perhaps it's just me, but the aesthetics of this are horrible. I don't have a better solution, but this is just bad!

@brianV: Good point. I can't think of an easy clean solution because theme_form_element() doesn't know if the element will end up rendered in a block.

There could be a CSS solution like this:

(In other words, with CSS we could hide the form errors from appearing within a block.)

Ok, I think this patch incorporates a space to address the issue that @Dries pointed out, Reduces the repetition in function calls identified by @Damien Tournoud and pulls in @brandonojc's patch at #75 & suggested CSS at #81

Not sure how to deal with @yched's concerns. By centralizing the error messages here it would seem to me that we'd be introducing the least amount of code. Introducing it later might be possible would would require a bunch of duplication I would think.

Drat, want the bot to check it.

This is clearly a wrong commit, can't see that - it wasn't rerolled already.

Please remove the error next to the label, I do not see any reason to do this. After reading all the arguments it seems like we are choosing to go for no trade-off because we can't make a decision (so we do it both?). Lets keep it at the messages on top, it should be fine. Within the ascetics of Garland or Seven, this really doesn't fit well.

I understand the UX arguments that http://drupal.org/node/447816#comment-1985400 outlines, but that really favors one approach over the other and does not include the ascetic arguments. It assumes a whole lot about user behavior and cognition which doesn't correlate to any user research I have done on forms, sure it reduces the cognitive load somewhat - but it also creates a whole lot of ascetic in-balance.

I think - we need to roll this back, so that we can put people to find a proper design solution.

Oops, I committed this by accident indeed. I was testing this patch, got distracted, and forgot to undo the patch before starting to review the next patch. Rolled back until we figured out a better solution.

@Bojhan, do you have any better usability suggestions to convey more than color to indicate field validation errors?

I just want to see that this important accessibility issue keeps moving forward. Usability is important but if this idea isn't good enough we need to start brainstorming alternatives that work.

Just taking an unpracticed stab at this, but as a user, I would have liked to see:

1) A detailed, linked list of errors at the top
2) Next to each field, a graphic element or a textual sign (like "?") that, upon clicking, toggles the complete error message next to the field.

Another option would be to have the by-the-field error as a tooltip - since this issue targets screen readers etc., won't that get read out loud and solve the problem?

So to set the scope of this issue right, there are two things we want to achieve.

1. Set a error message at top [already completed]
2. Provide error indicator per field

Can we perhaps already move on 1. and or provide more examples of other sites on 2?

A few examples of error indicators on sites that were designed to be accessible (screenshots attached):

CNIB Contact Us Form - errors follow each field, none at top

1. Browse to http://www.cnib.ca/en/contact/Default.aspx
2. Click Send Message button without filling out any fields (you must have Javascript enabled)
3. Error: each field has a red error explanation appended, nothing at the top of the form (see screenshot)

CNIB (Canadian National Institute for the Blind) is where Drupal's own @EverettZufelt works.

NFB Donate Form - errors follow each field, with one error notice at top

1. Browse to http://tinyurl.com/yfrkrpp (or start at www.nfb.org, click Give, then click Donate)
2. Click Submit without filling out any fields
3. Error: each field has a red explanation appended, and one message at the top signals errors (see screenshot)

AFB Donate Form - each field gets a star (*) to signal an error, with a list of all errors at top of form

1. Browse to https://www.afb.org/credit_card.asp
2. Click Continue without filling out any fields
3. Error: each error field is marked with an asterisk (*), and the top of the form has a list of all errors (see screenshot)

I haven't seen an example of errors that use tooltips. None of these are aesthetically great, so I think Drupal can do better and balance accessibility and usable interface design.

Attached are screenshots from Wordpress and Joomla. Both of them simply list all the errors at the top and do not flag the effected fields.

This probably makes Wordpress and Joomla less usable in addition to being less accessible.

So this is an opportunity for Drupal to top Wordpress and Joomla--to be an accessibility leader, to build sites that millions more people can access, and to comply with accessibility laws that will allow Drupal to be adopted by the public sector.

Please review this updated patch. It creates an error indicator "!" that has a tool-tip containing the error message. I have removed the on-screen error message.

The patch makes theme_form_error_marker() theme-able, so folks can override for their own tastes. For example, they could choose to display the errors on screen like earlier patches did.

I've included screenshots of a few scenarios: errors in a block, errors on a long form, errors on required and non-required fields, etc.

I've tried to strike a balance for accessibility, usability and aesthetics. I'd appreciate further feedback so we can form a consensus and get this back to RTBC.

That patch is ready for review.

@valante: Tool-tips are ignored by many screen readers, but they are great for sighted users to reduce visual clutter. So in this patch I've made the error both a tool-tip for sighted users and invisible text for screen readers. I welcome feedback and input from other accessibility advocates on this approach.

I think you nailed the "reduce visual clutter", and the invisible text for screen readers sounds like a great solution.

The only thing I would change is the exclamation point - I wouldn't think to point my mouse there for more details. Maybe something like "show error", "what's wrong", "details", "why?" - anything that would make the user think he's supposed to click there, which will subsequently make the tooltip pop up.

@brandonojc Again, what are the best practices on the web? I am really astranged that - we are solving this problem in such a exceptionable way.

@Bojhan: Check out the examples in #89 that use best practices by either providing a full error message next to each field or a visual symbol. The 3rd example there uses asterisk (*) but we already use that to signify required fields. I'm curious if you have suggestions besides "!".

In addition, here are W3C WCAG 2.0 requirements and examples: How to Meet WCAG - Techniques for Error Identification. WCAG requires that we identify an error field and describe the error in text. This text can be at the top of the form, in which case they recommend links to the errors. (The patch at #91 adds links for required fields and in the future we could do so for other fields too although there are technical reasons that will be harder). WCAG says it is a failure to identify errors using color only. Finally, WCAG provides one example where validation adds links to erroneous fields. (See the description).

Also, check out this Section 508 for error example. It uses error messages at the top with links plus a red asterisk indicator (*) added next to error fields. (508 is the U.S. federal accessibility law).

In summary, the newest patch falls between the best practices from #89 and the WCAG requirements. It seems to accomplish what we talked about in #87-88:

1. Setting detailed error messages at the top, with links when possible
2. Providing a minimal error indicator per field.

mgifford requested that failed test be re-tested.

@brandonojc - thanks again for all of your work on this. Providing all of these examples, patches & consideration is really important.

I do think that the patch is going to have to get re-rolled. includes/form.inc is a bit of a moving target.

@Bojhan - what is exceptional about this? Best practices on the web are defined in WCAG 2.0 which is still less than a year old. It's taking some time to roll out into the community, but @brandonojc's examples are quite solid.

a big fat -1 on tooltips for this!!!

first of all - I'm severly against using ! together with hover (how about non-mouse users?)
I don't want to do an additional step to get my error information

what i prefer is that we get back to something similar to the screenshots in #28.

the * are actually subtle pre-submission hints, while the full texts are clear post-submission indications.

there is no need to provide links to the element when the error is specified at the element itself.

Let's try to keep kittens alive, and lets only focus on the following for now:
- For Full page forms: Error Message at the top of the page, and at the top of the specific form element.
- For Block Forms: Error Message at the top of the page, and (at least) at the top of the form inside the block.

By only using the correct text we can probaly meet the WCAG guidelines.
(don't forget to test all solutions with CSS & JS completely disabled!)

(The duplication of the error message between the generic (top) area and the context is not a problem, but might possibly even desired, read also my comment in #42)

I have to test out applying this latest patch once we have it re-rolled correctly, but it looks like the current patch has moved far away from where we were previously in terms of UI, and I'm not sure that is a good thing.

@Bojhan, "best practices" aren't yet on the Web. However, if you were to attend accessibility conferences such as Access University in Austin, Texas, each May or Accessing Higher Ground in Boulder, Colorado, each November, you would hear users and researchers lamenting the widespread poor practices that this patch is trying to correct.

In his books and website, Edward Tufte teaches the fundamental value of placing instructions at the point of need. In this case, there are two different classes of "points of need":

• At the top of the display, the user needs to know that there are errors and where to find them.
• Next to each field that contains an error, the user needs to know what the error is and how to correct it.

This is basic human-factors-based design. When the humans using the interface cannot easily observe the whole screen — perhaps because they're having to rely on a screen reader; perhaps because they're having to rely on a screen magnifier; perhaps because they're having to fix their Drupal site from their smart phone — this fundamental of good design becomes a pillar of accessibility.

Instructions at the top alone are good enough for most of us. But they're not good enough for those of us who most need the Web to gain access to commerce, culture, and everyday communication.

@Brandon, I would suggest that we make the link to the error with something more obvious than an exclamation point. I've seen too many users never notice such a flag, let alone realize what it meant. "What to fix" would be concise in English; "How to fix" might also work. "Help me!" is another possibility. Of course, those words would have to link to the full explanation of how to fix the problem.

I'll look back at this more carefully when I actually have some time and see if I can come up with suggestions that are more helpful.

Fixing the title. Minor, but important point: It isn't that color is used that is the problem. The problem is that color is the only indication.

Just keeping up with head.

Patch in #91 is a very flexible solution. Might just be the compromise between usability & accessibility that we need.

The last submitted patch failed testing.

Okay, reviewing the latest patch for usability and accessibility: As shown in the screenshot below, we could improve upon the design, but the general idea is good. The improvements needed are:

1. Make sure the error statements at the top don't push the content down the page. Perhaps it would be best to simply list the fields where errors were found. In this screenshot, there is only one error, but if there were three, the message at the top should be: "Fix errors in Title, Address, and Wombat." (Ideally, the name of each field could link to that location.)
2. Make sure the color pairs offer good contrast. In this screenshot, "Title" is almost invisible in the error message at the top of the page. Red background + blue text means a contrast ratio of 1.6:1, which is way too low for accessibility.
3. List each full error message right next to the corresponding field — "next to" means "above" or "to the left" ("to the right" for RTL languages).

This way, at the top of the page, the user will find out which fields need attention. As they focus on each field, they will have the full error message right there. This is of particular benefit to people using screen readers, people using screen magnifiers, and people with cognitive disabilities.

As for other screenshots of patches being implemented:

• In #91, the exclamation point alone is not a clear indication that there is an error in that field. Also, the tooltip approach is not a bad idea, but it can't be allowed to obscure the corresponding input field.
• In #76, the positioning is not too bad. Fix the color contrast and simply list the fields with errors at the top of the page and this would be okay.
• In #29, the setup is similar to that of #76. Improve the contrast and simply list at the top of the page the fields that include errors.

As for screenshots that show how other online forms present error messages:

• In #89:
  • The CNIB form shows the error message after the corresponding field. In fact, it usually looks like the error message applies to the next field. This is a usability and accessibility failure.
  • The NFB form is better because the error messages are closer to the corresponding fields. But it would be better still if each error message appeared before its corresponding field.
  • The AFB form is laughably bad. It's next to impossible to recognize the names of the fields in the condensed list at the top, and there is nothing down the form to show where the errors occurred or to give tips on fixing them.
• In #90:
  • The WordPress error statements are the second worst in the whole bunch. Each statement is too far from its corresponding field, and the statements are out of sequence with respect to the fields. I can see perfectly well, and I can see all the error messages and the corresponding fields on the same screen, but it's a lot of work to figure out which error message goes with which field and what I can do to fix it.
  • In Joomla!, the error statement is too far from the corresponding field. With all the bands of color, the message also gets lost, as if it's part of the page frame.

Drupal can — and should — work better than any of those other examples. The patches are remarkably close to the way it should be for the sake of both usability and accessibility.

Oops — I didn't mean to change status, but I did mean to remove the issue tags for accessibility and usability.

I'm realizing that the fact that we all disagree is a good reason to make it theme-able which this patch does. We'll never all agree, but at least we'll each be able to theme it as desired for our own site.

@Cliff: #1) Regarding shortening the error messages at the top, we would only want to do that if the full error text is visible on screen next to the fields. If the field error message is a tool-tip or requires a click, I would be worried that truncating the top error message would mean some users couldn't find the error at all. I'm guessing 90% of the time users get errors, they get 1 error. Maybe 5% of the time they get 2 errors, and 5% of the time they get 3 or more errors. So if we go with the tool-tip or click approach, I don't think we should truncate the errors at the top. Whereas if we go with your suggestion (#3) of putting the full error next to the field, then we could also shorten the errors at the top as you suggest.

@Cliff: #2) Regarding the issue of the blue links on red background, we could add trivial CSS to make links within the error box white instead of blue. It might be better aesthetically (less jarring) and more readable. Do you like that solution?

Thanks for all the input and feedback, everyone!

I think this will get past the bots. It doesn't include a change in the blue links noted in #106. No problem with it, but just wanted to focus on the bot for this patch and wait to hear back from @Cliff

Please review this updated approach (thanks to @webchick for strategy advice on IRC).

This patch does the following:

1. Creates theme_form_error_marker() so we can all theme this how we prefer.
2. By default, adds invisible error text in the label of fields with an error. It is not visible by default and we also don't use the tool-tip approach by default. We won't all agree about which indicator we prefer, which is why this patch makes it theme-able.
3. Puts a class error-marker on that error text to allow anyone to style it to be visible, if they prefer.
4. For required fields left empty, puts a link in the error message at the top of the form to help users find the erroneous field.
5. For Seven, styles links inside error messages as white-on-red instead of blue-on-red. Adds an underline so there is a visual indication of the link. Garland has a light pink background so it is legible as-is.

Screenshots attached show examples:

• error-link-seven.gif: shows how a required field left empty generates an error message at the top containing a white underlined link in Seven admin theme; otherwise the actual field with the error and the red border are unchanged from the current visual appearance (there is an invisible error message but we can't see it)
• error-non-required-no-change.gif: shows non-required fields with errors in Seven have no visual change; in a future patch I hope we can make all error messages link to the relevant field (discussed below)
• login-block-both-errors-no-change.gif: shows Garland login form in a block, again with no visual change from current behavior

In a future patch, I hope to make all the error messages at the top of the form contain links to the relevant field. This will require a change to form_set_error() API so let's keep this separate for now. In addition, we may find some visual indicator we agree on in the future, but for now let's get this basic foundation into Drupal 7.

Do you prefer having the error text fully visible as in prior patches? If so, here is the easy CSS you can add to your theme or module:

This looks like a good compromise. I'm setting this back to RTBC as I think the outstanding issues have been dealt with.

I'd still prefer to have the text visible, but since the error will be customizable by theme_form_error_marker() that can be extended in individual themes.

Personally, I'd be OK to go with a similar approach to the ones in #89. It takes some getting used to but they look more usable and more accessible to me -- and it is more convenient than a list at the top.

So if we go with something #89-ish, we need to avoid the following conditions:

Error messages showing up in form blocks and getting totally mangled together:

Redundant error messages showing up on each field of an 'expanded' form element:

Brandon, could you summarize (probably again, sorry about that :\) the challenges you ran into with the existing form error API that make this really hard to do? Maybe we can brainstorm a way around it.

One thought is just to put a line break between the error and the label, like http://drupal.org/files/issues/cnib-errors.gif But I agree with Cliff that these messages should go above the field in question, not below it. The fact that this is CNIB doing this makes me wonder if by being above the field, screen readers aren't given enough context? Is there a way to embed some HTML in a field's <label> element, for example, or..?

The alternative approach 'a la #89' would mean:

1. In the error messages at the top of a page, provide a summary of errors instead of listing each error individually. For example, "2 fields have errors and 1 required field is blank: link, link, link." The link text would be the name of the field, and the link would go to the form element ID to jump to each error easily.
2. Include a red error message at the location of each form element. We can put it inside the label element following the field title, separated by a newline, and preceding the field itself.
3. Make it themeable. We would still create theme_form_error_marker() as above. And we can modify seven CSS as above so that links appearing in the error messages are legible.

Step 1 could be accomplished by removing the drupal_set_message() call from form_set_error() and instead waiting until the end of validation to create one error summary message. In form_set_error() we would need to save the $element['#id'] in order to create a link. To do that I believe we'd need to add an argument and change the $form static variable data structure. The tricky part of implementing this, however, is that some form elements might have an error even though they don't have a name or an ID. For example, the password_confirm container (as in the second screenshot in #111) does not have a #title, nor does it have an ID anchor to link to, because the child elements have all that. Are there other tricky examples in core or contrib?

Step 2 could be accomplished basically the way the patch in #82 does. Adding a newline as suggested would help minimize some of the ugliness in #111. The tricky part of implementing this step, however, is the redundancy problem with parent element errors displaying repeatedly on the children (as in the 2nd screenshot in #111). As @DamZ pointed out in #78, we may need to make form_get_error() smarter so we can set and get errors on specific elements without all children inheriting the errors.

@Dries and @webchick, does this sound like the approach you were thinking?

I am finding it hard to understand this issue, what are the screenshots/rationale of the direction we want?

I believe that @brandonojc is suggesting we go with something that looks more like the NFB uses here -> http://drupal.org/files/issues/nfb-errors.gif

Condensed summary at the top with links down to individual required fields.

A themable red error message below the title of each form element.

We'd also want to have errors in the sidebar blocks be invisible and have the confirmation password be invisible.

I'll have a lot more confidence about inconsistent form behavior when we see this in core:
#558928: Form element labeling is inconsistent, inflexible and bad for accessibility