API Server OpenAPI Spec Extensions and Client‑Side Tool Accessibility: Interoperability Question

The goal is to allow client‑side tools such as kubectl, the Kubernetes Dashboard, or custom UIs to generate accessible interfaces for screen‑reader users by leveraging accessibility metadata exposed in the OpenAPI specification served by the API server.

Constraints include preserving backward compatibility with existing clients, limiting the growth of the OpenAPI document, ensuring a consistent interpretation of extension fields across diverse tooling, and aligning with Kubernetes versioning and deprecation policies.

Uncertainty remains about whether the API server should augment its schema with accessibility‑focused extensions (e.g., x‑aria‑label, x‑role) and how clients should detect, interpret, and apply those extensions to produce audible or tactile feedback for assistive technologies.

Should the API server include accessibility extension fields in its OpenAPI spec?
How should client‑side tools consume and expose those extensions to screen‑reader users?
What versioning strategy would ensure that adding such extensions does not break existing clients?