Accessibility Statement
Fields to complete (8)
Every bracketed item below appears in this document and must be filled in, chosen, or confirmed before use.
- [ACCESSIBILITY AUDIT TARGET DATE]
- [ACCESSIBILITY CONTACT NAME]
- [ACCESSIBILITY EMAIL]
- [ACCESSIBILITY REVIEW DATE]
- [ACCESSIBILITY STATEMENT DATE]
- [LEGAL EMAIL]
- [SUPPORT PHONE]
- [TORVARA ENTITY]
1. Our commitment
[TORVARA ENTITY] wants everyone, including people who use assistive technology, to be able to use the web applications we build and operate. We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, which is the standard we treat as the benchmark for accessibility under the Americans with Disabilities Act as it is applied to websites and web apps of businesses open to the public. We apply the same standard to the pages we build for our clients, since their customers are members of the public.
2. What we do
- Build every console and portal with semantic HTML (headings in order, lists, tables with header cells, labeled form fields, landmark regions) so screen readers can navigate them.
- Make every interactive control reachable and operable by keyboard, with a visible focus indicator, and avoid keyboard traps.
- Maintain text contrast of at least 4.5:1 for body text and 3:1 for large text and interface components, in both light and dark themes.
- Respect the user's system preferences for color scheme and reduced motion.
- Allow text to be resized to 200% and pages to reflow at 320 CSS pixels wide without horizontal scrolling of the page body.
- Provide text alternatives for meaningful images and icons, and captions or transcripts for videos we produce for the web where the video carries information.
- Give form errors in text, next to the field, and never rely on color alone to convey status.
- Make target sizes for buttons and links at least 24 by 24 CSS pixels, with the primary actions larger.
- Provide a way to skip repeated navigation and use consistent navigation and naming across pages.
- Test new pages with keyboard-only navigation, a screen reader (VoiceOver on macOS and iOS), browser zoom, and an automated checker (such as axe or Lighthouse) before release.
3. Known limitations
We are a small team and our applications are new. We are aware of the following limitations and are working on them. This list is reviewed and updated at each release.
- Map views. Location pages use interactive map tiles that are not fully operable by keyboard or screen reader. Every map is accompanied by a text address and directions link, which provide the same information.
- AI-generated media. Images and video generated for ads may lack descriptive alternative text until a person writes it; we add alt text before publishing on the web, but social platforms may not display it.
- Charts and dashboards. Some analytics charts in consoles are drawn as graphics; the underlying figures are provided in an adjacent table or can be exported.
- Hosted-page environment. Pages hosted on the claude.ai artifact platform are wrapped by that platform's own interface, whose accessibility we do not control.
- Third-party content. Content on Meta, Google, and other platforms is presented in those platforms' interfaces.
- Formal audit. We have not yet had a third-party accessibility audit; our conformance claim is based on internal testing. A formal audit is planned for [ACCESSIBILITY AUDIT TARGET DATE].
4. Compatibility
Our applications are designed to work with current versions of Chrome, Safari, Firefox, and Edge on desktop and mobile, and with VoiceOver, NVDA, JAWS, and TalkBack. They may not work correctly with browsers more than two major versions old.
5. Feedback and accommodation
If you have difficulty using any part of our applications, or need information in a different format, please tell us and we will help. Contact [ACCESSIBILITY CONTACT NAME] at [ACCESSIBILITY EMAIL] or [SUPPORT PHONE]. Please describe the page, what you were trying to do, and the assistive technology you use. We aim to respond within 3 business days and to provide the information or service you need by an alternative method (for example, by phone, email, or a plain document) while we fix the underlying issue. If you are dealing with one of our client businesses, you may also contact that business directly; it will forward technical issues to us.
6. Enforcement and formal complaints
If you are not satisfied with our response, you may contact us again at [LEGAL EMAIL] and ask for the matter to be reviewed by a founder. You also have the right to file a complaint with the U.S. Department of Justice or your state's civil-rights agency.
7. Technical specifications
Accessibility of our applications relies on HTML, CSS, JavaScript, and WAI-ARIA, used according to their specifications and the WCAG 2.2 techniques. This statement was prepared on [ACCESSIBILITY STATEMENT DATE] and follows the W3C's recommended structure for accessibility statements.