Skip to content

fix(a11y): use accessible amber for limited-mode button text#942

Open
aramb-dev wants to merge 4 commits into
jordanbaird:macos-26from
aramb-dev:fix/onboarding-yellow-accessibility
Open

fix(a11y): use accessible amber for limited-mode button text#942
aramb-dev wants to merge 4 commits into
jordanbaird:macos-26from
aramb-dev:fix/onboarding-yellow-accessibility

Conversation

@aramb-dev
Copy link
Copy Markdown

Replaces inaccessible .yellow with a darker amber color on the permissions onboarding "Continue in Limited Mode" button for readable contrast against the light background.

The .yellow color on the 'Continue in Limited Mode' button text failed
accessibility contrast requirements against the light button background.
Replace with a darker amber (0.75, 0.45, 0) for readable contrast while
maintaining the warning/limited-mode semantic intent.
Copilot AI review requested due to automatic review settings May 6, 2026 12:41
aramb-dev added 2 commits May 6, 2026 08:43
… text

Replace hardcoded RGB with a named color (LimitedModeButtonColor) in the
Asset Catalog, providing distinct Light and Dark appearance values for
proper contrast across system themes.
Drop the light-mode LimitedModeButtonColor from srgb(0.75, 0.45, 0)
to srgb(0.55, 0.32, 0) to reach ~4.5:1 contrast on light button
backgrounds. Dark-mode value unchanged.
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adjusts the foreground color used for the “Continue in Limited Mode” button label in the permissions onboarding flow to improve readability/contrast versus the prior .yellow styling.

Changes:

  • Replaces .yellow text styling with a darker amber RGB color when permissionsState == .hasRequired.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 24 to 28
case .hasAll:
AnyShapeStyle(.primary)
case .hasRequired:
AnyShapeStyle(.yellow)
AnyShapeStyle(Color("LimitedModeButtonColor"))
}
Add Increased Contrast appearances to the Asset Catalog colorset so
the limited-mode button text remains accessible when users enable
high-contrast accessibility settings.
emindeniz99 pushed a commit to emindeniz99/Ice that referenced this pull request May 13, 2026
…a11y amber)

* Updates.swift — when Sparkle wants to show a scheduled update
  prompt while Ice is in the background, activate the app with a
  regular policy and return `true` so the dialog comes up in front
  with key focus. Previously we returned `false` and Sparkle put the
  dialog up anyway, with Ice still .accessory — on macOS 26 the
  window then refused to accept clicks, which is the cluster of
  reports in jordanbaird#912 / jordanbaird#926 / jordanbaird#931 / jordanbaird#932 / jordanbaird#937. Same fix is applied
  to `standardUserDriverWillHandleShowingUpdate` for the
  user-initiated path. (Adapted from arifim's PR jordanbaird#945.)

* PermissionsView.swift — replace plain `.yellow` on the
  "Continue in Limited Mode" button with a darker amber
  (sRGB 0.75/0.45/0). The original failed accessibility contrast
  against the light button background. (Adapted from aramb-dev's
  PR jordanbaird#942 — the asset-catalog refinement in later commits of that
  PR is deferred since the current Xcode-26 sync of the project
  doesn't include the new colorset directory.)

Skipped this round:

* PR jordanbaird#940 (lilaflo) is an 80-commit re-application of
  jordanbaird/macos-26 onto another branch — same commits we
  already carry, nothing new.

* PR jordanbaird#944 (aathanwwt) targets CompactSlider 2.x's removed
  `gestureOptions:` parameter. Package.resolved locks us at 1.2.1
  with the upper bound at <2.0, so the parameter still exists in
  the version we ship.

* PR jordanbaird#941 (lixiaoning) notch-auto-hide. The diff references
  `MenuBarItem.info`, `MenuBarItemTag.iceIcon`,
  `controlItem.state == .hideItems`, and several private flags
  (`isMovingItem`, `isMouseButtonDown`, `tempShownItemContexts`,
  `itemMoveCount`) that don't exist in the macos-26 refactor of
  MenuBarItemManager. Adapting it would mean rewriting the helper
  against a different cache architecture, which I shouldn't do
  without a notched display to verify against. The negative
  windowNumber guard in the same PR is a no-op for us because we
  don't read `NSWindow.windowNumber` anywhere in the macos-26
  branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants