Elasticsearch Response Metadata and Kibana Live Regions: Splitting Accessibility Responsibility at the API Boundary

Integration boundary

Elasticsearch exposes a REST API that returns search responses, mappings, validation errors, and deprecation metadata as structured data. Kibana transforms those responses into user-facing screens, forms, tables, and notifications. The unresolved decision is where accessibility responsibility ends at this API boundary: whether Elasticsearch should supply stable, machine-readable error codes and field labels that assistive technology can announce predictably, or whether Kibana alone should add all required UI semantics such as ARIA roles, live-region announcements, and focus order.

Dynamic Elasticsearch content frequently becomes visible text in Kibana. Index names, field names, mapping types, shard counts, validation errors, and deprecation warnings may be rendered verbatim or transformed before display. Because Elasticsearch error wording, deprecation output, and response shapes can change across releases while Kibana accessibility fixes ship on separate UI cadences, the interoperability behavior is version-sensitive and difficult to guarantee with a single check.

A practical unresolved behavior is the method by which Kibana should announce asynchronous search failures and deprecation notices derived from Elasticsearch without stealing focus, duplicating announcements, or exposing raw JSON to screen-reader users. Which component should own the accessible name and role for dynamic values such as field names and mapping types when they appear in Kibana forms, tables, and notifications? Should Elasticsearch provide stable, machine-readable error codes and deprecation metadata specifically for assistive technology, or should Kibana transform all raw responses into accessible UI semantics? What approach should Kibana use to announce asynchronous search failures and deprecation notices without stealing focus or duplicating announcements?