Bitbucket merge button missing aria-disabled and keyboard focus when disabled

Question

Accessibility gap in pull-request merge control
The merge button in Bitbucket Cloud pull requests does not expose an explicit aria-disabled attribute when the button enters a disabled state. Screen readers therefore announce the control inconsistently—some read it as an ordinary button, others as unavailable—leaving users uncertain whether the action is truly blocked. Compounding the issue, keyboard navigation skips the disabled button entirely, breaking the expected tab order and preventing keyboard-only users from discovering the control or its state.
These behaviors have been observed in the current public Bitbucket Cloud UI across Chrome and Firefox with NVDA and VoiceOver. The exact conditions that trigger the disabled state (required approvals, merge checks, branch permissions) are documented, but the accessibility implementation has not been updated to match.
Open questions

Does Bitbucket plan to add aria-disabled="true" to the merge button when merge checks fail or approvals are missing?
Can the disabled merge button remain in the tab order so keyboard users can reach and inspect it?
Which ARIA pattern (alert, status, or live region) should announce the reason the merge is blocked?

Tasadduq Burney · Answer

Direct answers to your open questions

QuestionAnswer

Will Bitbucket add aria-disabled="true" when merge checks fail or approvals are missing?
This is a vendor decision, and I cannot confirm Bitbucket's roadmap. Based on your DOM observations, the current implementation appears to use the native HTML disabled attribute. The actionable path is a support ticket referencing WCAG 2.1 SC 2.1.1 (Keyboard) and 4.1.2 (Name, Role, Value).

Can the disabled merge button remain in the tab order?
Yes, but only if the native disabled attribute is replaced with aria-disabled="true". Per the HTML specification, a natively disabled button is removed from sequential focus navigation; no CSS or scripting workaround restores tab focus while disabled is present. With aria-disabled, the element stays focusable, and JavaScript must suppress activation instead.

Which ARIA pattern should announce the block reason?
None of alert, status, or live region. The WAI-ARIA guidance for disabled controls favors aria-describedby pointing to static text (e.g., "Merge blocked: 2 approvals required"). Live regions announce on change, which creates noise for a persistent control state and can fire on every re-render.

Why the current behavior occurs
The two symptoms you describe follow directly from the native disabled attribute rather than from a Bitbucket-specific defect:

Keyboard skip: disabled form controls are excluded from the tab order by the browser, so keyboard-only users cannot reach or inspect the merge button.
Inconsistent announcements: screen readers handle natively disabled buttons differently — NVDA and VoiceOver may say "unavailable," "dimmed," or omit the control depending on version, browse/focus mode, and verbosity settings.

This is well-established platform behavior. What is uncertain is Bitbucket's exact markup; the distinction below matters for the fix.
Verification you can perform today

Open a pull request where merging is blocked.
Inspect the merge button in DevTools: note whether it carries disabled, aria-disabled, or tabindex="-1".
Tab through the page and record whether focus lands on the button.
With NVDA or VoiceOver running, note the exact announcement when the button is reached by other means (e.g., virtual cursor).

One diagnostic detail needed
Does the button carry tabindex="-1" in addition to (or instead of) the native disabled attribute? If it is purely disabled, an attribute swap to aria-disabled="true" plus aria-describedby is the whole fix. If explicit tabindex management is also involved, focus handling code must change too — which affects what you ask for in the support ticket.

Bitbucket merge button missing aria-disabled and keyboard focus when disabled

Accessibility gap in pull-request merge control

Open questions

1 answer

Direct answers to your open questions

Why the current behavior occurs

Verification you can perform today

One diagnostic detail needed

Your perspective belongs here.

0 question comments

Question	Answer
Will Bitbucket add `aria-disabled="true"` when merge checks fail or approvals are missing?	This is a vendor decision, and I cannot confirm Bitbucket's roadmap. Based on your DOM observations, the current implementation appears to use the native HTML `disabled` attribute. The actionable path is a support ticket referencing WCAG 2.1 SC 2.1.1 (Keyboard) and 4.1.2 (Name, Role, Value).
Can the disabled merge button remain in the tab order?	Yes, but only if the native `disabled` attribute is replaced with `aria-disabled="true"`. Per the HTML specification, a natively disabled button is removed from sequential focus navigation; no CSS or scripting workaround restores tab focus while `disabled` is present. With `aria-disabled`, the element stays focusable, and JavaScript must suppress activation instead.
Which ARIA pattern should announce the block reason?	None of alert, status, or live region. The WAI-ARIA guidance for disabled controls favors `aria-describedby` pointing to static text (e.g., "Merge blocked: 2 approvals required"). Live regions announce on change, which creates noise for a persistent control state and can fire on every re-render.