Thread by @feather

Some collected thoughts for designers for when you're contemplating and exploring error message treatments... Here's some accessibility considerations for your design:

#UX #a11y #accessibility #thread

1. Is your error messaging strategy relying on colour to show error states? If so, think of other ways of conveying error state - iconography, and words that support that use of colour.

Note: I'm not saying "Don't use colour!" I'm saying use other methods in addition to colour.

2. Do your error states/icons/messages/borders have enough contrast against the adjacent colours? Can you tell when a field with an error state is focused?

3. Is your error messaging strategy consistent? Do you use the same types of phrasing across all parts of the interface? On one screen do you say "Error: blah blah is a required field" and on another "Error: blah blah is required to continue"

Set a consistent phrasing pattern.

4. Put some time into thinking about how you'll handle errors for composite fields (eg. a 3 part date field) or cases where 1 of 3 fields are required. Where will you place that error message? is it consistent with simpler fields? Is it predictable?

5. How will you handle long error text that is 3-4x as long as the idealized version you did the mockup with? Will you let the error message expand horizontally? vertically? both? how will that change when you're on a small viewport vs medium vs large? Design for flexibility here

6. Do your error messages persist (rather than show and fade away/disappear) to help those people that might find remembering things difficult?

7. Do you include an error bucket at the top of the page? Consider field level error messages too. That can help with memory related issues (I forgot what I read at the top), low-vision (I can't see what I read at the top) or attention related issues (there's too much at the top)

8. Interaction: A person may want to explore all form fields first before filling it out to understand what is being asked. That might mean that a person using a screen reader tabs through all the fields then shift+tabs all the way back to the start. When do you show errors? ...

... When you show errors onblur when someone hasn't interacted with the field other than simply tabbing through them (forward and/or backward), throwing each field into an error state can be overwhelming and less than helpful. Because they haven't even typed anything yet.

These are all things that have very little to do with code (other than they need to get implemented with code eventually). These are considerations for designers and should be explored early in the design process.