Error Management in digital Accessibility
In my opinion, error management does not belong in accessibility, but applies to all users. It is rather tragic that we have had digital formulas for almost 30 years and yet every day we find forms where the basic patterns of good error management are not applied.
The WCAG on the topic of errors
The following WCAG criteria apply specifically to error management.
3.3 Identify and describe errors
•This criterion states that errors in forms must be identified and described in a way that allows users to understand what is wrong and how to correct the error. For example, users should be informed if they have left a required field blank or if their input is invalid.
3.3.1 Error detection
•This criterion requires that users automatically detect errors when entering data into forms and are provided with suggestions to correct them. For example, a website could show users an error message if their email address is in an invalid format, and then suggest they check and re-enter the address.
3.3.2 Labels or instructions
•This criterion specifies that form elements (such as text fields, drop-down lists, etc.) must be clearly labeled or provided with instructions so that the user understands what type of information is expected. Clear labels also help users identify errors in
Error tolerance
Forms should be as error-tolerant as possible. For example, it usually doesn't matter whether someone writes their phone number with a slash, a hyphen or other characters in between. If you live in Germany, it is also relatively unlikely that you have a different country code - possible yes, probably no. However, you still have to enter your country code for Deutsche Bahn, for example. Some banks don't want spaces in the IBAN, some online shops don't want spaces in the credit card number. If unique numbers were necessary for some reason, this could easily be filtered out via programming.
Regardless of this, it should always be explained directly in the input field which characters are allowed or forbidden. When assigning passwords, it often happens that all possible characters are required, but for some unknown reason certain special characters are also forbidden. Additional information, as well as error messages via ARIA, must be described by clearly linking them to the corresponding input field.
Often entries in name fields must be at least three characters, but many Asians have names with only two characters. Select fields with the selection of the country, in which all 300 government entities in the world are stored in alphabetical order, are also a big nonsense. That might make sense at the UN, but it is very unlikely that someone would fill out a German form and come from Micronesia. Something like this could be solved much better with an auto-suggest: For example, you enter BRA and all states that start with Bra are displayed. Select fields are only useful for manageable quantities and options.
Where possible, multiple input options should be offered. Unfortunately, it has to be said that most calendar widgets from JavaScript libraries, for example, cannot be operated properly with the keyboard. It should be possible to simply enter a date using the keyboard. Alternatively, there is also the option of working with select elements or with input fields with the Date attribute.
Where possible, you should use clear HTML elements for the input fields. These can be helpful in correcting the entries or helping with automatic filling. HTML currently has attributes for mail, phone and URLs.
The WCAG criterion 1.3.5 - Identification of input fields (Level AA) requires the storage of machine-readable attributes in order to make the purpose of input fields clearly identifiable if they relate to the user: For example, name, place of residence, telephone number and so on . Personally, I think this is completely unnecessary: both the browser and the assistive technologies have corresponding functionalities, but perhaps this has not yet reached the responsible people. A list of attributes is available from the Mozilla Developer Network.
Error management
For long forms, all errors and the places where they can be found should be summarized at the beginning. For various disabled people - and not only for them - it is difficult or impossible to keep track of a long form. In addition, jump anchors should be used to guide you directly to the faulty areas. If it is technically possible, it would be best if only the incorrect fields are displayed. Personally, I currently think dynamic validation makes more sense than doing it on the server side. It is more ecological and also more barrier-free: the screen reader has to completely buffer every newly accessed page, the blind user
Long forms should be spread over several subpages. Whether they are static pages or tabs is a matter of taste. However, it is important that entries made once are saved automatically.
Error messages
Error messages should be as short as possible, understandable and helpful. For a date, for example, you may need an example of what a correct entry looks like, for example DD.MM.YYYY.
Error messages may not only be identified by color or other sensory features such as a displayed symbol. “Check the fields marked in red” as with Deutsche Bahn is a no-go, but unfortunately it is not only found there.
Add text like “Error: Please correct…” or similar with helpful information. As mentioned above, if the error message appears at the specific element where the error occurred, it must be described using ARIA by linking to the associated input field.
Mark mandatory information
There are two ways to do this, both of which should be fulfilled:
- When symbols such as the star are used, the meaning of the symbol must be described AT THE BEGINNING of the form. If all fields are mandatory, this must also be described at the beginning.
- Regardless of this, all mandatory fields should also be marked as such in a machine-readable manner, for example via ARIA required
Summary of entries
For complex entries that involve money, the entries should be summarized again at the end. It is important that the example tables are formatted correctly.
Error Messages in Applications
Unfortunately, the WCAG does not help us with web applications. Here I would check how serious the errors are. If, for example, documents cannot be saved or emails cannot be sent, I would recommend a dialog that the user has to actively click away. And of course it should be helpful.
If the errors are non-critical, toast messages can also be used, which I have discussed in detail here. Perhaps a very slow internet connection or something similar is not critical.
Other error messages
Other error messages should also be understandable and helpful. Nerds can relate to 500, 400 or 301. However, mere mortals do not know what these server errors mean and they are not helpful either.
This applies accordingly to all error messages that are generated on websites. The most frequently occurring errors can be identified. And please help me: Don't blame the errors on the users. Comments like “You probably typed the URL wrong” in 404 error messages are rude and usually incorrect. When was the last time you typed a longer URL yourself? Exactly, it's actually always the provider who deleted pages and didn't redirect them.
Other information, such as ad blockers, JavaScript turned off or missing rights to display social media content, should also be formulated in such a way that they are understandable for non-techies.