Replies: 6 comments
Implementation and validation updateThe full accessibility implementation is now available for review:
The core work covers landmarks and live status, named dialogs and focus restoration, workspace and subagent trees, JSON trees, menu buttons and submenus, combobox/listbox selection, radio groups, tabs, trajectory listbox/table navigation, feedback popovers, adjustable separators, and accessible names for icon-only controls. Validation completed:
One existing HMR live test is excluded on the current Node 24 environment because import-without-cache 0.4.0 fails in its loader before the app is ready; this is unrelated to these accessibility changes. NVDA and JAWS were not physically run because no Windows environment was available. Their compatibility is supported by standards-based ARIA/APG behavior and automated browser coverage, but this update does not claim universal assistive-technology certification. |
npm package publishedThe companion plugin is now publicly installable from npm:
The public registry tarball was downloaded anonymously after npm publish-time scanning and its SHA-1 matched the published digest: 3f4a6c4efa0ebfaaae4d57a1908c420061d529e9. |
Final core accessibility candidateThe immutable community core candidate is now published:
The gate passed GUI regressions on Ubuntu, macOS, and Windows, plus typecheck, lint, the official production build, a functional sandbox probe, and the production browser replay (82 files passed, 1 conditional file skipped; 281 tests passed, 13 conditionally skipped). The companion source is finalized at omdsh-dev/dsh-accessibility@c8833e2 and its macOS/Ubuntu/Windows × Node 22/24 matrix is green. The implementation has native Safari/VoiceOver accessibility-tree and keyboard evidence, but does not claim universal assistive-technology certification. Complete spoken VoiceOver evidence and physical NVDA/JAWS/Narrator validation remain tracked at: |
npm trusted publication completeThe final companion candidate is now publicly available:
The package was published by GitHub Actions through the npm trusted-publisher configuration for The prerelease install is now: dsh plugin --profile web add @oh-my-dsh/dsh-accessibility@0.1.0-beta.4The npm The validation boundary is unchanged: native Safari/VoiceOver accessibility-tree and keyboard evidence plus cross-platform automation are complete, while complete human-audible VoiceOver records and physical Windows NVDA/JAWS/Narrator runs remain openly tracked in issues #2 and #1 of the companion repository rather than being presented as universal assistive-technology certification. |
Accessibility candidate 4 and npm beta.5The completed core candidate and companion diagnostics update are now public:
The final pass adds assembled axe coverage with no disabled rules, stable accessible names for native disclosure rows, separate nested file controls, correct empty-list semantics, and 17 companion structural diagnostics. The immutable core tag passed GUI regressions on Ubuntu, macOS, and Windows, plus typecheck, lint, the official build, production browser replay, and the aggregate accessibility gate. The browser replay passed all 84 files with 284 tests passed and 13 conditionally skipped. Real assistive-technology evidence was repeated on macOS 15.5 / Safari 18.5 with VoiceOver enabled. The native accessibility tree exposed the DSH application heading, primary navigation, selectors, composer, and controls. Sequential keyboard focus reached Open sidebar, New session, Add workspace, Search sessions, Settings, workspace, preset, and composer. Opening Settings by keyboard and closing with Escape returned focus to Settings. This does not claim exact spoken-output or universal AT certification. Human-listened VoiceOver utterance records and physical Windows NVDA, JAWS, and Narrator runs remain open at:
The GitHub APIs available to this account did not permit creating the upstream pull request, so the compare link above is the ready-to-review handoff. |
Community assistive-technology testing request / 社区多设备读屏验证招募We are looking for screen-reader users who can test the accessibility candidate on a physical device. Automated and VoiceOver-enabled browser checks are green, but community evidence from different machines, browsers, speech settings, and assistive technologies is needed before claiming broad compatibility. Most-needed devices
Install the exact candidateRequirements: Node.js 22.19.0 or a supported Node 24 release, Git, and Corepack. git clone --branch dsh-v0.1.1-rc.2-a11y.4 --depth 1 https://github.com/omdsh-dev/deepseek-harness.git dsh-a11y-test
cd dsh-a11y-test
corepack enable
pnpm install --frozen-lockfile
pnpm run build
pnpm dsh plugin --profile web add @oh-my-dsh/dsh-accessibility@0.1.0-beta.5
pnpm dsh webOpen the printed local URL, normally Quick 10 to 15 minute pass
The complete 12-scenario checklist is available in English and 简体中文. Result templatePlease post Windows results in issue #1, VoiceOver results in issue #2, and other platform results as a new issue in the companion repository. Partial results are useful; please state exactly which scenarios were run. 中文说明：欢迎使用真实设备、真实读屏软件验证。请严格使用上面的 |
Uh oh!
There was an error while loading. Please reload this page.
Accessibility: screen-reader and keyboard gaps in the 0.1.1-rc.2 web client
Summary
I tested the current
0.1.1-rc.2web client with macOS VoiceOver, keyboard-only navigation, and the macOS/browser accessibility tree. The UI already exposes useful accessible names on many icon buttons, and the model menu has a working keyboard interaction. However, several core navigation paths are currently blockers for screen-reader and keyboard users.I would like to build a community accessibility companion for DSH, but the current slot API cannot safely fix all of these issues from a plugin. This discussion proposes a split between core UI fixes and an optional companion plugin, and asks whether that matches the intended architecture.
Test environment
0.1.1-rc.2No prompt was submitted and no model call was made during the test.
Reproducible blockers
1. The workspace/session tree is skipped by keyboard focus
The sidebar exposes
role="tree"androle="treeitem", but neither the tree nor its items provide a focusable entry/roving-tabindex model.Steps:
Expected: the tree follows the ARIA tree keyboard pattern (one focusable entry, arrow-key navigation, Home/End, Left/Right expansion, and Enter/Space activation).
2. Closing session search leaves focus on a hidden input
Steps:
The search UI collapses, but focus remains on the now hidden/non-tabbable input. Expected: focus returns to the Search sessions trigger.
3. The Settings dialog does not contain or restore focus
Steps:
Focus eventually moves into controls behind the dialog. Pressing Escape closes the dialog but does not reliably return focus to the Settings trigger.
Expected: modal dialog semantics and keyboard behavior, contained focus while open, an intentional initial focus target, and focus restoration on close.
4. The conversation composer lacks a persistent accessible label
In its normal state, the textarea relies on placeholder text. A persistent label or
aria-label/aria-labelledbywould give it a stable accessible name after content is entered.5. Conversation updates lack a complete reading model
Source inspection shows a polite status announcement for the in-progress state, but the message flow itself has no labelled
log/feed-like region and built-in messages do not form consistently labelled user/assistant groups. Streaming also needs a completion-oriented announcement strategy so a screen reader is not asked to speak every token.6. Main layout and resize handles need semantic/keyboard support
The sidebar, conversation area, and details area are currently generic containers. Pointer-draggable splitters should expose separator/value semantics and keyboard resizing.
Why a plugin alone cannot provide complete support
The supported client extension mechanism composes UI through slots. A companion plugin can add a settings tab, keyboard help, an off-screen announcer, or diagnostics. It cannot safely decorate the existing root layout, built-in workspace tree, Settings dialog, composer, or built-in message nodes.
Some relevant slots are single-owner slots. Replacing
sidebar.workspacesorconversation.sessionwould mean reimplementing a large built-in surface rather than incrementally improving it. A DOMMutationObserverpatch would be brittle and tied to private markup, so I do not think it should be presented as complete accessibility support.Proposed split
Core UI changes
ui-layout: main/complementary regions, labelled areas, keyboard-operable separators, visible focusui-workspace/ sidebar: ARIA tree keyboard model and reliable search focus restorationui-settings: modal focus containment, Escape behavior, trigger restoration, tab semanticsui-conversation: persistent composer label, labelled message groups, a stable message-reading region, throttled/completion announcementsOptional
dsh-accessibilitycompanion pluginThe plugin would explicitly state that it complements, rather than replaces, the required core semantics.
Suggested acceptance matrix
Questions for maintainers
dsh-accessibilitycompanion plugin the preferred path?If this direction is useful, I will publish the implementation with the
dsh-plugin,accessibility,screen-reader,wcag,voiceover, andnvdarepository topics, with compatibility initially pinned to DSH0.1.1-rc.2.All reactions