Declarative Pipeline stage rendering shows inconsistent ARIA semantics and keyboard focus behavior

Core Criteria for Stage Element Exposure

The decision on whether stages render as interactive controls or static text should follow three measurable criteria:

1. Functional Interactivity: If a stage can be directly manipulated (collapsed, renamed, or has associated actions), ARIA role=button or button semantics are required. Static display-only stages may use generic text nodes.
2. Screen Reader Context: Every stage element must expose at minimum aria-label with stage name and position (e.g., \"Stage 2 of 5: Build\"). Use aria-describedby to link to any status or error messages.
3. Keyboard Operability: Interactive stages must be focusable via tabindex=0 and respond to Enter/Space activation. Non-interactive stages should omit tabindex to avoid spurious focus stops.

Stabilizing Keyboard Focus Order

Focus order in the Blue Ocean visual editor can be stabilized without committing to a specific stage rendering model by:

• Defining a fixed tab sequence: editor toolbar → stage list → canvas → properties pane. Use aria-flowto to explicitly guide tab navigation between disjoint regions.
• Avoiding dynamic tabindex manipulation during render. Instead, manage focus programmatically with focus() calls after state changes, and return focus to the originating element when interactions complete.
• Applying role=document to the canvas container and using aria-roledescription=\"pipeline canvas\" to provide semantic context without altering underlying element roles.

Stakeholders Requiring Alignment

Before proposing upstream changes, the following stakeholders must align on accessibility semantics:

• Blue Ocean UI maintainers – to adopt consistent ARIA patterns across canvas and sidebar components.
• Declarative Pipeline plugin authors – to ensure stage rendering hooks support accessibility attributes without breaking existing DSL assumptions.
• Jenkins accessibility working group – to establish baseline WCAG compliance requirements for pipeline editors.
• Screen reader user representatives – to validate that proposed semantics deliver usable experience in practice.

Verification Steps

Re-confirm behavior against current Jenkins instance:

1. Enable NVDA or VoiceOver and navigate the pipeline editor using Tab and arrow keys.
2. Inspect stage elements with browser dev tools accessibility panel; verify presence of aria-label and correct role assignment.
3. Trigger stage collapse/expand actions and confirm focus returns predictably to the triggering element.