Design: invalid visualisation for list and menu items

[TommyLindh2]

Background

In #4026 and #4028 we added an invalid flag to Chip and ListItem.
The flag is forwarded end-to-end only when a ListItem is rendered as a
chip (i.e., inside limel-picker). Plain limel-list, limel-list-item,
and limel-menu surfaces currently ignore ListItem.invalid — it has no
visual effect there.

This leaves an API smell: consumers can set invalid: true on a
ListItem and be surprised when nothing changes in a list/menu context.

Questions to resolve

Visual design

The chip's invalid style (red background + chessboard pattern, white
text) is intentionally loud because chips are small and discrete.
Stamping the same style onto a full-width list row would look jarring.
We need to decide on a subtler treatment for lists/menus. Options:

• Left border accent in red
• Muted red background tint
• Inline error icon at the end of the row
• Red text colour on the primary label
• Some combination of the above

Interaction rules

• Is an invalid list item still selectable? (My lean: yes — the user
  should be able to pick an invalid item to replace/fix it, or navigate
  past it.)
• How does invalid interact with the existing disabled flag? They
  are semantically different (disabled = can't interact; invalid = can
  interact but flagged). Both set together: disabled should win
  visually.

Scope of components

Which surfaces should honour ListItem.invalid?

• limel-list
• limel-list-item
• limel-menu / limel-menu-list
• limel-select (when rendering the selected option)
• Anywhere else that renders a ListItem?

Accessibility

• Apply aria-invalid="true" to the list item element.
• Consider aria-errormessage linkage if per-item error text is added
  later.

Once designed

When there's agreement, implement and update the JSDoc on
ListItem.invalid to drop the "chip only" caveat.

Related

• chip-set: expose invalid state per chip #4026 — chip-set per-chip invalid
• picker: expose invalid state per list item #4028 — picker per-item invalid