Applications, forms and error handling
Forms
Sufficient labels, cues, and instructions for required interactive elements must be provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends. All form controls must have implicitly associated labels using mark–up and be positioned close to the element that they refer too.
The cursor must not be automatically moved between fields during data entry.
Instructions and cues in context to help in form completion and submission must be provided. Only use text (and images) to provide examples of how to fill a field in. All example text must appear before the item to be filled in. Any fields that are mandatory need to be clearly marked using an asterisk or similar marker.
Wherever possible ARIA states, properties and live regions should be used.
Submission
Ensure that a user action is required to submit a form, such as activating a submit button. Do not automatically submit it based on focus leaving a field or all fields being complete. A form submission must be reversible, verified or confirmed to allow a user avoid accidental submission of information.
If a form has a number of stages, wording such as “continue” must be used rather than “send” or “confirm”.
CAPTCHA
Always provide information in the alt text for CAPTCHA (a test that involves typing in the letters that are distorted in an image) that describes its purpose The text alternative is “Type the word in the image” and it is a good idea to provide contact information for a human customer service representative who can bypass CAPTCHA.
Assistive text
Wherever an error occurs, such as on a form, clear text must be provided in context with the element to help the user to solve the issue.
Provide examples of data formatting where there are restrictions on the format of the data a field will accept (eg – A date should be DD/MM/YY) and should be placed before the field. Any fields that are mandatory need to be clearly marked using an asterisk or similar marker.
Error messages
If an input error is detected (via client–side or server–side validation), provide suggestions for fixing the input in a timely and accessible manner. Error messages must be clear and concise and give the user some help as to what they need to do next and be placed next to the relevant field. There must be clear indication of which form field generated the error.
If a certain format is required for the field an example of the format and specific suggestions for fixing a particular error must be included in the error message.
Sessions and authentication
The user must be informed when they have been logged out either deliberately or due to a timeout and must be provided with a link to log back in.
If an application has a time limit, the user must be given the option to turn off, adjust or extend the time limit if the time limit is no longer than 20 hours or required as part of a real–time event such as an auction.
Any interruptions such as alerts and page updates must be postpone or suppressible by the user. If an authenticated session expires the user must be able to re–authenticate and continue without losing any data from the current task.