Include aria-label as part of the Declarative API's toolparamdescription sources #286

Activity

1. mlmrx commented on Sep 3, 2026

   

   mlmrx

   on Sep 3, 2026

   Contributor

   More actions

   The aria-label-only case is worth covering, but I think defining a new <label> → aria-label → aria-description priority would make the generated schema disagree with the control's accessibility semantics.

   The Accessible Name and Description Computation already handles these sources and gives aria-labelledby precedence, then aria-label, then the host-language label. In particular, an explicit aria-label can intentionally override a visible <label>, while the proposed order would do the opposite and would omit aria-labelledby entirely. The same specification has a separate accessible-description computation, where aria-describedby precedes aria-description.

   A more interoperable direction may therefore be to define the fallback in terms of the control's computed accessible name (and, if needed, its computed accessible description), rather than reading individual ARIA attributes in a WebMCP-specific order. That would also give #66's multiple-label case and aria-labelledby a defined result.

   There is still a schema-mapping decision to make: #67 asks whether the short label/accessibility name belongs in JSON Schema title rather than description, while the longer accessible description maps more naturally to description. Since the declarative synthesis algorithm remains a TODO in #210, I don't think a code PR is safe until that mapping is resolved.
2. sawyer-stripe commented on Sep 3, 2026

   

   sawyer-stripe

   on Sep 3, 2026

   Author

   More actions

   define the fallback in terms of the control's computed accessible name

   Yes, this is a better way of describing the behavior I'd be expecting (sorry, mixed up the suggested order in my original ticket).
3. domfarolino

   added

   declarative

   on Sep 4, 2026