Error State — what it is, field error display, and implementation in Android

What is field error state in Android?

Error State is a special display mode of an input field that activates when entered data fails validation. Visually, Error State includes three components: a change in the border or background color of the field (usually to red), the appearance of a text message below the field describing the error, and optionally an icon or highlight. The purpose of Error State is to instantly draw the user's attention to the problematic field and suggest how to fix the error.

In Android, Error State is implemented at the TextInputLayout level from Material Design Components. TextInputLayout wraps EditText and manages its states: normal, focused, error, disabled. The setError(String) method switches the field to error state, changes the border color and displays the message. When text changes or setError(null) is called, the field returns to normal.

According to Material Design Guidelines, Error State should be noticeable but not dominant. The red border color should contrast with the normal state but not overload the interface. The error message should contain specific information about the problem and how to solve it. An error icon (e.g., a red circle with an exclamation mark) reinforces the visual signal.

How setError works in TextInputLayout

The setError(CharSequence errorText) method switches TextInputLayout to error state. The errorText parameter is the text displayed below the field. If null is passed, the error is cleared. TextInputLayout manages the animation: the error text appears with a smooth fade-in, the border changes to red. An error icon (default: exclamation mark in a circle) is shown at the end of the field.

Important details: setErrorEnabled(true) must be called before setError to reserve space for the error message. Otherwise, the layout may "jump" when the error appears because space is not reserved. It is recommended to always enable error support in XML via app:errorEnabled="true" to avoid layout shifts.

The setError method is automatically cleared when the field text changes if setErrorEnabled(true) is enabled. This behavior is convenient for real-time validation: as soon as the user starts fixing the error, the red border disappears and the field returns to normal. However, for complex scenarios this auto-clear may be undesirable — in such cases, manage the error manually.

val til = findViewById<TextInputLayout>(R.id.til_email)

// Enable error support (set in XML otherwise)
til.isErrorEnabled = true

// Set error message
til.error = "Invalid email address"

// Clear error
til.error = null

// Check if error exists
if (til.error != null) {
    // Field is in error state
}

The example uses Kotlin properties to access setError/isErrorEnabled. TextInputLayout automatically updates the UI: changes boxStrokeColor, shows the error icon, displays the error text. If the text in EditText changes, the error is cleared automatically. For manual reset, set error = null.

Alternative ways to display errors

Not all projects use Material Design Components. For custom error display, you can use a separate TextView below the EditText that becomes visible on error. This approach gives full control over styles and message placement. For example, you can place the message to the right of the field, use a different background color, or add an icon to the left of the text.

In Jetpack Compose, Error State is implemented via the isError parameter in OutlinedTextField or TextField. When isError = true, the border turns red, and you can show error text via supportingText. Compose does not have built-in auto-clear on text change — the developer manages the error state manually using remember and mutableStateOf.

For group errors (a single message for multiple fields, e.g., "Fill in all required fields"), use Snackbar, Dialog, or an inline block at the top of the form. A group error does not replace the Error State of individual fields but complements it. The user first sees the general message, then looks for specific fields with errors.

Colors, icons and error animation

Error State color in Material Design Components is controlled via the boxStrokeErrorColor attribute or the colorError attribute in the theme. By default, the system red color is used, but it can be overridden in the app theme or directly in TextInputLayout via app:boxStrokeErrorColor="@color/customErrorColor". For dark theme support, it is recommended to use a selector with different colors for light and dark modes.

Error icon is configured via app:errorIconDrawable. By default, an exclamation mark in a circle is displayed. It can be replaced with a custom icon or removed entirely by setting app:errorIconDrawable="@null". The icon is displayed at the end of TextInputLayout and serves as an additional visual marker. In Material Design 3, the error icon is required for accessibility.

Animation of error appearance is built into TextInputLayout: the text slides up from below with a smooth opacity change. For custom animation, use the Transition API or MotionLayout. For example, shaking the field on error draws additional attention. However, overusing animation degrades UX — smooth message appearance is sufficient.

Managing error state during validation

Managing Error State is divided into two stages: setting the error during field validation and clearing the error upon correction. In the simplest case, validation is called in TextWatcher.afterTextChanged: if the value is invalid, setError is called with an error message. If valid, setError(null) is called. TextInputLayout automatically hides the error when setError(null) clears the state.

For Form Validation, errors are set at the form submission stage. Loop through all fields, validate each one, set errors for invalid fields, and focus on the first erroneous field. The submit button is blocked during this process. If the form is large, it is recommended to scroll to the first field with an error and automatically set focus on it.

The single error focus rule: when submitting a form, set focus only on the first field with an error. The user fixes one error at a time, and after correction, the next field with an error automatically receives focus. This step-by-step approach reduces cognitive load. Material TextInputLayout does not intercept focus when setting an error — this must be done manually via requestFocus().

Common mistakes when working with Error State

The first mistake — missing isErrorEnabled. If setErrorEnabled is not called before setError, the layout may shift when the error message appears. This is especially critical if the field is in the middle of the screen — the user loses their scroll position. Always enable setErrorEnabled(true) in XML via app:errorEnabled="true" or programmatically before setting an error.

The second mistake — overly long error message. Long text wraps to multiple lines and may overlap neighboring fields. The recommended error message length is 20-40 characters. If more information is needed, use helperText in the normal state or a tooltip for additional explanation. Brevity is the foundation of a good Error State.

The third mistake — ignoring accessibility. Error State must be accessible to screen readers. TextInputLayout automatically announces the error via contentDescription, but custom implementations must do this manually. Use announceForAccessibility() or android:importantForAccessibility for error messages. TalkBack users should hear the error immediately after it appears.