Accessibility
Access status should be explicit — not implied.
EyeSay is being built for more than one way of reaching language. This page separates what the current product supports from what is still being validated or planned, so a family or clinician does not have to infer hardware compatibility from a design intention.
Current access-method status
Available now, in development, and research stage are different states.
“Designed with” is not the same as “tested with”. Where specialist hardware or an access profile has not been formally validated, we say so.
Direct touch
Available nowThe current web app is designed first for direct touch, with large labelled targets and a stable motor layout that does not re-order under the communicator's finger.
Current boundary: Exact touch behaviour still depends on the browser, device, screen size and operating-system accessibility settings.
Touch on release
In developmentRelease-based activation is part of the access design so a resting or moving finger does not have to activate a control on initial contact.
Current boundary: It is not yet published as a formally validated access profile across every EyeSay interaction and target device. Do not assume universal touch-on-release support yet.
Keyboard
Available nowPublic and authenticated interfaces are being built with keyboard-reachable controls, visible focus treatment and semantic labels. The current product prioritises keyboard-accessible interaction alongside direct touch.
Current boundary: Keyboard access does not by itself establish compatibility with every alternative keyboard, keyguard or operating-system input method.
Switch / scanning
Research stageDedicated switch-scanning profiles and a formally documented scanning workflow are on the access roadmap.
Current boundary: EyeSay does not currently claim production-ready compatibility with a particular switch interface, switch adapter or scanning setup.
Eye gaze
Research stageThe interaction architecture is being designed with gaze-compatible patterns in mind, including stable target positions and non-moving core vocabulary.
Current boundary: Formal eye-gaze validation has not been completed. EyeSay does not currently promise compatibility with any named eye-gaze camera, tracker or operating system.
Keyguards and physical access
Research stageThe stable 8-by-6 motor topology gives future keyguard work a predictable geometry to design against.
Current boundary: Keyguard-specific dimensions, cut files and device-fit validation are not yet published. A stable grid is not the same thing as tested keyguard compatibility.
Interface commitments
Accessibility is also about what stays predictable.
- Targets
- Interactive AAC targets are designed around generous touch areas rather than tiny icon-only controls.
- Text labels
- Text remains first-class alongside visual cues, with readable labels rather than symbol-only meaning.
- Colour
- Colour is not intended to carry meaning by itself; text, shape, border and context provide redundant cues.
- Focus
- Keyboard focus is visible and important controls use semantic names so access is not dependent on pointer input.
- Motion
- Reduced-motion preferences are respected for non-essential movement.
- Contrast
- Foreground and background token pairs are designed for readable contrast, including against operating-system forced-colours and high-contrast settings.
- Motor stability
- Context may change around the stable language plane, but the learned motor positions are not relocated to make a suggestion easier to reach.
- Authorship
- An access method changes how a communicator reaches a control; it does not change who authors the message.
Hardware boundary
No compatibility claim without device-specific evidence.
EyeSay does not currently claim certified or production-ready compatibility with a named switch interface, eye-gaze tracker, keyguard, specialist mount or alternative pointing device unless that combination is explicitly documented as tested. Browser support, operating-system support and hardware compatibility can each fail independently.
Access questions
Tell us the barrier or setup you need us to understand.
Use the Early Access contact path for an accessibility question. Please avoid sending child clinical records or sensitive communication transcripts; a description of the device, input method and barrier is enough to start.