Visual improvement for readonly inputs - A11y

[AnaMontes11]

Goal

Improve the visual clarity of read-only input fields by introducing an additional visual indicator — specifically, a dashed border to better communicate their state and enhance the accessibility experience. This approach strengthens the overall a11y experience.

Context

Currently, read-only inputs in our design system use the newtralLow token as a background color to differentiate them from default inputs. However, this approach relies solely on color to indicate status, which may not be sufficient from an accessibility perspective.

According to WCAG 1.4.1, color should not be the sole visual means of conveying information or distinguishing a visual element. Therefore, we cannot rely solely on the background color to help users understand that a field is read-only; there must be an additional visual indicator.

Impact

Improved accessibility compliance: Ensures we meet WCAG 1.4.1 by adding a non-color-based visual cue.

Better UX: Reduces user confusion by making it clearer which fields are non-editable, especially in dense forms or dark mode.

Cognitive clarity: Supports users with visual or cognitive impairments who may miss color-only distinctions.

Discussion Questions

• Has this ever been flagged in an accessibility audit, or has it been considered compliant because it technically meets WCAG?

Additional considerations

This pattern is used by other systems such as VISA’s design system, and aligns with inclusive UX practices.

The solution goes beyond minimal technical compliance and moves toward a more inclusive and intuitive experience.

Do you have a visual proposal?

https://www.figma.com/design/bEZYrQYN50pZ8FViv8Es4l/pruebas?node-id=19-6246&t=PRlSdXlh84tFDqIQ-4

[AnaMontes11]

After discussing with the team, we've decided to close this discussion for now, as this specific issue has not been flagged in any accessibility audits to date.

Additionally, we acknowledge that introducing a dashed border may require further user testing, since it could overlap with other interaction patterns (e.g., drag and drop), potentially causing confusion.

That said, if in the future we decide to evolve the visual treatment of read-only inputs, we can revisit this proposal with fresh insights and testing.

Closing for now