Add prop to keep GlButton accessible when disabled

Adam Ferchrequested to merge
button-dimmed-support into main

What does this MR do?

Changes <gl-button disabled> so that internally it produces an aria-disabled="true" button instead of a native disabled button. The public API doesn't change, consumers continue to write <gl-button disabled> and <gl-button :disabled="someCondition">. Only the rendered output and behavior change.

Buttons rendered this way:

  • Stay in the tab order, so keyboard users can reach them
  • Are announced by screen readers as inactive (and appear in the SR form-controls menu instead of being skipped)
  • Continue to no-op on click (handled in JS, the same way GlButton already handles loading)
  • Render the same dimmed visual state and not-allowed cursor as before

Why this is the right default

Following the framing from Trevor (a11y), inactive buttons fall into three tiers:

  1. No disabled button, use error handling or messaging. Best where feasible.
  2. aria-disabled="true", focusable, announced, present in SR form-controls menus. The right default for "this action isn't currently available."
  3. Native disabled, fully removed from the a11y tree and tab order. A justified escape hatch only, not a default.

GlButton's previous behavior put consumers on tier 3 by default, making inactive buttons invisible to keyboard and SR users. This MR moves the default to tier 2.

What's not in this MR

  • No public API change. <gl-button disabled> is still a boolean prop.
  • No migration. Existing consumers get the new behavior automatically.
  • No dimmed terminology. Earlier drafts introduced a dimmed prop value; team feedback (Scott, Thomas, Trevor) converged on dropping it once aria-disabled is the default, "dimmed" is an internal styling detail, not a consumer-facing concept.
  • Compound components (GlButtonGroup, GlSegmentedControl, GlTabs) inherit this behavior automatically; no changes needed there.

Side benefit: tooltips on disabled buttons

Today's docs instruct consumers to wrap disabled buttons in a focusable element to support tooltips and popovers, because native disabled blocks hover and focus. With aria-disabled, that wrapper pattern goes away — tooltips and popovers can attach directly to the button.

Closes #3466

Screenshots or screen recordings

N/A — 'dimmed' is visually identical to disabled by design, :focus ring is unchanged. The accessibility tree is what changes.

Integrations

No integration MR required — change is additive and backwards-compatible. Downstream consumers (GlButtonGroup, GlSegmentedControl, GlTabs) will be addressed in separate MRs once this lands.

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Conformity

  • The “What does this MR do?” section in the MR description is filled out, explaining the reasons for and scope of the proposed changes, per “Say why not just what”.
    • For example, if the MR is focused on usage guidelines, addressing accessibility challenges could be added in a separate MR.
  • Relevant label(s) are applied to the MR.
  • The MR is added to a milestone.
  • Added the ~"component:*" label(s) if applicable.
  • A changeset is added when this MR will do a patch, minor, or major update. More information can be found in doc/publishing-packages.md.

Components

  • GitLab UI's contributing guidelines.
  • If the MR changes a component's API, integration MR(s) have been opened (see integrations above).

Documentation

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

  • All actions and functionality can be done with a keyboard.
  • Links, buttons, and controls have a visible focus state.
  • All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
  • Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
  • Color combinations have sufficient contrast.
Edited by Mark Florian

Merge request reports