eyeHear Accessibility Statement

Last updated on November 4, 2026.

Our Commitment

eyeHear exists to serve people who are deaf or hard of hearing. Accessibility is not a feature we added — it is the entire purpose of the product. We are committed to making both the eyeHear iOS app and the eyehear.app website usable by the widest possible range of people, including those who rely on assistive technologies such as VoiceOver, Switch Control, Voice Control, and larger text sizes.

Conformance Status

We measure our work against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA (opens in a new tab) — the international standard most widely referenced by educational institutions, government, and enterprise procurement.

  • eyehear.app website: designed and built to conform to WCAG 2.2 Level AA. Every page provides a skip link, semantic landmarks, ordered headings, visible keyboard focus, labeled form controls, and color contrast meeting or exceeding the required ratios in both the light and the dark color scheme. Automated checks of these run on every change; see Assessment Approach for what has and has not been checked by a person.
  • eyeHear iOS app: built with Apple's native accessibility frameworks and evaluated against WCAG 2.2 Level AA as applied to native mobile software (per the Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) (opens in a new tab)). Our accessibility conformance report, a self-evaluation of version 1.7.3, rates each applicable criterion for the app as Supports, its top rating. See Known Limitations for what we have not checked by hand.

A detailed, criterion-by-criterion Accessibility Conformance Report (ACR / VPAT®) is published. Download the Accessibility Conformance Report (PDF). Questions about it? See Feedback & Accommodation Requests below.

Accessibility Features

The eyeHear app is built around the needs of deaf and hard-of-hearing users:

  • Large, high-contrast captions — captions display at a very large size. In the app's Settings → Caption Size, choose Shrink to Fit (the default), which fits the caption to the screen, or one Fixed Size.
  • Light and dark high-contrast themes — black-on-white and white-on-black, with caption and other text well above the required contrast ratios, and secondary text tuned to stay legible in each theme. The theme follows the device's appearance, or you can choose Light or Dark in the app's Settings; your choice is remembered between sessions.
  • Single-activation control — captioning can be started and stopped with a single activation through VoiceOver, or with the VoiceOver Magic Tap (two-finger double-tap) from anywhere on the screen, not only the press-and-hold gesture. We have checked it by hand with VoiceOver, Voice Control, Switch Control, and Full Keyboard Access on an iPhone.
  • Keyboard commands on iPad — with a hardware keyboard, a menu bar and shortcuts start and stop captioning (Command+L) and open Settings, History, and typing mode. We have not yet tried them by hand on an iPad.
  • Labeled controls — every icon-only button (History, Settings, Edit, New note, share, delete) has a descriptive VoiceOver label, and tap targets meet the recommended minimum size.
  • Caption exposed to screen readers — the caption is one element that is marked as frequently updating, so VoiceOver can follow it. We have checked by hand that VoiceOver and braille announce new words as they arrive.
  • Status announcements — captioning starting or stopping, and any errors, are announced to VoiceOver rather than signaled by color alone.
  • Reduce Motion support — screen transitions fall back to a simple fade when Reduce Motion is enabled.
  • Dynamic Type — all interface text follows your system text size. The live caption screen is deliberately always shown as large as the screen allows, and Settings has its own Caption Size control for it.
  • All orientations — works in portrait and landscape on iPhone and iPad.
  • On-device processing — speech recognition runs on your device where supported, and eyeHear never sends your conversations or recordings to its servers.

Known Limitations

We are transparent about where we fall short and are actively working to improve. Current known limitations include:

  • Caption accuracy. Captions can be wrong, and they can be incomplete or delayed, depending on background noise, accents, microphone quality, and network conditions. They are an aid, not a substitute for a qualified interpreter or CART provider.
  • iOS app: not checked by hand on iPad or iPhone Duo. We have checked the app by hand on an iPhone only. Its layouts on iPad and iPhone Duo, including History's side-by-side view, rest on automated tests and simulators.
  • Website: limited screen-reader testing. We have tested the eyehear.app website by hand with VoiceOver in Safari. In October 2026 we also ran scripted tests of every form on the site that record what a real screen reader says: Orca with Firefox and with Chromium on every form, and VoiceOver with Chrome and with Safari on every form but the newsletter signup and the survey. We have not tested with NVDA or JAWS, or with VoiceOver on iPhone. In Firefox, a required drop-down that nobody has touched yet is announced as "invalid entry"; that is the browser's own behavior, which the page cannot change. The controls added to the home page in October 2026, such as the Caption Size sliders and switches and the iPhone Duo switch, have not yet been re-checked with VoiceOver, so how they are spoken is unconfirmed.
  • Website: the security check on our forms. Our forms use Cloudflare's Turnstile security check, a third-party widget whose accessibility we do not control and have not checked with assistive technology. If it does not work for you, email support@eyehear.app instead; every one of our forms says so beside the check.

Important: eyeHear Is an Aid, Not a Formal Accommodation

