Accessibility Statement

Prodia Systems Limited designs the EyeSay website and product toward the principles of the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA, and toward the expectations of the European accessibility standard EN 301 549 for digital services.

• semantic HTML with a single main heading per page and a logical heading order;
• full keyboard operability, with visible high-contrast focus rings on every control;
• interactive targets sized to at least 44 by 44 CSS pixels, and usually larger;
• text set in Atkinson Hyperlegible, a typeface designed for letter-shape distinction, at a comfortable measure and line height;
• colour is never the only cue — state is also carried by shape, label, weight or icon;
• respect for the operating system's reduced-motion preference: motion is minimal and can be switched off entirely by that preference;
• a light and dark appearance, both checked for text contrast;
• the cookie dialog is keyboard reachable, focus-managed and dismissible;
• legal documents use a 70–80 character measure, a table of contents, and print styling.

The communicator app and the adult console are on a separate origin, and the design carries the same commitments plus AAC-specific ones:

• Stable motor positions. Permanent vocabulary does not move. Motor memory is an access feature, so context and suggestion logic has no ability to reorder the grid.
• Large targets by default, with the whole cell, label included, being the target.
• Text labels are first-class, not small captions under a symbol.
• Permanent agency words — STOP, NO, HELP, BREAK, TOILET — always present and never removable by ordinary editing.
• Scanning prototype with a predictable order, in which the adaptive halo is its own scan group and never reorders while a selection is in progress.
• Focus mode that de-emphasises cells visually without moving them.
• Word finder that highlights the route to a word rather than relocating it.
• High contrast and reduced motion settings in the app itself, independent of the operating system, plus light and dark appearance.
• ARIA labelling on grid cells, halo candidates and the utterance ribbon so a screen reader reports position and content.

Because this phase is delivered as an installable web app rather than a native iPad application, some limits come from the browser rather than from our design:

• speech output depends on the voices your device or browser provides; voice quality and available languages vary by platform;
• listening features depend on browser speech recognition, which is not available in every browser; where it is unavailable the app presents a clearly labelled manual mode instead;
• precise dwell selection, touch-on-release behaviour and external switch access are less reliable in a browser than in a native app; a native implementation is planned;
• eye-tracking and head-pointer hardware support is limited by browser pointer APIs;
• screen reader behaviour over a large grid varies between platforms;
• our third-party dependencies are chosen for accessibility, but we cannot warrant every component in every assistive-technology combination.

We test primarily on current Safari and Chromium browsers on iPad and desktop, with VoiceOver on Apple platforms and keyboard-only operation everywhere. Older browsers may work but are not part of our test set.

If something on this website or in the product blocks you, please tell us — accessibility reports get priority. Email contact@prodiasystems.com or write to Prodia Systems Limited, 27 Pembroke Street Upper, Dublin 2, D02 X361, Ireland. Describe the page or screen, the device and assistive technology you use, and what happened. We aim to reply within 10 working days and to tell you honestly whether and when we can fix it.

The product accessibility design is also described on our accessibility approach page.