Accessibility Statement

The Global Company, operator of Beamy AI, is committed to making our Service usable by as many people as possible, including people with disability.

We believe accessibility is a design requirement rather than a compliance exercise. A person using a screen reader, navigating by keyboard, relying on magnification, or working with reduced motion should be able to run a scan, read a report and manage a subscription without obstruction.

This statement applies to the beamy-ai.com website and the app.beamy-ai.com application.

We aim to conform to the Web Content Accessibility Guidelines (WCAG) version 2.2, Level AA, published by the World Wide Web Consortium.

WCAG defines requirements for making web content more accessible to people with a wide range of disabilities, including visual, auditory, physical, speech, cognitive, learning, language and neurological disabilities. Level AA is the level most commonly referenced in legislation worldwide.

Where WCAG 2.2 Level AAA success criteria are achievable without harming usability, we apply them. In particular, we aim to exceed the Level AA contrast requirement of 4.5:1 and instead meet the Level AAA requirement of 7:1 for body text throughout the Service, because we believe text that is merely legible is not good enough.

Beamy AI is partially conformant with WCAG 2.2 Level AA.

Partially conformant means that some parts of the content do not yet fully conform to the standard.

We have chosen to state this honestly rather than claim full conformance. Beamy AI is a young product under active development, and we have not yet completed a formal independent accessibility audit. Claiming conformance we have not verified would be misleading, and would not serve anyone who relies on this statement to decide whether the Service will work for them.

Section 6 sets out the limitations we currently know about.

Colour and contrast. We use a deliberately restricted palette. Body text is rendered in a single high-contrast ink colour on light backgrounds and a single high-contrast light colour on dark backgrounds, at full opacity. We do not use grey, faded or reduced-opacity text for content. Our amber brand colour is reserved for large display text, buttons and graphics, and is not used for body copy, because it does not meet our contrast target at small sizes.

Colour is never the only signal. Where we show whether a brand was found or absent in an AI answer, that state is conveyed by text and by shape as well as by colour, so it remains clear to people with colour vision deficiency.

Typography. Body text is set at a minimum of 19 pixels on desktop and 17 pixels on mobile, at a medium weight rather than a light one, with a line height of 1.7 and a maximum line length of approximately 68 characters. Text can be resized to 200 percent without loss of content or function, and the layout reflows to a 320 pixel viewport width without requiring horizontal scrolling.

Keyboard access. All interactive elements can be reached and operated with a keyboard alone. Focus order follows the visual order of the page. Focus indicators are visible and are not suppressed. Keyboard traps are avoided. Skip links allow keyboard users to bypass repeated navigation.

Semantic structure. Pages use correct heading hierarchy, landmark regions, and native HTML elements wherever possible. Form fields have persistent, programmatically associated labels rather than placeholder-only labels. Error messages identify the field and describe the problem in text.

Motion. The Service uses motion to communicate progress during a scan. All motion respects the prefers-reduced-motion setting: when that preference is set, animation is removed and content is presented statically and immediately. No content flashes more than three times per second.

Live status. A scan takes time to complete. Progress is announced through ARIA live regions so that screen reader users receive the same information as sighted users, without focus being moved unexpectedly.

Images and graphics. Meaningful images carry text alternatives. Decorative graphics, including the beam motifs used throughout the design, are hidden from assistive technology so they do not add noise.

Data. Tables use proper header associations. Where information is presented visually as a chart or score, an equivalent text form is available.

Timeouts. We do not impose short session timeouts that would disadvantage users who need more time.

We design the Service to work with current versions of screen readers, browser zoom and operating system magnification, speech recognition and voice control software, operating system high-contrast and dark modes, and keyboard-only navigation and switch access.

The Service is built with modern web standards and is designed for current versions of Chrome, Edge, Firefox and Safari. Accessibility may be degraded in older browsers or with older assistive technology, and we do not test against browsers that are no longer supported by their vendors.

We list these openly so you know what to expect. We are working on each of them.

No formal audit has been completed. Our assessment to date is based on internal review and automated testing. We have not yet commissioned an independent audit or completed structured testing with users who have disability. Until we do, there may be barriers we are not aware of.

AI-generated content is outside our control. A core function of the Service is to display, word for word, what third-party AI engines say about a brand. That text is generated by OpenAI, Google, Anthropic, Perplexity and similar providers. We cannot control its structure, its reading level, its length, or whether it uses lists, tables or plain prose. We present it in an accessible container with correct semantics, but the content itself is not ours to modify. Simplifying or rewriting it would defeat the purpose of the Service, which is to show you exactly what was said.

