a11y(fuselage): make PasswordInput visibility toggle keyboard accessible

Description

The PasswordInput component currently uses a clickable <Icon> as the password visibility toggle.

In packages/fuselage/src/components/PasswordInput/PasswordInput.tsx, the visibility control is implemented as:

<Icon
  name={hidden ? 'eye-off' : 'eye'}
  size={20}
  onClick={handleAddonClick}
/>

The component also contains an existing // TODO: fix a11y issues comment.

Because the icon is not an interactive control, the password visibility toggle is difficult or impossible to use with keyboard navigation and does not provide an accessible name to screen readers.

Current behavior

The password visibility toggle:

• Cannot be reached using the Tab key.
• Cannot be activated using standard keyboard controls such as Enter or Space.
• Does not expose button semantics to assistive technologies.
• Does not provide an accessible name describing the action being performed.
• Only exposes the interaction through the icon's onClick handler.

Steps to reproduce

1. Render a PasswordInput component.
2. Focus the password input using keyboard navigation.
3. Press Tab to move to the next interactive element.
4. Observe that the password visibility toggle cannot be focused.
5. Inspect the rendered toggle element and its accessibility information.

Expected behavior

The password visibility toggle should behave as a standard interactive button.

It should:

• Be reachable using Tab.

• Be activatable using Enter and Space.

• Expose button semantics to assistive technologies.

• Have an accessible name that communicates the action, for example:

  • Show password when the password is currently hidden.
  • Hide password when the password is currently visible.

• Continue updating the password input between password and text types.

Proposed solution

Use an existing interactive Fuselage component such as IconButton for the visibility toggle, with an accessible label that changes according to the current visibility state.

For example:

<IconButton
  icon={hidden ? 'eye-off' : 'eye'}
  aria-label={hidden ? 'Show password' : 'Hide password'}
  onClick={handleAddonClick}
/>

The existing // TODO: fix a11y issues comment can then be removed once the accessibility issue is resolved.

Testing

A regression test should verify that:

1. The visibility control is exposed as a button.
2. The button has the appropriate accessible label.
3. Activating the button changes the input type from password to text.
4. The accessible label changes from Show password to Hide password.
5. The control can be activated through keyboard interaction.

Manual verification with keyboard navigation and a screen reader would also be useful.

Related code

packages/fuselage/src/components/PasswordInput/PasswordInput.tsx

The component currently contains an explicit // TODO: fix a11y issues comment, which appears to be directly related to this behavior.

Acceptance criteria

• Password visibility toggle is keyboard focusable.
• Toggle can be activated using keyboard controls.
• Toggle exposes button semantics.
• Toggle has a meaningful accessible name.
• Accessible name reflects the current action (Show password / Hide password).
• Existing password visibility functionality continues to work.
• Regression tests are added for the accessibility behavior.
• Existing accessibility TODO is removed after the fix.

Before clicking "Create": make sure your repository search really confirms there isn't already an issue/PR for this exact PasswordInput accessibility problem. If that's confirmed, this is a solid first issue to raise.

Start with packages/fuselage/src/components/PasswordInput/PasswordInput.tsx, then locate the component’s test entry point and inspect existing Fuselage interactive controls. Done means the visibility control is keyboard-operable with button semantics and state-appropriate labeling, its visibility behavior remains intact, and regression coverage verifies these states.