, 11 tweets, 3 min read Read on Twitter
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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Derek Featherstone
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!