Contributions that improve screen-reader interoperability, keyboard operation, diagnostics, documentation, or test evidence are welcome.
简体中文 | English
Organization membership is not required. Use the accessibility-barrier form for product defects, the assistive-technology test form for actual AT observations, and the disabled-developer task form for consented task outcomes with or without dedicated AT. The community validation guide explains the safe setup, evidence boundary, and review lifecycle. Architecture proposals should identify whether work belongs in DSH core, the runtime companion, a development testkit, the external AT lab, or a separately permissioned model-visible authoring tool.
pnpm install
pnpm run evidence:validate
pnpm run evidence:coverage
pnpm run typecheck
pnpm test
pnpm run build
npm pack --dry-runBehavior changes must include deterministic tests. Changes to support claims must update both accessibility documents and identify the exact browser, assistive-technology version, language, scenario, spoken result, and focus result. Claimed human evidence must also add or update a record governed by HUMAN-EVIDENCE.md using protocol/task IDs and classifications from EVIDENCE-CATALOG.json, then review the effect on aggregate coverage. Add or revise the catalog and coverage policy through review before recording a new task or changing a program requirement; never self-classify a result as representative core or claim-eligible. Failed and partial results are retained with claim: none; raw data never belongs in that public record. Automated checks do not count as manual screen-reader certification.
For real AT observation, use the core lab for static core tasks, the live-announcement lab for response/tool/request transitions, the companion lab for Accessible View, the authoring AT lab for approval and repair, or the CLI lab for the one-shot terminal candidate. All use synthetic content and provide a copyable, consent-aware result record. A lab startup is not itself an AT result. Disabled-developer evidence additionally follows RESEARCH.md, requires a private withdrawal route, and never requires diagnosis details.
Keep host and client behavior within documented DSH extension seams. Do not patch generated CSS classes or inspect conversation text.
Do not use a DOM observer to rewrite host semantics, focus, or keyboard behavior. Any future access to conversation or workspace content requires a privacy review and an explicit boundary from the current read-only diagnostics.
Security reports use GitHub private vulnerability reporting. Conduct incidents follow the omdsh-dev/community Code of Conduct and must not be filed publicly.