Accessibility Statement

Technology that works only for some people is unfinished. We are building Gbuild so that people of all abilities can use it — not as an afterthought, but as a foundation of how we design, build, and test everything.

Accessibility is not a checklist we complete and set aside. It is ongoing work, and we hold ourselves accountable to it. When we fall short, we want to know — and we treat that feedback with the same urgency as any other defect.

We work toward conformance with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — the widely adopted standard for making digital products perceivable, operable, understandable, and robust for everyone. While we have not yet completed a formal third-party audit, WCAG 2.2 AA guides every design and engineering decision we make.

These are the areas we actively design for today:

• Screen readers and assistive technology. We work to ensure that interactive elements are properly labeled, that content is structured with semantic HTML and ARIA attributes, and that the application is navigable with VoiceOver and other screen readers.
• Keyboard and switch input. Every core interaction in Gbuild is designed to be reachable without a mouse or trackpad. Focus order follows a logical sequence, and focus indicators are visible. Customizable hotkeys let you adapt Gbuild to the input method that works for you.
• Voice input. Gbuild is voice-first by design. You can talk to G using push-to-talk or always-on listening, with speech transcribed on-device by default. Voice is a primary input method, not an add-on.
• Color contrast and visual clarity. We design for sufficient contrast between text and background, and we offer multiple theme options — including high-contrast modes — so you can choose the visual presentation that works best for you.
• Reduced motion. Gbuild respects the macOS "Reduce Motion" system preference. When enabled, animations are simplified or removed. An in-app toggle provides additional control for people who are sensitive to motion but prefer not to change the system-wide setting.
• Neurodiversity. We design with awareness that people process information differently. Neurodivergent people — including people with ADHD, autism, dyslexia, and other cognitive differences — deserve interfaces that respect varied attention, processing, and sensory needs. We aim for clear language, predictable layouts, and controls that do not rely on time pressure.
• Captions and text alternatives. Where Gbuild generates or presents audio content, we work to provide text alternatives — including captions for speech and descriptive labels for visual-only content.

Gbuild is under active development, and some areas of the application do not yet meet the standard we are working toward. We are aware of limitations in the following areas and are actively improving them:

• Some advanced visual interfaces — such as the terminal grid and 3D canvas elements — have limited screen-reader support today. We are working to add meaningful text alternatives and keyboard navigation to these surfaces.
• Not all animations fully respond to the reduced-motion preference in every context. We are auditing and correcting these on a rolling basis.
• Complex drag-and-drop interactions may not yet have full keyboard equivalents.

If you encounter a barrier not listed here, please tell us — we want a complete picture so we can prioritize effectively.

Accessibility feedback is prioritized, never filed away. If Gbuild creates a barrier for you — whether it is something we have listed above or something we have missed — we want to hear about it.

Email us at [email protected] with a description of what you experienced and, if possible, the feature or screen where it happened. We read every message and will follow up with you directly.

You can also learn more about our broader commitment to inclusion and universal design on our Our Promise page.