Jira Cloud accessibility: choosing WCAG 2.2 focus‑visible vs WCAG 2.1 AA for issue‑creation modal

Adopting WCAG 2.2's focus-visible criterion will not, by itself, fix the three defects you describe. Focus-visible is a styling/visibility requirement (SC 2.4.11/2.4.13 in WCAG 2.2 refine how keyboard focus is indicated and ensure it isn't obscured); it does not repair a broken tab order, a missing focus-return on Escape, or low-contrast icons. Those are separate failures under WCAG 2.1 AA already — SC 2.4.3 (Focus Order), SC 2.1.2 (No Keyboard Trap, and the de-facto focus-return expectation for modals), and SC 1.4.3/1.4.11 (Contrast). So the honest answer to the design ticket is: fix the defects first, then decide the baseline.

Impact on Tab order and focus return

Focus-visible changes only which focus indicator is shown (keyboard-triggered focus vs. pointer-triggered focus). It does not reorder the DOM. If Tab skips the description field today, the cause is almost certainly one of:

• a tabindex="-1" or missing tabindex on the rich-text wrapper,
• the editor mounting asynchronously after the modal's initial focus trap is calculated, or
• a positive tabindex elsewhere distorting the sequence.

Applying :focus-visible styles can actually mask this: if focus is programmatically moved to the description field, it will look correctly focused while keyboard users still can't reach it. Verify the DOM order directly:

// In DevTools console, with the modal open:
const els = [...document.querySelectorAll(
  '[role="dialog"] button, [role="dialog"] textarea, [role="dialog"] [tabindex]'
)];
els.forEach(e => console.log(e.tabIndex, e.getAttribute('aria-label') || e.id));

For the Escape/focus-return issue, the modal should store document.activeElement on open and restore it on close. Focus-visible doesn't change this logic, but if your new styles only apply to :focus-visible and the browser heuristics classify the restored focus as non-keyboard, the Create button may receive focus without a visible indicator — a regression you'd only catch by manual keyboard testing, not by axe.

Screen-reader announcement consistency

Focus-visible has no direct effect on announcements. NVDA/JAWS/VoiceOver announce based on the accessibility tree: the field's aria-label/aria-labelledby, role, and where focus actually lands. The risk is indirect: if you fix the tab order (moving the description field earlier in the DOM), the announcement sequence when the modal opens may change, and any ARIA live-region or aria-describedby on the dialog should be re-tested. Test with NVDA + Chrome and VoiceOver + Safari after the DOM fix, not after the CSS change.

Cloud vs Data Center trade-offs

This is the real constraint. :focus-visible is supported in all current evergreen browsers, but Data Center/Server deployments often run older Atlassian front-end stacks and must support customer-pinned older browsers. Options:

• Dual baseline: target WCAG 2.2 AA for Cloud, keep 2.1 AA for DC, sharing component code but gating the focus-visible styles behind a feature flag or media/supports query.
• Polyfill: the focus-visible polyfill adds a class-based fallback, but it adds JS weight and can lag on rapid Tab presses.
• Conservative CSS: style both :focus and :focus-visible identically. You lose the "hide outline on mouse click" refinement but keep one code path that works everywhere — often the pragmatic choice for an enterprise product.

The low-contrast priority icons flagged by axe are orthogonal: fix them with color changes against SC 1.4.11 (non-text contrast, 3:1) regardless of which baseline you pick.

Recommendation

1. Fix tab order, Escape focus-return, and icon contrast now — all are WCAG 2.1 AA failures today.
2. Adopt WCAG 2.2 AA as the Cloud target; it is backward-compatible in the sense that 2.2 conformance implies 2.1 conformance (with the narrow exception of the removed SC 4.1.1 parsing criterion).
3. For Data Center, use the shared :focus, :focus-visible styling approach so behavior doesn't diverge.
4. Verify with axe core (expect zero new violations), full keyboard-only pass (Tab reaches description; Escape returns focus to Create with a visible indicator), and NVDA/VoiceOver announcement order.

One caveat worth flagging for review: exact success-criterion numbering and Jira's current front-end behavior vary by release, so confirm against the WCAG 2.2 recommendation text and your specific Jira Cloud/DC versions before committing the design ticket.