Textarea

Every <rh-textarea> must have an accessible name. Use one of the following approaches:

1. External <label> element (recommended)

   • associate a <label> with the textarea using for and id. The component wires the label to the inner textarea via ariaLabelledByElements. See the default demo for an example.

2. accessible-label attribute: use when no visible label is present.

<rh-textarea accessible-label="Additional comments"></rh-textarea>

Users may also add an aria-label or aria-labelledby attribute on the host. aria-label overrides all other label sources; aria-labelledby takes priority over associated <label> elements and accessible-label.

Both disabled and readonly prevent editing, but they differ in important ways:

• Disabled uses aria-disabled (not native disabled) so the textarea remains focusable for assistive technology users. Disabled textareas are excluded from form submission. The element receives pointer-events: none and muted visual styling.
• Readonly prevents editing but keeps the value submittable. The textarea is fully focusable and interactive for text selection.

Always set ARIA attributes (e.g. aria-invalid, aria-label, aria-labelledby) on the <rh-textarea> host element. The component is a form-associated custom element, so the browser forwards host ARIA attributes to assistive technologies via ElementInternals.

The state attribute (danger, warning, success) controls visual feedback only and does not set aria-invalid. When you have a validation error, set both so sighted and screen reader users get the same information:

• state="danger" + help-text="..." for the visual cue
• aria-invalid="true" on the host for assistive tech

This keeps a single source of truth for validity in your code. For implementation details, see Validation and error state on the Code page.

• If a textarea does not have an associated <label> element, an accessible-label attribute is required.
• Help text content (via help-text attribute or help-text slot) is automatically linked to the control via ariaDescribedByElements so screen readers announce it.

Learn to use the accessibility semantics defined by the Accessible Rich Internet Application (ARIA) specification to create accessible web experiences.

Understanding documents provide detailed explanations for Web Content Accessibility Guidelines (WCAG) guidelines and success criteria.

• SC 1.3.1 Info and relationships (Level A)

• SC 2.1.1 Keyboard (Level A)

• SC 2.1.3 Keyboard (no exception) (Level AAA)

• SC 2.4.3 Focus order (Level A)

• SC 2.4.7 Focus visible (Level AA)

• SC 2.5.5 Target size (Level AAA)