new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

IBM Carbon · all subjects

read-only-states

13 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Read-only state definition and purpose

A read-only state is applied to components when users are allowed to review but not modify the component. It removes all interactive functions from the component. Read-only states are considered active, and the data they contain can be used in an application's processes. This state change transforms a component's purpose to be purely informative rather than interactive.

Read-only state use cases

There are three main use cases that initiate a read-only state: (1) Application process: an application's process temporarily restricts a user from modifying the component until the process completes. (2) Locked: an application restricts the number of users that can modify the component at the same time. (3) Permissions: a user's credentials allow them to view the component but not modify it.

When not to use read-only states

Do not use a read-only state if the component does not have an enabled state to display static information. Do not use read-only as an alternative to a disabled state when a component is temporarily unavailable pending user actions or decisions, such as completing a form or choosing an option. Do not change a component's state from disabled to read-only.

Read-only state visual anatomy

Read-only state anatomy includes: (1) Background color change with transparent background for fields. (2) Border color change to de-emphasize selection and clickability for better readability. (3) Text color remains the same as in the enabled state and should pass 4.5:1 color contrast rules. (4) Icon color change to keep embedded icons for context but display that icons are not interactive with color and cursor changes.

Read-only state structure and spacing

Components should maintain the same structure and spacing used in the component's enabled state. In most cases, elements in the enabled state are present in the read-only state.

Read-only icon signifier color token

Signifier icons included in a component's enabled state, like chevron arrow icons, close icons, and calendar icons, should use the `$icon-disabled` color token in read-only states.

Default versus fluid component field backgrounds in read-only

The default style component field background colors blend in with the overall UI or layer background for read-only states, whereas fluid component field backgrounds retain the same enabled state background color.

Read-only state cursor interaction

The arrow cursor reinforces that a component is in a read-only state and is not interactive. The cursor's state reflects a component's shift in focus from interactive to informative.

Read-only keyboard accessibility

Interactive operations included in a component's enabled state should be removed or modified for its read-only state. The component should remain navigable with a keyboard.

Read-only content considerations

Components should include the same content used in the component's enabled state. However, when the content in the enabled state is instructive, like a dropdown with no current selection, the content may need to change to be informative.

Read-only accessibility: navigation versus operation

A component that can be reached by keyboard is navigable. Read-only components remain navigable so that users can review the information they contain. Read-only components are not operable, meaning users can neither manipulate nor alter their values. This contrasts with disabled components, which cannot be reached by a keyboard.

Read-only state best practice: disabled state readability

Do not use a disabled state for components if they need to be read by the user. Unlike read-only states, disabled states are not read by screen readers and do not pass visual contrast, making them inaccessible if they need to be interpreted.

Read-only state best practice: disabled states in read-only views

Maintain a component's disabled state when in a read-only view. Do not change a component's state from disabled to read-only because of an active read-only view, as some states should remain disabled depending on the use case.

Give your agent this brain