Accessibility Design - Where To Put "required" In Forms? Options

[cre8pc]

We know that forms often contain a RED colored "Required" word or "*" to point to required fields. We know that for accessibility standards, the color red is illogical for blind people and colorblind readers (red is a common "missing" color, esp. for colorblind men.)

There are suggested workarounds but I like the idea of plopping in a small image for the "*" and using an alt attribute labeled "required" for screen readers.

However, where is the best and most welcome place to put it? Before or after the field label? Does it matter for screen readers where it goes?

The other workaround I've seen suggested are indenting required fields or otherwise separating them from non-required ones visually by separating the fields or grouping them.

Is this a preference for those who use screen readers, and sighted readers (because scanning groups of labels would be made easier)?

[joedolson]

Using red is actually fine, as long as the background color is of an appropriate contrast. It's not that colorblind individuals won't see red text; they simply won't see it as _RED_.

However, I still think that there are better ways of labeling required fields for forms. In my mind, the most important thing is clarity: it should be very easy to determine exactly what is required and what isn't.

In simple forms, with only a couple of required fields, I find that separating the required fields out can be useful: using a form <fieldset> and <legend> to demarcate required information.

However, with more complicated forms, it can be more difficult: information should be grouped semantically, as well, so if 5 out of 7 address fields are required, it makes far more sense to group all address information together than to group required information together.

Personally, I like to use the word "required," in text, whenever possible. An asterisk or graphic requires cognitive associations which may cause information barriers --- text is less likely to cause that problem.

A second factor is to make sure that your error responses are clear: tell the user which fields they left blank or filled with invalid information and, if possible, prefill the form with their responses for easier editing.

I think that the "best" solution is always a combination of different methods, depending on the context: but clear text labels are pretty much always a must, in my book.

[Respree]

However, where is the best and most welcome place to put it? Before or after the field label?

I'm not so sure there is a 'best' or 'welcomed place' to place an asterisk. I imagine if you ask 100 people, some will like it before, while others may prefer it after -- in what percentages, I haven't a clue.

I think the most important concept is to make it very clear which is versus which isn't a required field. Whether that distinction is made with the use of bolding, colors, italics, differing fonts, askterisks or other similar techniques, it should not have to make the reader 'guess'.

The common trend of placing an askterisk next to required fields seems counter intuitive to me. In my experience, 'most' of the fields of a form typically are required, with the minority being not required. To me, the askterisk designation should really be used to communicate the exception (not required) and not the rule.

i.e.

All fields are required, except where otherwise noted (*)

Name
Address
City
State
Zip
* Phone
Email address.

instead of...

* Indicates required field

* Name
* Address
* City
* State
* Zip
Phone
* Email address.

[cre8pc]

All fields are required, except where otherwise noted (*)

Name
Address
City
State
Zip
* Phone
Email address.

At first glance that example looks real sweet, but I think we're conditioned to think that any (*) means required, so those scanning and not reading directions (common behavior) won't catch the switch.

I got curious because I tested a very long application that had a mix of required and non-required fields, or so it seemed because the labelling was so confusing it was hard to know what was what. It was a nightmare for those who could see, let alone anyone with a screen reader. There was so much text on the page, needed as user instructions that unless they reorganized it into chunks better (first suggestion), I wondered about placement of an image (*) because I'd seen that recommended in Dive into Accessibility. Even he wondered where to place it (before or after a field or label).

Joe, appreciate the clarification on RED.

[joedolson]

At first glance that example looks real sweet, but I think we're conditioned to think that any (*) means required, so those scanning and not reading directions (common behavior) won't catch the switch.

That was my first thought, as well. Expectations and the RTFM principle will tend to make that system ineffective.

I think that reorganizing long forms into chunks (preferably on separate pages) is critical to keeping the information easy to comprehend, regardless of the required/not required dichotomy: if there are only 5 items on the page, it's much easier to sort out what you need to do than it is when there are 50.

[Jozian]

I agree with Joe that for longer forms we should be breaking up the info into multiple groups and pages. Chunk it up!

Personally, I like to use the word "required," in text, whenever possible

I see this often done in microfont - that cant be very 'accessible'...

-Jeff

[joedolson]

No, microscopic font sizes don't help anybody, much...

However, the tiny text "Required" isn't, in my opinion, significantly worse than an asterisk. I tend to put it in full-sized bold type, myself...

[bragadocchio]

I think that reorganizing long forms into chunks (preferably on separate pages) is critical to keeping the information easy to comprehend, regardless of the required/not required dichotomy: if there are only 5 items on the page, it's much easier to sort out what you need to do than it is when there are 50.

The fewer the number of pages, the better, from my experience.

When you're getting someone to fill out a multiple page form, you want to spell out all of the steps/pages before they start filling those out. If the steps sound like they are broken into too small pieces, they might be.

I do like the idea of chunking information in semantically meaningful ways on pages. Using a Fieldset can help with that. A legend with it can help you chunk information in a meaningful way.

[Jozian]

Brag-

Good point on the number of chunks/pages having an upper limit. Absolutely nothing annoys me more than signup forms that ask for a little, and then more, and then more... and dont tell me how much more I have to give before I get. HouseValues.com, and many others, used to do their signups this way. Not sure if they still do or not, but I disliked it immensely.

A lot of online real esate, mortgage, and debt sites out there seem to use any and all tactics to lure, bait, and/or hide their true identity (as a feeder site usually).

I have a lot of experience with online mortgage applications and leads. In this industry, the debate never ends over what is the right formula. Full app? Short app? Detailed contact info? Short contact info? Spouse Info too? Get the SSN, work number, email? ... You dont want to scare the client away by asking for too much info, but if you ask for too little, then how committed are they and how much can you actually tell them about their situation and options?

-Jeff

This post has been edited by Jozian: May 21 2007, 09:45 PM

[joedolson]

It depends on the scope of the form: a survey with 100 questions really should be broken into several sections. On the other hand, a survey with 15 questions absolutely shouldn't.

I'm a firm believer in user testing: look at drop out rates, etc., to see whether the information design supports itself effectively.

It's also worth noting that it doesn't matter that the completion rates are higher if the information supplied is bad: if users are consistently only completing half the survey or using the "random selection" method just to finish a massive questionnaire, then the information design is still faulty.

Honestly, a survey should be able to gather chunked valuable data with far fewer than 100 questions --- better might be to have a particulate selection method where randomly identified (or topically separated) groups of participants each answer logical portions of the survey. Having every respondent answer every area of questioning can be very ineffective.