Interaction states are visual representations used to communicate the state of an interactive element.
- Interaction states include default, hover, focus, active, disabled, read-only, selected, checked/unchecked/mixed, grabbed, expanded/collapsed, and aria-pressed (toggled) states.
- Interaction states can be combined. For example, an element could be selected, hovered, and focused at the same time.
- There are other visual variations beyond interaction states that are not covered here, such as primary, secondary, destructive, reversed, persistent/dismissible styles, visited/unvisited, and loading.
A disabled state applies to an element when the action is unavailable to a user. It might be unavailable due to permissions or pre-requisites, such as needing particular data. For example, you might prevent launching a survey with no questions and no participants by disabling the launch button.
- Disabled components have 30% opacity. The opacity is usually applied at the parent component level, not to internal elements. For example, a disabled button has 30% opacity while its text color and background color has 100% opacity.
- Disabled elements are exempt from minimum contrast requirements because they're "incidental".
- Use the
disabledattribute on disabled form elements, such as buttons, so that the disabled state is perceivable to different users, including those using assistive technologies.
- Form elements can inherit disabled states from parent form elements. For example, a
formmight be disabled so its child Checkbox Group would be disabled too.
- Disabled states remove all interactive functions of a component, including its normal action and hover states. They ignore clicks.
- Disable elements when they are temporarily unavailable and hiding it would be conspicuous.
- You might disable filtering options when the user has narrowed the selection so much that there are no more results available.
- You might disable a button immediately after a user clicks it to prevent duplicate actions or when removing the button would be conspicuous. For example, if removing the button would mess up the layout, confuse users about its absence, or make it unclear that usually more actions are possible.
- Show disabled elements if people need to know what actions might be available to them that are temporarily unavailable. Let them know what's needed to make these actions available, such as permissions, data, or some action they need to take. If there's no way for the action to become available, consider hiding it.
- For a split button with multiple actions, a menu with links or actions, or a Select, you might want to disable only some options. Before doing this, consider if there's another approach that would minimize cognitive load and effort for the user.
- If there's only 1 valid option available in a Select, you might replace the Select with that selected option as text information.
- If there's only 2 valid options available in a Select, you might use a Radio Group instead.
- If there are alternative options that alternate between availability, you might hide the unavailable option instead of disabling. For example, if a menu contains an option for "give access", after giving access that item could then become unavailable. You might then replace it with a "remove access" option. Don't show both options at the same time with one disabled.
- Consider providing a message to explain why an element is disabled and how to enable it.
- For example, a form might show a negative Inline notification at the top of the form summarizing all the invalid fields that need to be corrected before proceeding.
- If you need to disable a button, help users (including people using assistive technologies, such as screen reader) understand how to enable it again. For example, include nearby microcopy that explains why it is disabled and what action the user can take e.g. “There are no more reports to share. To share more reports, wait for a survey to close.”
A "read-only" form element cannot be modified, but can otherwise be focused, read, and submitted with a form. For example, you might show an employee what other previously known information about them by their organization that they cannot edit within Culture Amp would be submitted along with their user-provided data in a form. This state is rarely needed. More often, it would be provided as regular text content instead of a read-only form element.
The "working" state applies to buttons, in particular, situations where a button action triggers a change in UI state but needs to wait for a server response, such as submitting a form. Don't disable buttons while submitting forms with ajax by Chris Ferdinandi summarises why this is especially important for screen reader and keyboard users.
To indicate this to the user, the button triggering the action changes to a 'working' state while it waits. The label and/or icons visually disappear (while maintaining the space it once contained) and a loading spinner is centered in its position on the button.
The working state of a button is pseudo-disabled. It visually appears disabled to indicate it isn't actionable, and it must retain focus for accessibility reasons. This is a pattern for short duration interactions - long enough to let you know something is happening, but not so long that you need to show progress. Consider using one of the other loading patterns if this doesn't apply.
To avoid the button changing the position of nearby actionable controls, the working button must retain it's pre-working state width.
- Use default, hover, focus, active, and disabled states on links, buttons, checkboxes, radios, text fields, icons with tooltips or popovers and icon buttons.
- Use a disabled state when hiding an element would be conspicuous.
- Instead of disabling an element, you may show a blocking modal on click that explains why it won't perform its usual action. You might visually style the element as disabled without actually disabling it.
- Avoid disabling an element when there's no path for a user to make it available.
Here are some examples of other existing design systems:
- Shopify's Polaris Design System
- Material design: Interaction > States
- Carbon design system: Disabled states
- Web Content Accessibility Guidelines (WCAG) 2.1 Glossary state definition
- Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0
- Web Content Accessibility Guidelines (WCAG) Understanding Success Criterion 1.4.13: Content on Hover or Focus
- MDN ARIA: button role: Associated ARIA roles, states, and properties
- Style hover, focus, and active states differently
- Why you shouldn’t include disabled interaction elements in your design system
- StackOverflow: What's the difference between disabled=“disabled” and readonly=“readonly” for HTML form input fields?