Eye-gaze: tracker matrix, calibration workflow, accuracy testing — the least-tested primary access method

[willwade]

From the governance test checklist gap analysis (governance#41).

Priority: HIGH — primary access method, least tested

Eye-gaze is the core access method for the target AAC audience on Windows, and it has:

• No tracker compatibility matrix (which Tobii models? EyeTribe? PCEye?)
• No calibration workflow test
• No accuracy/stability test scenarios
• RFC 0010's eye-gaze proposals are still open

What to test

1. Tracker matrix: which trackers work with Dasher v6? (Tobii 4/5, PCEye Plus, EyeTribe — via what driver/API?)
2. Calibration: does Dasher use the tracker's built-in calibration or provide its own? Does calibration state persist?
3. Auto-speed stability: RFC 0010 mentions auto-speed adjusting based on gaze stability — does it oscillate or converge?
4. Dwell + eye-gaze: the combination (gaze to steer, dwell to select) is the most common eye-gaze setup — is it tested?
5. Fatigue: does accuracy degrade over a 30-minute session?

Relationship to RFCs

RFC 0010 (input & access methods) lists eye-gaze under "proposals still open." This issue should drive those proposals to active with concrete test data.