Complex data displays. The spectrum view, the score history and comparison views convey relationships between several dimensions at once. We provide text equivalents, but these views remain harder to interpret without sight than a simple list would be. We are continuing to improve the text alternatives.

Third-party components. Some parts of the Service are provided by others and their accessibility is determined by them, not by us. These include Cloudflare Turnstile, used to distinguish humans from automated scripts on our free scan; Stripe, used for checkout and billing; and fonts and other assets delivered by third-party networks. We selected providers that state a commitment to accessibility, and we monitor them. Where a third-party component creates a barrier, contact us and we will provide an alternative route to the same outcome, as described in section 8.

Legacy areas. Parts of the Service written earlier in development may not yet meet the standards described in section 4. We are progressively bringing them into line, and newer areas are built to the standard from the outset.

Downloadable content. Exported reports and files may not yet meet document accessibility standards in full. If you need an export in a specific accessible format, contact us and we will provide it.

Video and audio. We do not currently publish video or audio content. If we do, we will provide captions and transcripts before publishing, not afterwards.

Our current approach combines:

• Self-evaluation against the WCAG 2.2 Level AA success criteria during development
• Automated testing integrated into our development process, using standard accessibility testing tools
• Manual keyboard testing of every interactive flow
• Screen reader spot checks on the main user journeys
• Contrast verification of every text and background pair in our design system

We recognise that automated tools detect only a portion of accessibility issues. We intend to commission an independent audit and to conduct testing with people with disability as the product matures, and we will update this statement when we do.

If any part of the Service is not accessible to you, contact us. We will provide the information or complete the action for you by another means, supply a report or export in an accessible format you can use, offer an alternative route past any third-party component that creates a barrier, and give you a realistic timeframe for a permanent fix.

There is no charge for this, and requesting it will never affect your account, your subscription or how we treat you.

We want to hear from you. Feedback from people who encounter barriers is the most useful information we receive, and it is how this statement gets shorter over time.

When you contact us, it helps if you can tell us:

• The page or feature involved, and its web address if you have it
• What you were trying to do
• What happened, and what you expected
• The browser, operating system and assistive technology you were using, and their versions

We aim to acknowledge accessibility feedback within 2 business days and to respond substantively within 10 business days. If a fix will take longer, we will tell you why and when to expect it.

This statement is provided in the context of the following laws and standards. It is not a legal admission or a warranty of compliance.

Australia. The Disability Discrimination Act 1992 (Cth) makes it unlawful to discriminate against a person on the basis of disability in the provision of goods, services and facilities. The Australian Human Rights Commission's World Wide Web Access Advisory Note identifies WCAG as the relevant standard for web accessibility. If you believe you have been discriminated against, you may complain to the Australian Human Rights Commission.

European Union. The European Accessibility Act, Directive (EU) 2019/882, applies accessibility requirements to certain products and services, including e-commerce services, offered to consumers in the European Union. The relevant harmonised standard is EN 301 549, which incorporates WCAG. We are working toward conformance with these requirements. If you are in the EU and believe we are not meeting them, you may raise this with us and, if unresolved, with the enforcement authority in your member state.

United Kingdom. The Equality Act 2010 requires service providers to make reasonable adjustments so that disabled people are not placed at a substantial disadvantage. If you believe we have failed to do so, tell us and we will address it.

United States. Title III of the Americans with Disabilities Act prohibits discrimination on the basis of disability in places of public accommodation. The United States Department of Justice has taken the position that this extends to websites offering goods and services to the public, and has identified WCAG as an appropriate benchmark.

Enforcement. We would much prefer to fix a problem than to argue about one. Please contact us first. If we do not respond adequately, you retain every right you have under the law that applies to you, and nothing in this statement limits those rights.

Accessibility is not a project with an end date. Our current priorities are:

1. Completing the removal of low-contrast and low-weight text from every remaining area of the Service
2. Improving the text alternatives for the spectrum and score history displays
3. Structured screen reader testing across all main journeys, not only spot checks
4. Commissioning an independent accessibility audit
5. Testing with users who have disability
6. Accessible formats for exported reports

We review this statement at least every 12 months, and whenever we make a significant change to the Service.

To give accessibility feedback, request an alternative format, or raise a concern about accessibility:

The Global Company
Operator of Beamy AI
Email: privacy@beamy-ai.com

We treat accessibility feedback as a priority and we do not route it through general support queues.