Limits of the Prometheus Expression Browser Accessibility

The decision to retain the current Go template-based UI or migrate to a client-side framework should be guided by the trade-off between operational simplicity (low overhead) and inclusive design (accessibility). Because Prometheus is often deployed in resource-constrained environments or as a sidecar, any increase in binary size or runtime memory consumption directly impacts the tool's core value proposition of stability and minimalism.

Architectural Trade-offs

The following table outlines the primary technical tensions involved in this transition:

Metric	Current Go Templates (SSR)	Modern Frontend (CSR)
Binary Size	Minimal; templates are embedded.	Increased; requires bundled JS/CSS assets.
Client Overhead	Low; browser renders static HTML.	Higher; JS execution and DOM reconciliation.
Accessibility	Limited; manual ARIA implementation.	High; robust ARIA and focus management.
Complexity	Single binary, no frontend pipeline.	Dual-track build (Go + Node/Webpack).

Evaluating Impact on Resource-Constrained Deployments

To determine if a modern frontend is viable without compromising the "low-overhead" goal, the project can use the following verification steps:

• Binary Footprint Analysis: Compare the current binary size against a prototype build that bundles a lightweight framework (e.g., Preact or Alpine.js) to quantify the exact increase in megabytes.
• Browser Memory Profiling: Use Chrome DevTools Memory tab to compare the heap snapshot of the current SSR page versus a CSR version when rendering large query result sets.
• Accessibility Auditing: Run axe-core or Lighthouse on the current Expression Browser to create a baseline of accessibility failures, ensuring that any proposed framework actually solves the identified gaps rather than just adding bulk.

Uncertainties and Assumptions

This analysis assumes that the primary goal is to maintain a single-binary distribution. If the project moves toward a decoupled architecture where the UI is hosted separately from the Prometheus server, the binary size trade-off becomes irrelevant, but the operational complexity of managing two deployments increases.

Missing Diagnostic Detail: Are there specific screen-reader failure reports or compliance mandates (e.g., WCAG 2.1) that the current UI is failing to meet? Knowing the specific accessibility gaps would determine if a full framework migration is necessary or if targeted ARIA additions to the Go templates would suffice.