Accessibility Statement

01Our commitment

We believe a business website should be usable by everyone — including people who use screen readers, keyboard-only navigation, voice control, screen magnification, reduced-motion settings, or any other assistive technology. Accessibility isn't an optional polish layer on top of a design; it's part of building software well.

As a small studio, we don't have a dedicated accessibility team. What we do have is a commitment to: design with accessibility in mind from the start, test with assistive technology where we can, take feedback seriously, and continuously improve. This statement reflects that posture honestly — including where we know we have work to do.

02Standard we aim for

We work toward conformance with the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, as published by the World Wide Web Consortium (W3C). WCAG 2.1 AA is the standard referenced by:

• The Americans with Disabilities Act (ADA) and Department of Justice guidance for commercial websites in the United States
• The Disability Discrimination Act 1992 (Cth) and Australian Human Rights Commission guidance in Australia
• Section 508 of the US Rehabilitation Act (for federal procurement)
• The European Accessibility Act and equivalent frameworks in the EU/UK

WCAG 2.1 AA is a practical, internationally recognised benchmark. It's the level we aim for across all pages.

03Conformance status

This website is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some parts of the content do not fully conform to the accessibility standard.

The Site has not yet undergone a formal third-party accessibility audit. Our conformance assessment is based on internal review against the WCAG 2.1 success criteria. We'll commission an independent audit as the studio grows and the operation justifies it — we'd rather be honest about where we are than overstate our compliance status.

04Measures we've taken

The Site is built with accessibility in mind. Specifically, we have:

• Semantic HTML. Used standard HTML5 elements (nav, main, article, section, header, footer) so the document structure is meaningful to assistive technology, not just visually.
• Keyboard navigation. All interactive elements — links, buttons, form fields, navigation menus — are reachable and operable using a keyboard alone, without requiring a mouse or touch input.
• Visible focus indicators. Interactive elements show a clear focus state so keyboard users can see where they are on the page.
• Form labels. Every form field has a programmatically associated label element. Required fields are marked clearly. Optional fields are noted explicitly.
• Alternative text on meaningful images. Decorative images are marked as such; informative images include descriptive alt text.
• Reduced-motion respect. Where the Site uses animation, we honour the prefers-reduced-motion media query so users who've configured their system to minimise motion don't see animations.
• Colour contrast. Body text meets the WCAG 2.1 AA contrast ratio of 4.5:1 against its background. Large text and UI components meet the 3:1 ratio.
• Responsive layout. The Site reflows for narrow viewports (mobile), zoom levels up to 200%, and screen magnification.
• ARIA where needed. Where native HTML doesn't communicate enough context to assistive technology, we use ARIA labels and roles judiciously — not as a substitute for semantic HTML, but to fill gaps.
• Descriptive link text. Links describe their destination ("Read our refund policy") rather than relying on generic phrases ("click here") that don't make sense out of context.

05Known limitations

We're aware of the following areas where the Site may not fully meet WCAG 2.1 AA. We treat these as items to address, not acceptable defaults:

• Decorative animation. The Site uses several animated elements (the hero grid, the chat demo, the process timeline, the integrations marquee). We honour reduced-motion preferences where set, but the default experience may be unsuitable for users with vestibular sensitivity who haven't set that preference.
• Custom interactive components. Some interactive elements use custom styling rather than browser-native controls. We've worked to make these keyboard-accessible and screen-reader-friendly, but they may not behave identically to native controls in every screen reader / browser combination.
• Demo content. The "live demo" sections of the Site (animated chat, voice call simulation) present content in a way that may be challenging for some assistive technologies to interpret. The same information is available in the surrounding prose.
• No third-party audit yet. We have not commissioned an independent WCAG 2.1 AA audit. Issues we haven't identified internally may exist.
• Embedded video (if added). Where the Site embeds video content, captions and transcripts may not always be available. If you need a transcript of any video, contact us and we'll provide one.

If you encounter a barrier not listed here, please tell us — see Section 07.

06Compatibility

Browsers

The Site is designed to work with recent versions of:

• Google Chrome
• Mozilla Firefox
• Apple Safari (macOS and iOS)
• Microsoft Edge

We don't actively test in legacy browsers (Internet Explorer, very old mobile browsers). The Site may still function but accessibility features may not work as intended.

Assistive technology

We aim for compatibility with common assistive technologies, including:

• Screen readers — NVDA (Windows), JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android)
• Voice control — Dragon NaturallySpeaking, macOS/iOS Voice Control, Windows Speech Recognition
• Screen magnification — ZoomText, browser-native zoom up to 200%
• Keyboard-only navigation
• High-contrast and dark-mode preferences

We don't test against every combination of browser + assistive technology + operating system. If you use a configuration that doesn't work well, please let us know — that feedback directly improves our coverage.

07Reporting an issue

If you encounter an accessibility barrier on this Site, we want to know. Reports help us identify issues we may not have caught and prioritise fixes.

How to report

Email accessibility@highflowai.com with:

• The page or feature where you encountered the issue (URL helps)
• What you were trying to do
• What happened (or didn't happen)
• What assistive technology, browser, and operating system you were using, if you're comfortable sharing

You don't need to know the technical cause or use specific terminology. A plain description of the problem is enough.

What we commit to

• Acknowledge your report within two (2) business days.
• Provide a substantive response within ten (10) business days, including either: a fix, a timeline for the fix, or an alternative way to access the information.
• Keep you informed as we work on the issue.
• Treat accessibility issues seriously — meaning they go into the same backlog as other defects, not a "nice to have" pile.

If we can't fix something quickly

Some issues take longer to address than others, particularly for custom-built components. If a fix isn't possible immediately, we'll provide the information you needed another way — see Section 08.

08Alternative formats

If any content on the Site isn't accessible to you, we'll provide it another way at no cost. Options include:

• Plain-text version of a page sent by email
• Audio walkthrough or phone call to explain content or guide you through a process
• Transcript for any embedded video or audio content
• Direct human contact in place of any self-serve flow (for example, booking a call directly with us rather than using an online booking form)

To request any of the above, email accessibility@highflowai.com or info@highflowai.com, or call us on +1 (832) 924-7478. We aim to provide the alternative within five (5) business days of your request, sooner if possible.

We will never charge you for an accessible alternative to content available on the Site.

09Ongoing work

Accessibility is not a one-time exercise. Our ongoing approach includes:

• Reviewing accessibility when we add new pages or features, not only when issues are reported
• Testing with keyboard navigation and at least one screen reader as part of our pre-release process
• Tracking reported issues and turning them into concrete fixes with timelines
• Annual review of this statement and our conformance posture
• Commissioning an independent audit as the operation grows — we expect to do this within the next 12 months

If you have suggestions for how we could improve our accessibility practice beyond just fixing specific issues, we'd genuinely welcome them.

10Contact us

For accessibility issues, alternative format requests, or any feedback on this statement: