Reading Time: 3 minutesIt’s common to congratulate our users with “successfully” when a transaction completes. Here’s an example success message:
You have successfully uploaded your files.
The example message congratulates our users for staying on task. After all, the transaction may have taken effort and frustration to complete. At the same time, we’re admitting that success is not the usual outcome. Either the design is less than ideal, or we’re exposing our internal jargon of “success” and “error”.
Sure, give the success icon a meaningful text equivalent if you must, and don’t think it can’t be written as “Done”. Better is to leave it empty. It’s likely an unnecessary visual signal, and the message conveys the audible experience just fine without it. And why is there a checkmark anyway: are we grading our users’ performance? Why not add a bottle of bubbly and some rice confetti?
Let’s change that. In the following examples, we expect success because that’s how we design things around here:
- Your files are uploaded.
- You deleted the following file: index.php
- Welcome to our community.
When you test the previous examples with VoiceOver, the check mark is announced as “tick”. You may interpret it visually as a “tick”, too. There’s that school teacher vibe again.
Other than trawling CSS glyphs for an improved example or creating our own glyph and alternative text value, it’s okay to remove the icon. Allow the written content to deliver the message. The green can go, too, although it may add visual attraction in a busy UI. Recall that we’ll use ARIA to alert people using a screen reader, so the colour is its inclusive equivalent.
The following is an update:
- Your files are uploaded.
- You deleted the following file: index.php
- Welcome to our community.
You may want more contrast between your success and error messaging. It depends, of course. As long as people of all ability scenarios are informed, then your design remains your domain.
Errors may be styled with an icon. The following examples present a warning triangle that VoiceOver announces correctly as a “warning triangle”. However, it’s not appropriate for what we term “error” messaging when the message isn’t the result of a system or user error:
- Your files were not uploaded. Please try again.
- You cannot delete the following file: index.php
- Sign in or sign up to join the conversation.
Again, we can remove the icon content as follows and not lose the meaning:
- Your files were not uploaded. Please try again.
- You cannot delete the following file: index.php
- Sign in or sign up to join the conversation.
When you miss that icon terribly, then write a conditional accessible and invisible content strategy to match the message. Don’t impose our “success” and “error” jargon on our readers.
Let’s design for success, anyway.
You may like to read why In time, has been will be a has been.
On what errors are and are not
When you write your “error” messaging, remember we make the data input and validation rules. Our users are working hard to understand what we want them to do. It may be different to other platforms and especially when we break common idioms and patterns.
Our user can’t knowingly make an error when they need to complete the tasks we set them with the features we give them. Our users can only fail when we fail to explain what’s needed done with our choice of content: flow, UI, and writing. Go gentle. Think of our flow, UI, and writing as performance support. Work on error prevention before error management and we can’t go far wrong.
Let me know what you think in the comments.