Using the correct state or combination of states for a UI element helps users to recognize possible options and see where they need to take action.
Depending on the UI element, different types of state are supported:
- Control states
- Value states
- Visual states
- Additional states
The table shows the possible states for each type.
A UI element can have only one control state at any given time.
Use the “enabled” state if:
- A UI element can currently be used.
- A UI element cannot currently be used, but disabling it is not an option because users might not know how to enable it. In this case, keep the UI element enabled and provide a message if it is used incorrectly.
Example: Enable a button even if the corresponding action can only be performed if a setting is made on another page or in a completely different subsection on the same page.
- A UI element is a finalizing action, such as Save, Accept, OK, or Cancel. Finalizing actions are placed on the footer toolbar of a page or dialog.
- A button on a table toolbar does not depend on items in the table being selected.
Examples: Column Settings, Sort, Filter, Full Screen, Add
- A button on a table toolbar depends on items in the table being selected, and one or more of the items currently selected fulfills the requirements for enabling the button.
Example: Enable Delete on a table toolbar even if the user can delete only some of the items in the current selection.
- An action is global, such as Share or Print.
Do not use the “enabled” state if:
- A UI element cannot currently be used and it would be obvious how enable it. Disable it instead.
- A UI element cannot be used at all. Hide it instead.
- A button on a table toolbar depends on items in the table being selected, and none of the items currently selected fulfills the requirements for enabling the button. Disable the button instead.
Use the “disabled” state if:
- A UI element cannot currently be used, and it is obvious how enable it.
The user must click a checkbox to add a value in an input field. The input field is placed directly next to or directly below the corresponding checkbox. Disable the input field if the checkbox is not selected, and enable it as soon as the checkbox is selected.
- A button on a table toolbar depends on items in the table being selected, and the current selection does not include suitable items.
- Disable Copy if nothing is selected.
- Disable Compare if fewer than two suitable items are selected.
- Disable Delete if nothing is selected or if the current selection contains only items that cannot be deleted, such as locked items.
Do not use the “disabled” state if:
- The user can never enable the UI element. Hide it instead.
- It would not be clear why a UI element is disabled. In this case, keep the UI element enabled and provide a message if it is used incorrectly.
- The input value of a UI element is relevant, and taken into account if a finalizing action is triggered. In this case, users must also be able to read the value. Use the read-only state instead.
Never disable the checkboxes that are used to select items in a table or list. If an action can’t be executed for some of the selected items, keep the checkbox enabled and display an appropriate message when the action is triggered.
Hidden UI elements are not visible, not focusable, and not editable. The UI element doesn’t take up any space. If a UI element is hidden at runtime, the freed space is used by subsequent UI elements.
Use the “hidden” state if:
- A UI element can never be used (for example, because the role or group assigned to the user doesn’t include the necessary authorization).
- Hiding the UI element is a meaningful form of responsive behavior.
Example: A column of a table is not needed on phones.
- A UI element is not available in the current mode.
Example: Buttons that are only available in edit mode should be hidden in display mode.
- A UI element is not available for the current state.
- Hide Delete on a page in an undeletable state, such as “sent”.
- Hide Delete as a line-item action for an undeletable item.
- Parts of the UI are changed based on a setting.
Example: When changing the setting, hide UI elements that are not available for the new setting.
Do not use the “hidden” state if:
- A UI element cannot currently be used, but can be enabled by user actions.
- A selection does not contain deletable items. In this case, disable Delete.
- A table was filtered down and currently doesn’t contain deletable items. In this case, disable Delete.
Use the “read only” state if:
- A page or a part of it is in edit mode, and
- a UI element is currently not editable or changeable.
- an input value is relevant and needs to be taken into account when triggering a finalizing action.
- an input value must be readable.
Do not use the “read only” state if:
The display-only state is used for two cases:
- A UI element is used in display mode.
- A UI element is displayed in edit mode, but is never editable.
The visualization of display-only UI elements is optimized for reading. The type of UI element does not necessarily need to be recognized. The UI element is not focusable (exception: links), and not editable. Its value is recognizable and shown in full (not truncated). The UI element might also be displayed in a “compressed” format, where the information is displayed differently to the read-only or editable state.
Use the “display only” state if:
- A page or part of it is in display mode.
- An input value is relevant and needs to be taken into account (for example, it is sent on Submit)
- A page or part of it is in edit mode, and a UI element is never editable (for example, a UI element displaying a generated ID).
- A link cannot be accessed by the user but the link text contains valuable information.
Example: A link to a sales order object page shows the sales order number as link text. If the user doesn’t have access to the object page, show the sales order number as plain text.
Do not use the “display only” state if:
- A page or part of it is editable and a UI element is currently not editable. Use the read-only state instead.
- A link cannot be accessed by the user and the link text doesn’t contain valuable information. Hide the link instead.
Example: A link to a fact sheet shows the link text Fact Sheet (or Details). If the user is not authorized to open the fact sheet, do not show the link at all.
Value Help Only
Use the “value help only” state if:
- A UI element can currently be used.
- User input is limited to specific values, and you don’t want to let users type in values directly.
Do not use the “value help only” state if:
- You want to allow free text entry.
- User input should be limited to specific values, but typing them is faster and more efficient. In this case, work with selects, combo boxes, or input fields with suggestions and validation to limit the user input to the permitted values.
- The surrounding page (or part of it) is in display mode.
Value states are only available for user input elements. A UI element can have only one value state at any given time. The value states make use of the semantic colors. For more information, see How to Use Semantic Colors.
Use the “none” state if:
- There is no reason to use another value state.
- The user input has not yet been validated.
- Validation of the user input was successful, without any issues.
- A message contains non-critical, additional information for users.
Do not use the “none” state if:
- User input was validated and a problem occurred. Depending on the severity, use the warning or error state instead.
- A message contains information about a warning or error.
Use the “error state” if:
- Users need to be prevented from finalizing the current mode or page.
- User input failed a validation, and the problem must be fixed before the user can continue.
- A message contains information about an error.
Do not use the “error” state if:
Use the “warning” state if:
- The current mode or page can be finalized, but doing so might lead to an error later on.
- User input was validated and a minor problem occurred. It is possible to continue without fixing the problem, but doing so might lead to an error later on.
- A message contains information about a warning.
Do not use the “warning” state if:
Use the “success” state if:
- A message contains information about a process that was finalized without any issues. Users will need this information later on (for example, values that need to be copied to another app).
Do not use the “success” state if:
- A process was finalized successfully and a short notification is enough. In this case, use a message toast instead.
- The surrounding page (or part of it) is in display mode.
Use the “information” state if:
Do not use the “information” state if:
Visual states are handled by the corresponding UI element directly. A UI element can have only one visual state at any given time.
The hovered state shows that the cursor of a pointing device (such as a mouse or pen) is currently placed on a UI element that is in an enabled, read-only, or value-help-only state.
The hovered state is not available if the UI element is used with keyboard and touch devices.
Do not use the “hovered” state if:
- You need to provide additional information for a UI element. The hovered state is only available for some interaction devices. When using other devices, the information gets lost.
The focus determines which UI element receives the user input when the user input itself does not supply positioning information (for example, keyboard input).
Only one UI element can have the focus at any given time.
The focus is changed by activating another UI element with an input device that provides positioning information (mouse, pen, touch). Clicking an area without a focusable UI element removes the focus until another UI element gets the focus through a user interaction.
With a keyboard, the focus is changed as follows:
|Key(s)||Change in Focus|
|F6||Move the focus forward to the first element of the next group.|
|Shift+F6||Move the focus backward to the first element of the previous group.|
|Arrow keys||Move the focus between items (for example, within lists, tables, calendars, or charts).|
When you move the focus using the keyboard, the newly-focused element does not get activated (“pressed”).
Initial Focus Position
When opening a new page, dialog or similar element, make sure that the focus is initially placed at a meaningful element. For example:
- At the first focusable element below the launchpad shell bar
- The first editable field
- The first editable field that requires user input
Or in general: The element that is likely to be the first one used.
Use only one control state at any given time. If several control states need to be combined, use the most restrictive state.
List of control states in edit mode, from the most restrictive to the least restrictive:
- Display only
- Read only
- Value help only
In display mode, use only the following control states:
- Display only
- Enabled (for display controls only)
Use only one visual state at any given time. If several visual states need to be combined, use the one that requires the most user interaction.
List of visual states, from the most to least user interaction:
Use only one value state at any given time. If several value states need to be combined, use the most severe state.
List of value states, from the most severe to the least severe:
Combining Different Types of State
- Hidden and disabled UI elements cannot be combined with any other state.
- Display-only UI elements can be combined with the pressed state (toggle only) and the selected state.
- Read-only UI elements can be combined with pressed state (toggle only) and with the selected state. In addition, read-only elements can be focused.
- Value-help-only UI elements can be combined with any visual states. In addition, they can be required and focused.
- Enabled UI elements can be combined with any visual state, any value state, and any additional state.
Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.