ArgoCD v2.10 UI Accessibility: Systematic Audit vs. Community-Driven Fixes

Context

ArgoCD's web UI, overhauled in v2.0 and current in v2.10, exhibits known accessibility gaps: missing ARIA labels on key controls, insufficient color contrast in the default theme, and limited keyboard navigation for application trees and log streaming. The project has not published a formal WCAG or Section 508 conformance statement, and no dedicated accessibility milestone appears on the public roadmap.

Unresolved Decision

The core tension is whether to pursue a systematic accessibility audit and remediation effort—potentially requiring upstream fixes in the Ant Design component library—or continue relying on community pull requests that address isolated issues such as modal focus management. A systematic approach would demand dedicated engineering cycles that compete with GitOps core feature development, while piecemeal fixes risk leaving critical workflows non-compliant for operators who depend on the UI for sync status visualization and resource inspection.

Questions

1. Should the project adopt a version-gated accessibility target (e.g., WCAG 2.1 AA by v2.12) and allocate maintainer bandwidth accordingly?
2. Is there a viable path to upstream Ant Design accessibility debt without blocking ArgoCD releases?
3. Can automated regression testing with axe-core be integrated into the CI pipeline to prevent regressions in keyboard navigation and contrast ratios?