eyeHear is a communication aid. It is not a substitute for a qualified human interpreter, CART (Communication Access Real-time Translation) provider, or other professional accommodation. You should not rely on eyeHear as the only means of communication when an inaccurate, incomplete, delayed, or missing caption could cause serious harm. Examples are emergency or safety instructions, informed consent, diagnosis or treatment discussions, medication or discharge instructions, legal proceedings, and financial commitments. This is not a complete list, and captions can be wrong in any conversation. In these situations, you should use eyeHear along with a qualified interpreter, CART provider, or other accommodation. If you need one, ask the person or organization you are dealing with to provide it. See our Terms of Use for the full disclaimer.

If you are captioning for someone whose first language is ASL, get an interpreter. English captions are not language access for them.

Assessment Approach

We assess the iOS app through automated checks (including an automated accessibility audit of its screens), Apple's Accessibility Inspector, and testing by hand with VoiceOver on an iPhone. On October 22, 2026 we also checked version 1.7.2 by hand on an iPhone with VoiceOver (including braille), Voice Control, Switch Control, Full Keyboard Access with a hardware keyboard, Increase Contrast, and the largest text sizes. Our automated checks cover labels, traits, and target size, not operation with these tools. On October 31, 2026 we also measured the typing screen in iPhone simulators at several text sizes and in both orientations, and ran a scripted VoiceOver walk through the captioning screen there. This found problems in version 1.7.2: notices and the keyboard button covering the typing editor, the editor's missing name, and VoiceOver's order. We also measured the colors of the Try Again button, the first-run permission button, and the primary button on the error sheet, which found low contrast in version 1.7.2. Version 1.7.3 fixes it, and on November 3, 2026 we checked those three buttons by hand on an iPhone, in Light and in Dark. We measured the speech-unavailable screen at the accessibility text sizes too, which found a large-text problem in version 1.7.2. Version 1.7.3 fixes these problems as well, and on November 3, 2026 we checked each fix by hand on an iPhone. Our conformance claims are self-evaluated; we have not engaged a third-party auditor.

For the eyehear.app website, automated checks run on every change, and the change cannot be released if they fail. They scan every page except the 404 page in the light and the dark color scheme (the 404 page is scanned in the dark scheme at serious and critical impact only), and the error and confirmation states of every form, with axe-core. They also test reflow at 320 CSS pixels and user text-spacing settings on every page, and spot-check reduced motion, keyboard focus rings and forced-colors rendering on the home page, using Chromium's emulation of Windows High Contrast. Focus visibility on other pages, forced colors on six pages, and target sizes were checked by scripts during the October 21 audit and are not re-run on each change. The browser checks that run before every release use Chromium only. On October 31, 2026 we also ran automated scans, a keyboard walk, text-size and reflow checks, and scripted key presses in the forms on demand, in Chromium, Firefox, and WebKit, the engine Safari uses. The text size was the browser's own setting in Chromium and Firefox, and an approximation in WebKit. We have not run them in Safari itself or on a phone.

An audit dated October 21, 2026 read the source and tested the site in a browser against WCAG 2.2 Level A and AA. None of this replaces a screen-reader test. We have tested the website by hand with VoiceOver in Safari. On October 30 and 31, 2026 we ran scripted tests of every form with Orca (in Firefox and Chromium) and, for all but the newsletter signup and the survey, with VoiceOver (in Chrome and Safari). See Known Limitations.

eyeHear was built for, and with input from, a deaf family member. We have not yet had a structured accessibility review led by deaf or hard-of-hearing testers, and the technologies listed above do not substitute for one. If you are a deaf or hard-of-hearing person, or an organization, willing to review eyeHear, please write to support@eyehear.app.

Managed Deployment for Institutions

eyeHear supports Apple managed app configuration (MDM), so institutional administrators can centrally disable in-app sharing, and turn off or limit how long captions are kept in History, to meet privacy and data governance requirements. Policy is enforced entirely on-device with no added telemetry. If your organization is evaluating eyeHear for Orgs, an upcoming paid offering, you can register interest.

Feedback & Accommodation Requests

We welcome your feedback. If you encounter an accessibility barrier in eyeHear, or if you have a question about our published Accessibility Conformance Report (ACR / VPAT) or need a specific accommodation, please contact us at support@eyehear.app, through our support page, or with the form below. We'll reply by email.

Report an Accessibility Issue

Tell us what happened, which page or screen you were on, and what assistive technology you were using. We need your email so we can reply. Everything else is optional.

We use your email and message only to respond. See our privacy policy.

Please leave out patient or student names and other identifying details here.

Add app and device details (optional)

These help us find the cause faster. Skip any you're not sure about; it won't hold up your message.

If the security check doesn't work for you, or you'd rather not use a form, email support@eyehear.app instead.

Your message may mention your hearing or other health details. We use them only to answer you, and our service providers process them on our behalf. You can leave them out and still write to us. See our Consumer Health Data Privacy Policy.