feat: FieldInput ARIA

[mikeharv]

The basics

• I validated my changes

The details

Resolves

Fixes #9656

Proposed Changes

Implements foundational ARIA support for input fields, including text input and number fields.

Key changes:

• Implemented default ARIA behavior in FieldInput:
  • Provides a default type ("input field") if none is specified with the block definition
  • Ensures a non-empty ARIA value (uses localized placeholder for empty strings)
  • Adds a private recomputeAriaContext() helper to:
    • Set role="button"
    • Set aria-label using computeAriaLabel
    • Prefix labels with localized "Edit" text when editable
    • Hide fields in flyouts via aria-hidden
• Wired ARIA updates to lifecycle events:
  • initView
  • doValueUpdate_
  • doValueInvalid_
• Updated field text elements to be aria-hidden since they are represented via ARIA labels
• Added new message strings:
  • FIELD_LABEL_EMPTY
  • FIELD_LABEL_EMPTY_INPUT
  • ARIA_TYPE_FIELD_INPUT
  • FIELD_LABEL_EDIT_PREFIX

Reason for Changes

This change establishes a baseline pattern in FieldInput so that fields have meaningful default accessibility behavior without requiring every implementation to solve the same problems independently. It ensures that ARIA labeling stays in sync with field state and that fields communicate their interactivity in a predictable way.

At the same time, this approach intentionally leaves room for customization, allowing specific field types to provide more tailored or context-aware accessibility behavior where needed.

Test Coverage

Added unit tests for ARIA behavior on:

• FieldTextInput
• FieldNumber

Tests cover:

• Role assignment (button)
• Visibility handling (aria-hidden in flyouts)
• Default and updated ARIA labels
• Presence/absence of "Edit" prefix based on editability
• Label updates when field values change

Manual testing was also performed in a rendered workspace to verify:

• ARIA labels update correctly when editing fields
• Screen readers announce expected values

Documentation

New methods include TSDocs.

Additional Information

• This PR establishes the base pattern for ARIA support; additional field types (e.g. dropdowns, checkboxes, images) will implement these APIs in follow-up changes.

[gonfunko]

What's the difference between these two?

[mikeharv]

There isn't a difference, except that one is for the base field class. I wasn't sure if we should keep them distinct in case they diverge, for example if the new one changes to something like "empty input".