Interaction evidence / open coverage
Accessibility in Holaryn Agent
Review the interaction mechanics designed into Holaryn Agent, the evidence recorded for specific environments, and the manual coverage that remains open.
Designed behavior
What the product is designed to support
Holaryn uses semantic structure, keyboard-operable controls, visible focus, live status, responsive layouts, zoom, and reduced-motion handling as engineering requirements. Each mechanism still needs evidence for the exact surface and environment.
Keyboard and focus
Skip links, native controls, logical DOM order, focus-managed overlays, and visible focus indicators are product design requirements.
Use it: Rebind supported product shortcuts when defaults conflict with an operating system or assistive technology.
Limit: A documented keyboard path is evidence for that path, not proof that every workflow has completed manual keyboard review.
Announcements and status
Polite live regions and accessible names communicate streaming work, async changes, save state, and selected product notifications.
Use it: Keep the active surface open when a continuous status stream is needed; review durable run history for prior outcomes.
Limit: Announcement timing and verbosity can differ across browser, desktop shell, and screen-reader combinations.
Reflow, zoom, and motion
Responsive layouts, desktop zoom controls, text scaling, and reduced-motion handling are covered by implementation rules and automated regressions.
Use it: Use native browser or desktop zoom and the operating system's reduced-motion preference.
Limit: Automated viewport and motion checks do not replace manual 200% text and 400% browser-zoom review.
Choose a surface
Surfaces and interaction guidance
Choose the surface whose interaction model fits the task, then use guidance tied to the same published source. A surface name is not a claim that every capability or platform behaves identically.
Command line
Terminal output and command interaction retain textual status and do not require a pointer.
Use it: Use the command surface when a linear, text-first workflow is the clearest fit.
Limit: Exact terminal and screen-reader behavior still depends on the terminal, operating system, and configured assistive technology.
Local web interface
Named landmarks, real labels, headings, live regions, focus-managed dialogs, and button alternatives support keyboard and screen-reader operation.
Use it: Use the skip link, workspace shortcuts, semantic controls, and the accessible terminal log view.
Limit: Specific implemented mechanics do not establish compatibility with every browser and assistive-technology pairing.
Desktop app
The desktop app wraps the same local web interface with native menus, persisted zoom, tray behavior, and operating-system notifications.
Use it: Use native menu commands for zoom and keyboard shortcuts when the desktop shell is preferred.
Limit: Notification announcement and native-shell behavior vary by operating system and assistive technology.
Computer use
The supervised computer-use surface exposes semantic roles and names beside a selected-window image and retains keyboard-operable supervision controls.
Use it: Use the semantic target list without relying on the screenshot when operating supported Windows applications.
Limit: Native computer use is a Windows-only beta. No macOS or Linux computer-use support is claimed.
Interaction contract
Keyboard, focus, announcements, reflow, and reduced motion
These mechanics work together: controls need names and states, focus needs a visible and logical destination, async work needs a restrained announcement, and layouts must remain operable without motion or horizontal document scrolling.
Keyboard: real controls and rebindable shortcuts remain alternatives to pointer-only operation.
Focus: overlays and page changes move or restore focus deliberately; visible focus is never color alone.
Status: polite live regions report relevant asynchronous changes without treating every stream token as a new alert.
Display: responsive reflow, native zoom, text scaling, and reduced-motion preferences remain part of the test boundary.
Product evidence
Testing evidence and current coverage
Completed means the named check ran in the stated environment. Partial means concrete mechanics or automated evidence exist but the full named matrix is open. Pending means no completed dated pass is claimed.
| Evidence | Status | Environment and date | Scope and limit | Source |
|---|---|---|---|---|
| Semantic web-interface mechanics | Pending | No current exact product baseline |
Named landmarks/controls, focus management, live regions, heading structure, and keyboard alternatives are documented and exercised by automated scenarios. The refreshed external assistive-technology matrix remains incomplete. | Not yet recorded |
| Desktop zoom and notification mechanics | Pending | No current exact product baseline |
Native zoom commands, persisted zoom, and announcement-oriented notification behavior are documented. Operating-system and assistive-technology combinations are not comprehensively verified. | Not yet recorded |
| Windows computer-use semantics | Pending | No current exact product baseline |
Semantic roles/names, target highlighting, keyboard supervision, and redacted step history for native computer use. No macOS or Linux native computer-use claim. | Not yet recorded |
| JAWS manual workspace matrix | Pending | JAWS 2025+ / Edge / Windows |
Refreshed end-to-end workspace review with current supported Windows/browser versions. The published verification record says this follow-up was not performed. | Not yet recorded |
| NVDA manual workspace matrix | Pending | Current NVDA / Firefox or Chrome / Windows |
Refreshed end-to-end workspace review with current supported Windows/browser versions. The published verification record says this follow-up was not performed. | Not yet recorded |
| VoiceOver manual workspace matrix | Pending | VoiceOver / Safari / current macOS |
Refreshed end-to-end workspace review on current Apple environments. The published verification record says this follow-up was not performed. | Not yet recorded |
| Orca manual workspace matrix | Pending | Orca / Firefox or Chromium / Linux |
A dated representative product pass has not been established by the reviewed release evidence. No broad Orca compatibility claim is made. | Not yet recorded |
Keep open work visible
Known limits
These limitations are part of the current assessment, not a hidden footnote.
- No formal product or website WCAG conformance statement is established.
- The refreshed JAWS, NVDA, and VoiceOver workspace matrix remains Pending; broad Orca compatibility is not claimed.
- Native computer use is a Windows-only beta, even though other agent surfaces run on Windows, macOS, and Linux.
- Automated axe, keyboard, reflow, and motion checks cannot reproduce every browser, operating-system, zoom, input, and assistive-technology combination.
- A specific documented behavior is evidence for that path and version, not a guarantee that every task or extension is accessible.
Privacy-safe reporting
Report an accessibility problem
Use Support for an accessibility problem. A useful report describes the environment and interaction without asking you to disclose a disability or include secrets and private content.
Include
- Product or website surface and exact version
- Operating system, browser, and assistive technology when relevant
- Steps to reproduce
- Expected and actual behavior
- Privacy-safe text or redacted evidence
Keep out
- Passwords, API keys, tokens, or private prompts
- Unredacted personal or customer data
- Disability or medical information
- Vulnerability detail—a security finding uses the private security path
Choose the Support reporting path or report a vulnerability privately.
Website evidence
Accessibility of this website
The website uses the same evidence discipline: automated results are dated and separated from manual environments that remain Pending. The page itself is part of the representative structural, axe, keyboard, and reflow baseline.
| Evidence | Status | Environment and date | Scope and limit | Source |
|---|---|---|---|---|
| Automated semantics and axe baseline | Completed | Playwright Chromium and axe-core |
One H1, named landmarks/controls, unique IDs, metadata, and no serious/critical axe findings across representative routes. Automated scanning is a regression signal, not a conformance statement. | tests/browser/shared-shell.spec.js and Django structural response tests |
| Keyboard, no-JavaScript, motion, and narrow reflow | Completed | Isolated local Chromium server and deterministic database |
Skip focus, native mobile navigation, capability details/filters, reduced motion, and 320 CSS-pixel document reflow. The automated set does not cover every browser, zoom level, or input method. | Website locked browser regression harness |
| Manual keyboard and zoom matrix | Pending | Manual environment required |
Current Chrome and Firefox on Windows, 200% text zoom, and 400% browser zoom across primary journeys. Do not infer completion from the automated 320px reflow check. | docs/accessibility-verification.md manual entry point |
| Manual website assistive-technology matrix | Pending | Windows, macOS/iOS, and Linux environments |
NVDA, JAWS, VoiceOver, and Orca representative journeys for the exact deployable revision. No formal website accessibility conformance claim is made. | docs/accessibility-verification.md Pending matrix |