Open Bug 611690 Opened 14 years ago Updated 2 years ago

Some users cannot distinguish required from focused inputs -- 508 compliance

Categories

(Core :: Layout, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: aaronlev, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file)

Many users cannot distinguish colors. On OS X at least, a required input field looks the same to a color blind user as a focused input field. That's why 508 compliance requires that all states be distinguishable w/o requiring color perception. At the moment for the VPAT form, you'd have to suggest people add a user style sheet, which might pass you, but ...

Anyway, I'm not sure the first crack at the "required" state appearance is well-considered enough. I think more thought needs to be put on it. Like a small star in the upper right corner of the field, or something.

I would discuss with other browser vendors, like Microsoft, to see what they think. It should be the same across browsers IMO. They usually do a reasonably good job at balancing the various needs on stuff like this.
FWIW, focused and required both appear to just have a thicker border on OS X.
Testing it in windows HCM (High Contrast Mode) will be telling as well. Aaron, got time to screen shot that?
Mounir, cc whoever did that ui-review here?
Whether it works on some platform now or not because of dotted outlines probably isn't the point. We're the first setting expected browser behavior here, and it should look like a UI designer did it, as opposed to designed by a programmer. (Apologies if that offends whoever did it :/)
FWIW, some kind of * is already fairly well-known and expected by users. Might want to take advantage of that. Some people might actually be confused by the red.
The red thing is going to be removed by bug 609016 and another rule will apply (bug  605124) which will have a default style too (bug 609017).
But, this has _nothing_ to do with required fields but with invalid fields.

People, usually see this with required because it's invalid by default but:
data:text/html,<input type='email' value='foo'>
will have the same red glow (as long as the value is not valid or empty).

What can we do? What would you suggest to distinguish invalid elements?
I think empty elements that are invalid because they're required should just show the required state, not the invalid state yet. Or even, unchanged elements. Otherwise it's like you're telling the user they did something wrong before they had a chance to touch it.

FWIW, color is good --- helps many users. Not just mainstream which is obvious but even people with many kinds of visual impairments. We just need to think about a few of those who can't differentiate. I have met them and they really exist. Red seems like a really good for most users to understand invalid, but it would be good to add something else. Two ideas:
1. Add an icon inside the field, similar to placeholder text, which disappears on focus. A similar technique could be used for the * for required.
2. Try shading or a subtle background effect inside the field, like a light gray pattern of /////. Just an idea. 
Whatever effects are used need to stay inside the bounds of the layout object, right? Nothing floating nearby, correct?

What will the required appearance be, btw?
Also, I think a well-known idiom for "incorrect" is a red X, the kind your teacher writes with a red marker.
Mounir, did you check with any of the other browser vendors? The more that browsers do the same thing, the more usable this is for ordinary folks.
At this time I don't think other browsers have a default UI for invalid controls.

I'm more interested in creating a good UI here than creating a UI which matches other browsers. We have a lot of opportunity to lead and create something good.

The current UI *was* designed by a UI designer, Alexander Limi, precisely because we didn't want it to look like a programmer did it. But if anyone has ideas for improvements I'm sure no one is opposed to that.

I don't agree that focused fields look like invalid fields even to color blind people. One has a thick border and one has a fading out one. But maybe they are too similar, I'll defer to others on that.
I think some of the points I made here are valid:
- About talking to the other vendors: it's possible to lead yet discuss and get in sync. In the accessibility space we do that all the time. It's better for the users, which is what matters.
- I don't think a border that fades a little is different enough -- just talking from experience here.
- Marking a field is invalid before a user interacted with it might not be so great in the eyes of users. Maybe a 3rd state is needed which is unfortunately more work.
- I didn't hear what other effects were considered here.
(In reply to comment #12)
> - About talking to the other vendors: it's possible to lead yet discuss and get
> in sync. In the accessibility space we do that all the time. It's better for
> the users, which is what matters.

We'll certainly discuss with other vendors, but I think getting a release out will provide us with a lot of useful data for those discussions. If you have ideas for forums where we should discuss I'm all ears.

> - I don't think a border that fades a little is different enough -- just
> talking from experience here.

I'll defer to you and others here.

> - Marking a field is invalid before a user interacted with it might not be so
> great in the eyes of users. Maybe a 3rd state is needed which is unfortunately
> more work.

Known issue, see bug 609017.

> - I didn't hear what other effects were considered here.

I'll defer to Limi on this one.
> We'll certainly discuss with other vendors, but I think getting a release out
> will provide us with a lot of useful data for those discussions. 
> If you have ideas for forums where we should discuss I'm all ears.

I think a blog post and/or emails to known developers in other projects would get quality feedback. Better than the bikeshedding that you'll get after a stable release. 

Another good place would be to ask on #whatwg to see what developers would like to see.
(In reply to comment #14)
> > We'll certainly discuss with other vendors, but I think getting a release out
> > will provide us with a lot of useful data for those discussions. 
> > If you have ideas for forums where we should discuss I'm all ears.
> 
> I think a blog post and/or emails to known developers in other projects would
> get quality feedback. Better than the bikeshedding that you'll get after a
> stable release. 

I will do a blog post about :-moz-ui-invalid and :-moz-ui-valid and the default style when they will be on trunk.

> Another good place would be to ask on #whatwg to see what developers would like
> to see.

Are you sure IRC is the best way to get wide feedbacks? I would prefer the mailing list.
Do you know any other mailing list that might be focused on that kind of issues?
I can't think of any mailing list other than whatwg, where you will get the signal to noise ratio you need. Some people don't even like that one. It's personal preference. It's personal preference. I always like starting with an informal chat with developers of other browsers, before putting a proposal out there for wide comment.
No longer blocks: themea11y
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: