Keyboard complete
Every essential action must work without a pointer. Asking, inspecting, switching material, comparing, deciding, Retain, and Receipt controls need a predictable keyboard path.
Accessibility
Access should notchange the meaning.
Q should remain understandable and operable however someone navigates, reads, zooms, touches, switches material, or asks for less motion. Accessibility is part of the product, not a finishing pass.
This page separates foundations already present from QHub behaviour that still requires end-to-end accessibility verification.
KeyboardScreen readerMotion choiceClear state
The access standard
Six requirements shape every path.
These requirements apply to public pages, QHub, Receipts, account flows, comparisons, and the evolving workspace.
Screen-reader meaningful
Names, relationships, scope, status, errors, active material, and Q state must be available through semantics rather than inferred from layout alone.
Meaning beyond colour
Identify, Surround, Test, Connect, Consider, Care, Retain, source status, conflict, and user decisions must use labels and distinct symbols as well as colour.
Visible focus and position
The active control and active material must remain apparent. Focus should not disappear when panels change, material is switched, or the workspace is rearranged.
Motion is optional
Meaning must not depend on animation. Reduced-motion preferences should remove non-essential movement without removing sequence, progress, status, or control.
Reflow without losing context
Q must remain usable when zoomed, on narrow screens, and with touch. Portrait can switch between material instead of squeezing panes, and no essential action may depend on drag, hover, or forced rotation.
Current status
What is present and what still needs proof.
Public claims should not exceed verified behaviour. A requirement stays open until the interaction, status, and failure path have been tested in the running product.
Present foundation
Semantic public-page structure
Current foundation
Aligned public pages include skip links, semantic landmarks, ordered headings, labelled navigation, structured lists, and descriptive controls.
Release requirement
Preserve the same structure as public pages and QHub evolve, including menus, dialogs, receipts, comparisons, and workspace controls.
Ongoing verification
Visible keyboard focus
Current foundation
Aligned public pages and current QHub controls use explicit focus-visible treatment designed for the dark interface.
Release requirement
Verify every QHub action, overlay, Q action control, source action, comparison control, Retain action, Receipt action, and future workspace command by keyboard only.
Ongoing verification
Distinct Q action identity
Current foundation
Q uses the public action names Identify, Surround, Test, Connect, Consider, and Care with distinct glyph silhouettes; Retain remains a separate governed action.
Release requirement
Verify accessible names, active-state announcements, reading order, and status changes without relying on glyph shape or colour alone.
Present foundation
Reduced motion and stable content
Current foundation
The shared Q mark and aligned public pages respond to reduced-motion preferences and remove non-essential transitions or smooth scrolling.
Release requirement
Apply the same rule to processing indicators, panel changes, comparison transitions, notifications, and programmatic focus movement.
Ongoing verification
Responsive reflow and touch
Current foundation
Public pages reflow to narrow screens, and the current QHub mobile shell avoids forcing desktop-style side-by-side inspection into portrait width.
Release requirement
Verify high zoom, text enlargement, virtual keyboards, orientation changes, touch target spacing, long labels, and readable comparison fallbacks in the running product.
Required before broad release
Workspace movement without drag
Current foundation
The workspace direction treats arrangement as presentation state rather than a change to the underlying record.
Release requirement
Any move, dock, resize, or compare interaction must have explicit keyboard-operable alternatives to drag and must preserve the active artifact, position, and focus.
Required before broad release
Q scope and active-material announcements
Current foundation
QHub separates visible material from explicit Q scope in its product model.
Release requirement
Assistive technology must be told which material is active, which material is in Q scope, when scope changes, and that opening or moving material does not silently add it to scope.
Required before broad release
Complete Ask-to-Receipt path
Current foundation
The founding-pilot surfaces cover the intended Ask, Inspect, Sources, Challenge or Compare, Retain, and Receipt sequence, while managed provider execution remains separately configurable.
Release requirement
The complete path, including errors and recovery, must be verified with keyboard, screen reader, zoom, reflow, touch, and reduced-motion settings before broad release.
Required before broad release
Formal and human-informed review
Current foundation
Accessibility requirements are being built into the product structure rather than deferred to a final compliance pass.
Release requirement
Complete automated checks, manual keyboard testing, screen-reader review, zoom and reflow testing, and structured feedback with disabled users before broad release.
State and authority
Meaning cannot depend on colour alone.
A person should be able to tell what an item is, where it came from, whether it is a Q proposal or a user decision, and what remains unresolved without reconstructing the visual design.
Preserved original
Visible treatment
Labelled as the starting point and kept visibly distinct from Q output, edits, or later material.
Assistive treatment
Its accessible name identifies it as user-supplied original content and exposes its reference or version where relevant.
Q proposal
Visible treatment
Marked as proposed rather than as the user's decision.
Assistive treatment
Proposal status is announced before its content and remains associated with the actions available to inspect, challenge, compare, or decide.
Source or considered material
Visible treatment
Its origin, role, and source status are named instead of being implied by position or colour.
Assistive treatment
The source label, provenance, current role, and any relevant limitation can be read directly.
Conflict or unresolved item
Visible treatment
Uses a named state, symbol, and explanation so disagreement does not disappear into warning colour.
Assistive treatment
The issue, affected material, current status, and available actions are exposed as structured text.
Your decision
Visible treatment
A user correction or decision is labelled as user-authored and remains distinct from the Q proposal that preceded it.
Assistive treatment
The action, affected version, result, and relationship to the earlier state can be read without reconstructing the visual history.
Retained outcome
Visible treatment
Proposed Retain and user-approved Retain remain separate states with separate labels and controls.
Assistive treatment
The interface identifies whether Retain awaits a decision or has been explicitly approved, including unresolved limits that remain attached.
The accessible path
Accessibility follows the work end to end.
A landing-page audit is not enough. These are release requirements for the full QHub path; they are not claims that every interaction is already verified today.
Ask Q
The starting question needs a clear label, predictable submission path, visible confirmation, and understandable error handling.
Keyboard and controlStandard text navigation, predictable Tab order, and no pointer-only submission or attachment control.
Status and announcementThe exact question understood by Q, submission success or failure, and any processing boundary are confirmed in text.
Inspect the record
Brief and Expanded views must expose more or less of the same record without changing its underlying truth or silently regenerating it.
Keyboard and controlDepth controls, sections, and Q actions are reachable in a logical order with stable focus.
Status and announcementThe current depth, active Q action, processing state, and unresolved status can be conveyed without rereading the whole page.
Review sources
Source origin, excerpt, status, and relevant limitations need to remain readable and attributable.
Keyboard and controlSources can be opened, inspected, returned from, and filtered without pointer-only interactions.
Status and announcementThe active source, provenance, source status, and whether it is in Q scope are labelled directly.
Challenge or compare
A challenge or comparison must preserve the underlying material instead of replacing it with a summary of the disagreement.
Keyboard and controlA and B can be reached directly, comparison analysis can be entered or skipped, and narrow screens can switch between sides without losing place.
Status and announcementThe relationship between A and B, the active side, conflicts, and current Q scope are available as structured text.
Switch or arrange material
Opening, switching, moving, or docking material changes presentation only. It must not silently change provenance, evidence status, retention, or Q scope.
Keyboard and controlEvery drag-capable action must also have explicit move, dock, switch, and resize commands. Portrait mobile may use one primary artifact at a time.
Status and announcementThe active artifact, destination, layout change, preserved position, and Q-scope state are confirmed without excessive interruption.
Retain and read the Receipt
Q may propose what to retain. The user decision and the Receipt must remain explicit, readable, and separate.
Keyboard and controlSupporting material, unresolved items, the Retain decision, Receipt sections, and export actions follow a meaningful focus order.
Status and announcementThe interface identifies proposed versus approved Retain, Receipt version, retained outcome, and unresolved limits directly.
Cognitive access
Start simply. Go deeper only when needed.
Q should not require someone to understand the full system before they can ask a question. More structure appears when it becomes useful, without hiding the record underneath.
See how Q worksOne clear entrance
Start with a normal question or material instead of choosing among unexplained system modes.
Go deeper only when needed
Brief comes first. Sources, conflicts, inference, comparison, and deeper record detail appear when they become useful.
Keep language stable
Identify, Surround, Test, Connect, Consider, Care, and Retain keep the same public names across desktop, mobile, keyboard, and assistive experiences.
Keep your place
Switching material should preserve useful context such as page, scroll, media time, comparison side, and active Q scope where the product supports it.
Visible is not automatically in scope
Material can be open or visible without silently becoming authorised input for Q.
Make recovery explicit
Errors should explain what remains preserved and the smallest available recovery action instead of returning the user to an ambiguous start.
Before broad release
The build must prove the accessible path.
Accessibility is verified through behaviour, not only code review or a policy page. These checks belong in the QHub release decision.
Keyboard-only completion
Complete the Ask-to-Receipt path without a mouse, including sources, comparison, recovery, Retain, and Receipt review.
Screen-reader review
Verify structure, names, active material, Q scope, reading order, errors, state changes, and live updates with representative assistive-technology combinations.
Zoom and reflow
Confirm content remains readable and operable at high zoom and narrow widths without forcing desktop pane geometry into mobile.
Workspace movement
Verify every move, dock, switch, resize, and comparison action has a non-drag alternative and preserves meaningful focus.
Contrast and non-colour cues
Test text, focus, Q actions, source states, comparisons, errors, and disabled controls while confirming essential meaning never relies on colour alone.
Motion and timing
Remove non-essential motion when requested and ensure progress, confirmation, or session behaviour does not impose inaccessible timing pressure.
Touch and orientation
Verify mobile controls work without precision tapping, hover, forced rotation, or unreadably narrow split panes.
Context restoration
Verify returning to material restores enough context to continue, including the active artifact and relevant reading or media position where supported.
Error recovery
Errors identify what happened, what remains preserved, and the smallest available recovery action.
Human-informed review
Accessibility feedback must influence release decisions and remain an ongoing product input rather than a one-time certification exercise.
Accessibility feedback
A barrier is product evidence.
Preview participants can help test accessibility changes before wider release, explain what worked or failed, and suggest improvements. Core accessibility requirements remain product requirements.
Until a dedicated accessibility contact is published, use the Founding access form and identify the submission as an accessibility report.
Accessibility questions
Clear answers, including current limits.
Is Quantaible claiming complete accessibility today?
No. Important public-page and QHub foundations are present, but the complete runtime still requires end-to-end keyboard, screen-reader, zoom, reflow, touch, reduced-motion, and failure-recovery verification before broad release.
Will the coloured Q remain understandable without colour?
It must. Identify, Surround, Test, Connect, Consider, and Care use public labels and distinct glyph silhouettes, while Retain remains a separate action. Colour reinforces identity but cannot carry the only meaning.
Will Q support keyboard-only use?
That is a release requirement. Essential Ask, Inspect, Sources, Challenge or Compare, switching or arranging material, Retain, recovery, and Receipt actions must be available without pointer input.
Will moving or docking material require drag?
No. Where drag or direct manipulation is offered, an explicit keyboard-operable move, dock, switch, or resize path must also be available.
What happens on mobile?
Portrait should keep one primary artifact readable at a time with a clear switcher rather than squeezing tiny panes. Landscape may offer a split only when the available width remains readable; rotation should never be required.
How should Q scope work with assistive technology?
The interface should identify what material is active and what material Q is actually authorised to use. Opening, viewing, or moving an artifact must not silently add it to Q scope.
Will Q remember where I was?
Continuity is an accessibility requirement for the evolving workspace. Where supported, switching and returning should preserve useful context such as page, scroll position, media time, comparison side, and active material rather than making the user reconstruct it.
Does reduced motion remove information?
No. Reduced motion should remove or simplify movement while preserving sequence, labels, progress state, content, and control.
How can I report a barrier during the controlled preview?
Until a dedicated accessibility contact is published, use the Founding access form and identify the submission as an accessibility report. Include the page or control, expected result, actual result, device, browser, zoom level, keyboard use, and assistive technology where relevant.
The rule
Everyone should be able to tellwhat Q proposed and what they decided.
The starting point should stay distinct, Q proposals should stay proposals, scope should stay explicit, and user decisions should remain attributable.