Access AI policies
Accessibility Statement
Accessibility is the purpose of Access AI. The product direction is designed around blind and low-vision users and informed by founder Anthony Pope's experience with vision loss.
No formal conformance claim: This statement describes goals, implementation choices, and known limitations. It is not a claim of formal WCAG, ADA, or other accessibility conformance.
Website accessibility features
- Semantic headings, landmarks, lists, links, buttons, details, fieldsets, and labels.
- A skip link and consistent page navigation.
- Visible keyboard focus and large primary controls.
- High-contrast colors, responsive layouts, text wrapping, and no essential color-only meaning.
- Reduced-motion and forced-color support.
- A keyboard-accessible consent banner, native dialog, explicit choices, and live status messages.
- Core content and email links remain usable without JavaScript; JavaScript is limited to consent and analytics enhancements.
Product accessibility goals
- Complete onboarding without sighted assistance.
- Support Android TalkBack and standard screen-reader gestures.
- Keep text entry compatible with software keyboards and Braille input services.
- Provide clear labels, logical focus order, spoken setup, and spoken answers when enabled.
- Avoid essential tasks that depend only on color, imagery, drag gestures, or custom swipes.
- Use practical relative positions, clock-face references, landmarks, and explicit uncertainty when supported by the available image.
Testing approach
Automated checks can detect some markup, contrast, link, and code problems but cannot prove real-world usability. Keyboard, zoom, reflow, reduced-motion, screen-reader, browser, and mobile checks are part of the website review. Physical-device and assistive-technology testing remains necessary for product milestones.
Known limitations
- Browser-dependent speech, recording, permission, and focus behavior in the Streamlit proof of concept.
- Differences among screen readers, Android devices, speech engines, browsers, and Braille input services.
- AI output that can be incomplete or inaccurate.
- Features that depend on network, camera, microphone, or third-party service availability.
- Native Android camera, production voice recognition, and smart-glasses functions that remain development work or plans.
Feedback
Email founder@access-ai.tech. When useful, include the page or task, device, browser, assistive technology, and what you were trying to do. Do not include unnecessary sensitive information.