...

All alphanumeric input fields will display the value entered by the user. If the input is invalid, an indication for invalid/warning will be displayed. Prevention of input is not allowed (e.g. typing on the keyboard “A” and not displaying it in the field)

Triggering the validation is set by 3 types:

• Syntax validation - validation should be displayed while typing.
  For example:

  • An illegal character was typed  (e.g. numbers instead of alphabetic)

  • Exceed the number of characters (e.g. user input 3 digit number where only 2 digits is allowed)

• Logical validation - any validation that is set on the required value (e.g. Max. input of 100)

  • In most cases, the validation will occur after the user left the field

• Missing input on a required field

  • Validation is displayed as soon as the user leaves (out of focus) the required input field which has no input

  • Note: when a form has a single required field, the validation will appear only after the user tries to submit the form (Submit button is enabled)

Autocorrect - Some cases require an automatic correction of the invalid input.

• Pagination and Slider with a numeric input, which have by definition a numeric range, will behave as follow.

  1. When the user enters invalid input, the field will visually indicate invalid input

  2. On OutOfFocus the entered value will be automatically changed to:

     1. Last valid value

     2. Edge range (e.g. in pagination “0” will auto-correct to the “1” )

• Connected fields

...

• - where different fields are

...

• dependent on each other and the numeric range is dynamic.
  On OutOfFocus with an indicated invalid input, a pop-up message will appear with the options of:

  • Back - returns the focus to the field with the last used input 

  • Revert - returns the focus to the field with the latest valid input (the one before the user changed it)
    See pop-up example:

    Image Modified

...

Default input/validation

• When starting to edit a field with a validation indication on it, the current indication will be hidden (i.e. it will be treated as if the user had edited the field for the 1st time).

• If the user had entered a form/page/screen for the first time (fields are empty), logical validation should not be enabled. However, syntax validation should be enabled.

• In cases where the user enters a page that already had input, the warning validation should be displayed (e.g. the user enters a page already edited with warnings in it).

Structure

The field validation consists of:

• Color frame or  & a Small  icon on the top right corner - marks the validation type

• A  validation tooltip message appears upon hover of the validated field/component 

• A descriptive message next to the submit button

  • Error messages have a higher priority than a warning. In case the error was fixed, the warning validation should be presented.

  • In some cases of limited space or a short form, no descriptive message will appear

Examples:

Components		Error	Warning
Text field
Text area
Dropdown menu
Combo box (free text field)
Spinner (free text field)
Date Picker (free text field)
Time Picker (free text field)
Search field		NA
Toggle		NA
Slider		NA
Single checkbox		NA
Checkbox group
Grid table cell
Tab
Call To Action with short text		on Error, button is disabled
Call To Action with mixed errors  error takes priority
Call to action with long text.  Pop-up size might need to expand in height
*  Unlike "field validation error" the warning version can appear on top of controls that does not have a text field, since a warning can appear when there is a conflict between 2 controls.

Text position:

• Text position can be either near the CTA (right-aligned) or at the beginning of the row (left-aligned) according to size and available width
  See examples:

  

  
  

  

...

• 2 options for the content of the error message:

  • Generic 
    The content of the message is written in advance and there is no need to refer to the specific text that the user typed, for EX: "not a valid zip code" 

  • Input based (  Preferred option where applicable)
    The content of the message can dynamically change based on the input of the user, use it to clarify to the user where the error is coming from.
    Some examples:

    •  Invalid input → zip code cannot contain the special character: "%"

    • You cannot book this flight, please select another destination or date → Direct flights to Dublin are only available in August. Please select another destination or date 

• For complicated fields, an example in the text of the tooltip can help

• Try to avoid negative words

  • (e.g. "Password does not meet requirements" or "Invalid Password" → could be turned into→ "Password must contain 8 alphanumeric characters")

Accessibility compliance

...