›_ Claude Code Issues
Claude Code Issues / #35257

Accessibility: 22 unlabeled icon-only buttons missing aria-labels (WCAG 4.1.2)

Resolved 💬 3 comments Opened Mar 17, 2026 by HasanTayem Closed Mar 20, 2026

Summary

The Claude Code desktop app (Windows, v1.1.2102) has 22 buttons that lack accessible names, and the message input field does not work correctly with NVDA screen reader. These issues make the app difficult to use with assistive technologies.

Environment

  • App: Claude Desktop v1.1.2102 (Electron)
  • OS: Windows 11 Pro (10.0.26200)
  • Screen readers tested: NVDA 2025.3.3, Windows Narrator (latest, bundled with Windows 11 26200)
  • Testing method: Windows UI Automation API (System.Windows.Automation), manual testing with NVDA and Narrator

Daily Workflow Impact

As a screen reader user, every interaction with Claude Desktop requires extra steps that sighted users never encounter:

  1. Opening the app: Sidebar buttons (rename, delete, options on conversations) are announced as just "button" with no indication of what they do. Managing conversations is guesswork.
  2. Typing a message: NVDA stays in Browse Mode on the message input. Pressing Enter or Space (the standard way to activate an editable field) does nothing. The user must press Insert+Space every single time to toggle Focus Mode manually before typing.
  3. Navigating the UI: Multiple interactive elements have no accessible names, making it impossible to build a mental model of the interface through a screen reader.

These are not edge cases. They affect the core workflow of using the app: picking a conversation and typing a message.

---

Issue 1: 22 Unlabeled Icon-Only Buttons (WCAG 4.1.2)

These buttons are completely invisible to screen readers, violating WCAG 2.1 Success Criterion 4.1.2 (Name, Role, Value).

131 total buttons inspected. 109 properly labeled. 22 unlabeled.

Category 1: Sidebar conversation action buttons (~18 buttons)

These are small 31x31 icon-only ghost buttons that appear on each conversation item in the sidebar (right edge, x=638). They are evenly spaced at ~40px intervals down the sidebar list. Based on their CSS classes and position, these appear to be rename, delete, or options buttons on each conversation row.

CSS class signature:

inline-flex items-center justify-center relative shrink-0 can-focus select-none
disabled:pointer-events-none disabled:opacity-50 ... h-6 w-6 rounded-md
active:scale-95 bg-bg-300 text-text-500 hover:text-text-100 _ghost_x02hl_49

One of these buttons has hover:text-danger-100 (likely a Delete conversation button), while the rest have hover:text-text-100 (likely Rename or Options buttons).

No aria-label, no Name, no HelpText, no AutomationId.

Category 2: Project header action buttons (2 buttons)

Two 30x31 icon-only buttons near the project selector dropdown (y=279, x=619 and x=654). These are likely Search/filter and New conversation (or sort) buttons.

Same ghost button style, same lack of accessible name.

Category 3: Inline indicator/button (1 element)

A 25x25 element at approximately (516, 861) with class ml-1 shrink-0 inline-flex items-center cursor-default. No accessible name.

Impact

  • Screen reader users cannot identify what any of these 22 buttons do. They are announced as just "button" with no context
  • Voice control users (e.g., Windows Voice Access, Dragon) cannot target these buttons by name
  • Keyboard-only users encounter unnamed focusable elements with no indication of their purpose
  • The sidebar becomes essentially unusable for managing conversations with assistive technology

Suggested Fix

The Button component already supports aria-label pass-through. The fix is adding aria-label props where icon-only buttons are rendered. Example:

// Before (current)
<Button variant="ghost" size="icon_xs" onClick={handleDelete}>
  <TrashIcon />
</Button>

// After (accessible)
<Button variant="ghost" size="icon_xs" onClick={handleDelete} aria-label="Delete conversation">
  <TrashIcon />
</Button>

Affected locations are likely in:

  • Sidebar conversation list item component (rename, delete, options buttons)
  • Project header toolbar (search/filter, new conversation buttons)

---

Issue 2: NVDA Focus Mode Not Automatically Activated on Message Input (WCAG 2.1.1)

Problem

When using NVDA 2025.3.3, the main text input area (where you type messages to Claude) does not automatically trigger NVDA Focus Mode (also called Forms Mode).

In standard accessible web applications, when a screen reader user navigates to an editable text field and presses Enter or Space, NVDA automatically switches from Browse Mode to Focus Mode, allowing the user to type directly into the field.

Current behavior: The message input field does not activate Focus Mode on Enter/Space. The user must manually press NVDA+Space (Insert+Space) to toggle into Focus Mode before they can type. This must be done every time the user wants to interact with the input.

Expected behavior: Pressing Enter or Space on the focused text input should automatically switch NVDA into Focus Mode, as is standard for <textarea>, <input>, or elements with role="textbox" and proper ARIA attributes.

Likely Cause

The message input may be using a contenteditable div or a custom editor component (e.g., ProseMirror, Slate, or CodeMirror) that is missing the proper ARIA role or attributes for NVDA to recognize it as an editable text field. Specifically, it may be missing:

  • role="textbox"
  • aria-multiline="true" (for multi-line input)
  • aria-label="Message to Claude" (or similar descriptive label)

NVDA relies on these attributes to determine when to auto-switch to Focus Mode. Without them, it treats the element as a generic container rather than an input field.

Impact

This forces NVDA users to perform an extra keystroke (Insert+Space) every time they want to type a message, which is a significant workflow disruption that makes the app feel inaccessible for daily use.

---

How to Reproduce

Unlabeled buttons:

  1. Open Claude Desktop on Windows
  2. Run NVDA 2025.3.3 or Windows Narrator
  3. Tab through the sidebar. Multiple buttons are announced as just "button" with no name
  4. Try to identify which button deletes a conversation vs. renames it. There is no way to tell.

Or use Windows UI Automation API to inspect programmatically:

Add-Type -AssemblyName UIAutomationClient, UIAutomationTypes
$root = [System.Windows.Automation.AutomationElement]::RootElement
$claude = $root.FindFirst("Children",
  [System.Windows.Automation.PropertyCondition]::new(
    [System.Windows.Automation.AutomationElement]::NameProperty, "Claude"))
$buttons = $claude.FindAll("Descendants",
  [System.Windows.Automation.PropertyCondition]::new(
    [System.Windows.Automation.AutomationElement]::ControlTypeProperty,
    [System.Windows.Automation.ControlType]::Button))
$buttons | Where-Object { [string]::IsNullOrWhiteSpace($_.Current.Name) }

NVDA input issue:

  1. Open Claude Desktop with NVDA 2025.3.3 running
  2. Navigate to the message input field
  3. Press Enter or Space to try to activate Focus Mode and start typing
  4. Observe that NVDA stays in Browse Mode. You must press Insert+Space to manually switch to Focus Mode
  5. This happens every time you want to type a new message

Related Issues

  • #15509 - Requesting --no-ansi flag for screen reader accessibility (CLI)
  • #25785 - NVDA does not announce backspace/deleted characters (CLI)
  • #11002 - Requesting a --screen-reader mode for NVDA and JAWS (CLI)

These issues cover the CLI tool. This issue covers the Desktop app UI, which has a separate set of accessibility problems.

References

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