Accessibility
OpenACAI should work for people using phones, keyboards, screen readers, larger text, lower motion, high contrast, printouts, and slower connections. This page explains what is available now and what future app clients must preserve.
Display controls
Set this device up for easier reading.
These controls save only in this browser. OpenACAI records that display options were used, but not which settings you chose.
What should work without asking.
Accessibility is not a separate service path. The public site, resource directory, forms workbench, GAMHON activities, and account preferences should keep core actions available with ordinary assistive technology and plain browser tools.
Keyboard first
Navigation, search, filters, form controls, details panels, and game actions should remain reachable without a mouse.
Screen reader structure
Pages use headings, landmarks, labels, status messages, and plain link names so visitors can skim by section instead of listening to an entire page.
Readable on phones
The layout is responsive, supports text scaling, keeps buttons large enough to tap, and avoids forcing people through tiny PDFs for core information.
Motion is optional
GAMHON activities and page interactions should not require animation, timed reactions, sound, or fast movement to understand the next step.
Print still matters
Resource lists, form notes, and checklists are designed so someone can leave with paper instructions when a device, battery, or internet connection is unreliable.
Private help stays careful
Contact and account pages use no-store behavior. Accessibility preferences stay local and do not include disability, health, or identity details.
Current public checks
- HTML language and mobile viewport are checked automatically
- Contact remains no-store while public pages can be cached
- Accessibility controls load before the page finishes painting
- Forms and account controls use labels and status messages
Future Android and iOS requirements
- Support VoiceOver and TalkBack labels
- Respect system text scaling and reduced motion
- Avoid custom gesture-only actions
- Keep crisis and emergency information outside animations
- Use web fallback for complex forms until native flows pass review
How to report a barrier
Use the contact page and include the page, device, browser, assistive technology if relevant, what you were trying to do, and what stopped you. Do not include passwords, full Social Security numbers, benefit case numbers, or private medical records.
Where the technical proof lives
The public accessibility contract is available at openacai-accessibility.json. Mobile clients use that document to keep app behavior aligned with the website.
Useful next steps