a5152bc0c8
All checks were successful
no-vanity-metrics / Scan committed Markdown for vanity metrics (push) Successful in 4s
standards workspaces build + test / eoc-rs (push) Successful in 1m54s
standards workspaces build + test / jouleclaw-rs (push) Successful in 2m2s
standards workspaces build + test / aac-rs (push) Successful in 58s
standards workspaces build + test / jcp-rs (push) Successful in 1m20s
standards workspaces build + test / arl-rs (push) Successful in 3m21s
standards workspaces build + test / joule-code-rs (push) Successful in 42s
standards workspaces build + test / joulecontract-rs (push) Successful in 33s
standards workspaces build + test / proof-rs (push) Successful in 1m13s
standards workspaces build + test / map-rs (push) Successful in 29s
standards workspaces build + test / mesh-rs (push) Successful in 25s
standards workspaces build + test / joule-ui-rs (push) Successful in 2m28s
standards workspaces build + test / openpay (push) Successful in 1m13s
standards workspaces build + test / sandbox-rs (push) Successful in 2m8s
standards workspaces build + test / jouledesk-rs (push) Successful in 2m32s
standards workspaces build + test / smart-byte-rs (push) Successful in 2m27s
standards workspaces build + test / joulehook-rs (push) Successful in 2m15s
standards workspaces build + test / sense-rs (push) Successful in 2m36s
standards workspaces build + test / macOS energy backend (jcp-energy) (push) Successful in 2m21s
- §4.1 Language honesty: every language states how its core vocabulary was obtained (CoreStatus); an absent status reads as GlossOnly; glosses are never presented as a language's core. Withdraws the claim that one ~400-word core covers ~80% of every language. - §5.1 Timing belongs to the person: scan rate and dwell are theirs to set; automatic adaptation is off unless they opt in; changes are proposed, never silent. - §5.2 Scan-rate floor: max(⌊100·M/65⌋, P95), from at least 10 responses. The previous reference set 80% of the mean press, so the highlight had usually moved on when the person pressed. - §5.3 Dwell proposals go both ways, with floors, replacing "should adapt to fatigue" (the old reference only ever lengthened the dwell). - §10 adds C5–C7; §11 says access and vocabulary choices are never a prerequisite for starting. - spec/access_model.md, the lexicon and the ontology agree (new CoreStatus class and individuals; scanRateMs, dwellMs, adaptationOptIn; Turtle, SHACL and JSON-LD validated with rdflib). New aac-rs/README.md covers testing, the static build, and hosting Express under another site. Co-Authored-By: Claude Opus 5.5 <[email protected]>
34 lines
3.8 KiB
Markdown
34 lines
3.8 KiB
Markdown
# AAC sub-spec — The access model
|
|
|
|
Normative refinement of [SPEC §5](../SPEC.md). Reference: `aac_core::{AccessMethod, MotorProfile, ScanConfig, ScanMode, DwellConfig}`.
|
|
|
|
Every access method is a first-class input. The method and its tuning travel with the **user**, not the board: a board authored for eye-gaze MUST still open under touch or a switch (SPEC §5.3).
|
|
|
|
## 1. Access method — `AccessMethod`
|
|
|
|
`DirectTouch` (default) · `EyeGaze` · `HeadTracking` · `SwitchScan { switches: u8 }` · `Joystick` · `Bci` · `PartialVoice` · `Pointer`. `SwitchScan` carries the number of switches available (1, 2, or more); a 1-switch user relies on auto-scan timing, a 2-switch user steps and selects manually.
|
|
|
|
## 2. Motor profile — `MotorProfile`
|
|
|
|
The user's physical capabilities, used to adapt targets and timing: `fine_motor` and `sustained_press` (`Full | Limited | None`), `tremor_level` (`None | Mild | Moderate | Severe`), `min_target_mm: f32`, optional `max_reach_mm`, and `preferred_side`. A client SHOULD derive target size and dwell/scan timing from this profile and MUST NOT render a target smaller than `min_target_mm`.
|
|
|
|
## 3. Switch scanning — `ScanConfig`
|
|
|
|
A conforming scanner MUST support at minimum the `Linear`, `RowColumn`, and `Group` modes of `ScanMode` (also defined: `Block`, and inverse scanning). It MUST honor:
|
|
|
|
- `scan_rate_ms` — highlight dwell per step;
|
|
- `start_delay_ms` — delay before auto-scan begins after a press;
|
|
- `max_cycles` — complete cycles before stopping (`0` = infinite);
|
|
- `auto_restart` — whether scanning restarts after a selection.
|
|
|
|
`scan_rate_ms` is the person's to set (SPEC §5.1). `adaptive_rate` MUST default to `false`. A rate recommended, proposed or applied from measured responses MUST follow SPEC §5.2: at least 10 recorded responses, at least `max(⌊100·M/65⌋, P95)` of their response times, clamped to `[300, 5000]` ms. Without opt-in the scanner MAY only *propose* that rate (`proposed_scan_rate_ms`, which offers nothing within 10% of the current rate); with opt-in it MAY apply it. A client that measures responses MUST time them from the moment a highlight appears to the press.
|
|
|
|
## 4. Dwell / eye-gaze — `DwellConfig`
|
|
|
|
Gaze selection MUST use a configurable dwell time (`base_dwell_ms`, with the dwell in force in `effective_dwell_ms`) with **visible progress feedback** (`DwellFeedback`) and a `tolerance_px` radius within which gaze may wander without resetting. A selection MUST NOT fire before the effective dwell elapses.
|
|
|
|
The dwell is the person's to set (SPEC §5.1; the reference's `set_dwell_ms`, clamped to `[150, max_dwell_ms]`). `fatigue_adaptation` — the reference's name for automatic dwell adjustment — MUST default to `false`. Proposals (`proposed_dwell_ms`) follow SPEC §5.3: one ladder step longer when more than 20% of recent selections were undone; one step shorter when fewer than 5% were undone and more than 20% of attempts were abandoned late (gaze left after at least half the dwell); never from fewer than 10 selections, never shorter than 300 ms. A client counts an undo when the person removes a word within a few seconds of selecting it by dwell. The dwell engine reads a monotonic clock that MUST work on the client's platform (the reference uses `web-time`, since `std::time::Instant` panics in browsers).
|
|
|
|
## 5. Universality
|
|
|
|
No access method MAY be a precondition for opening or reading a board (SPEC §5, item 3). Choosing an access method is best done by the person with their team, and it is never a prerequisite for starting (SPEC §11); the standard guarantees that whichever method is chosen is a first-class, fully-specified input — never a bolt-on. A client SHOULD start the chosen method as soon as it is chosen (scanning over the board on screen, the camera for gaze) and stop what it no longer needs — in particular, release the camera when gaze is no longer in use.
|