Wizard: only offer image mode on RHEL 10 hosts

[lucasgarfield]

Image mode is disabled with an explanatory tooltip on non-RHEL-10 hosts, since only RHEL 10 official images ship today.

• Disable the image mode toggle on non-RHEL-10 hosts, tooltip explains RHEL-10-only support (CentOS Stream/Fedora coming soon)
• Model host distro as unknown until the check resolves — toggle starts disabled without the tooltip, so RHEL 10 users don't see a "coming soon" flash and other hosts don't get a window to enter an unsupported mode
• Hosted service is unaffected

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src/Components/CreateImageWizard/steps/ImageOutput/components/BlueprintMode.tsx" line_range="108-117" />
<code_context>
-          }}
-          aria-describedby='blueprint-mode-description'
-        />
+        {!isImageModeSupported && isHostDistroKnown ? (
+          // Disabled buttons don't emit hover events, so the tooltip
+          // needs a wrapper element as its trigger.
+          <Tooltip content='Image mode is currently available only on RHEL 10 hosts. Support for CentOS Stream and Fedora is coming soon.'>
+            <span
+              className='image-mode-toggle-wrapper'
+              data-testid='image-mode-toggle-wrapper'
+            >
+              {imageModeToggle}
+            </span>
+          </Tooltip>
+        ) : (
+          imageModeToggle
+        )}
       </ToggleGroup>
</code_context>
<issue_to_address>
**suggestion:** Tooltip wrapper around a disabled button might benefit from explicit accessibility handling.

Because the tooltip trigger is a non-semantic `<span>` wrapping a disabled control, assistive tech may not expose the tooltip or the disabled state correctly. Consider either giving the wrapper an appropriate role/ARIA attributes, or keeping the inner button focusable (e.g., `aria-disabled` with click prevention) so the tooltip and disabled state are properly announced for keyboard and screen-reader users.

Suggested implementation:

```typescript
        {!isImageModeSupported && isHostDistroKnown ? (
          // Disabled buttons don't emit hover events, so the tooltip
          // needs a wrapper element as its trigger.
          // Make the wrapper a semantic, focusable control so the tooltip
          // and disabled state are exposed to assistive technologies.
          <Tooltip content='Image mode is currently available only on RHEL 10 hosts. Support for CentOS Stream and Fedora is coming soon.'>
            <span
              className='image-mode-toggle-wrapper'
              data-testid='image-mode-toggle-wrapper'
              role='button'
              aria-disabled='true'
              aria-label='Image mode toggle (unavailable for this host)'
              tabIndex={0}
            >
              {imageModeToggle}
            </span>
          </Tooltip>
        ) : (
          imageModeToggle
        )}

```

Depending on how `imageModeToggle` is implemented elsewhere in this file, you may want to:
1. Ensure that the inner toggle is actually disabled *only* via `aria-disabled` (and click prevention) instead of the native `disabled` attribute, so that the control remains reachable by keyboard while still being announced as disabled.
2. If you switch to `aria-disabled`, make sure to prevent activation for unsupported hosts in the `onClick` handler (and optionally `onKeyDown` for Space/Enter) to preserve the disabled behavior while enabling consistent tooltip announcement for keyboard and screen-reader users.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion: Tooltip wrapper around a disabled button might benefit from explicit accessibility handling.

Because the tooltip trigger is a non-semantic <span> wrapping a disabled control, assistive tech may not expose the tooltip or the disabled state correctly. Consider either giving the wrapper an appropriate role/ARIA attributes, or keeping the inner button focusable (e.g., aria-disabled with click prevention) so the tooltip and disabled state are properly announced for keyboard and screen-reader users.

Suggested implementation:

        {!isImageModeSupported && isHostDistroKnown ? (
          // Disabled buttons don't emit hover events, so the tooltip
          // needs a wrapper element as its trigger.
          // Make the wrapper a semantic, focusable control so the tooltip
          // and disabled state are exposed to assistive technologies.
          <Tooltip content='Image mode is currently available only on RHEL 10 hosts. Support for CentOS Stream and Fedora is coming soon.'>
            <span
              className='image-mode-toggle-wrapper'
              data-testid='image-mode-toggle-wrapper'
              role='button'
              aria-disabled='true'
              aria-label='Image mode toggle (unavailable for this host)'
              tabIndex={0}
            >
              {imageModeToggle}
            </span>
          </Tooltip>
        ) : (
          imageModeToggle
        )}

Depending on how imageModeToggle is implemented elsewhere in this file, you may want to:

1. Ensure that the inner toggle is actually disabled only via aria-disabled (and click prevention) instead of the native disabled attribute, so that the control remains reachable by keyboard while still being announced as disabled.
2. If you switch to aria-disabled, make sure to prevent activation for unsupported hosts in the onClick handler (and optionally onKeyDown for Space/Enter) to preserve the disabled behavior while enabling consistent tooltip announcement for keyboard and screen-reader users.

[codecov]

Codecov Report

❌ Patch coverage is 95.23810% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 79.01%. Comparing base (78776f1) to head (eba1d52).

Files with missing lines	Patch %	Lines
...ard/steps/ImageOutput/components/BlueprintMode.tsx	95.23%	1 Missing ⚠️

@@                        Coverage Diff                         @@
##           lucas/cockpit/6-optional-users    #4740      +/-   ##
==================================================================
- Coverage                           79.09%   79.01%   -0.08%     
==================================================================
  Files                                 265      265              
  Lines                                7021     7028       +7     
  Branches                             2546     2588      +42     
==================================================================
  Hits                                 5553     5553              
- Misses                               1372     1376       +4     
- Partials                               96       99       +3     

Flag	Coverage Δ
playwright	59.58% <44.44%> (-0.39%)	⬇️
vitest	74.07% <76.19%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ard/steps/ImageOutput/components/BlueprintMode.tsx	95.45% <95.23%> (-1.85%)	⬇️

... and 6 files with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78776f1...eba1d52. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lucasgarfield]

Replaced by #4756