Hawi Agents Accessibility Statement

Last updated: 22 August 2026

1. Our commitment

Hawi Inc., operating Hawi Agents ("Hawi", "Hawi Agents", "we", "us" or "our"), is committed to making Hawi's websites, applications and digital services accessible and usable by as many people as reasonably possible, including people with disabilities.

We want people to be able to understand, navigate, configure and operate Hawi regardless of vision, hearing, mobility, dexterity, speech, cognitive ability, learning or neurological difference, temporary impairment, situational limitation, device, input method or assistive technology.

Accessibility is an ongoing design, engineering and content responsibility. It is not treated solely as a compliance exercise.

2. Services covered

This statement applies to Hawi-controlled digital experiences that link to it, including HawiAgents.com, the Hawi web application and, where available:

• Account, authentication and Workspace interfaces;
• Agent creation, management, chat, activity and approval interfaces;
• team chat, Boards and notifications;
• Connected Service and integration management;
• billing, subscriptions, credits, usage and financial controls;
• marketplace, creator and voice-related interfaces;
• privacy, security and support controls; and
• other Hawi web-based functionality.

Third-party websites, applications, authentication pages and services reached through Hawi have their own accessibility practices and are not necessarily controlled by Hawi.

3. Our accessibility target

Hawi's accessibility engineering target is the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, for Hawi-controlled web content and functionality where those guidelines apply.

WCAG is organised around four principles: content and controls should be perceivable, operable, understandable and robust. Hawi uses those principles when designing and reviewing the Services.

Hawi may meet some Level AAA criteria where practical, but does not claim that the entire Service conforms with Level AAA.

4. Current conformance position

Hawi is working toward WCAG 2.2 Level AA.

Hawi has not yet completed a sufficiently comprehensive independent accessibility audit to support a claim that every page, component, workflow or third-party integration fully conforms with every WCAG 2.2 Level AA success criterion. Some functionality may already satisfy relevant requirements while other functionality may still need review, improvement or remediation.

We would rather describe this position accurately than claim complete compliance based only on automated scanning. This statement will be updated when representative testing provides enough evidence to describe the conformance position more precisely.

5. Using Hawi accessibly

Hawi is designed with the goal that important tasks can be completed without relying on a particular physical ability, sensory characteristic or input device. These tasks include creating and accessing an Account, signing in, navigating Workspaces, creating and controlling Agents, connecting integrations, reviewing activity, using chat, managing billing and privacy settings, reviewing approvals, completing forms and understanding errors.

Keyboard operation and focus

Important Hawi functionality should be operable without a mouse. Where technically appropriate, users should be able to move through controls, activate buttons and links, operate menus and forms, open and close dialogs, select options and submit information using a keyboard.

Keyboard users should not become trapped inside a component. Focus should be visible, follow a meaningful order, move appropriately when a dialog opens, and return appropriately when it closes. Focused controls should not be completely obscured by sticky headers, overlays or banners.

Hawi uses skip navigation, landmarks, headings and semantic regions where appropriate so users can move past repeated navigation and reach primary content efficiently.

Screen readers and semantic structure

Hawi seeks to work with modern screen readers through semantic HTML, meaningful page titles, language identification, headings, landmarks, labels, lists, tables, form relationships, accessible names and descriptions. ARIA is used to supplement native semantics when necessary, not as a substitute for correct native elements.

Icon-only controls should have meaningful accessible names. Decorative images and icons should be hidden from assistive technology where announcing them would add noise. Links should use understandable text rather than ambiguous wording where practical.

Dialogs, menus and dynamic status

Dialogs, menus, sheets and overlays should expose an accessible name and state, preserve a logical focus order, prevent inappropriate interaction with obscured content and return focus when closed.

Important dynamic updates, such as an Agent being created, a message being sent, an integration connecting, a task completing, a payment succeeding or an error appearing, should be communicated to assistive technology where appropriate. Loading and processing states should not rely only on visual animation.

6. Forms and authentication

Forms are central to Hawi. We aim to provide clear labels, understandable instructions, appropriate input types, meaningful error messages and programmatic relationships between errors and affected fields.

Required status should not be communicated through colour alone. When an error occurs, Hawi should identify what went wrong, which field is affected and, where reasonably possible, how to correct it.

Authentication and verification should avoid unnecessarily excluding users with disabilities. Hawi seeks not to rely exclusively on visual puzzles, image recognition, memorising complex information or precise movement. Where a security mechanism creates an accessibility barrier, we will investigate an accessible alternative that maintains appropriate security.

Where reasonably possible, multi-stage processes should preserve information already entered instead of requiring unnecessary re-entry. Important transactions and changes should provide review, correction, confirmation or reversal where appropriate.

7. Colour, contrast and visual presentation

Hawi should not rely on colour alone to communicate important meaning. A successful, pending or failed state should also be available through text, an accessible icon or another non-colour cue.

We aim to meet WCAG 2.2 AA contrast requirements for normal and large text, buttons, form controls, focus indicators, icons, status indicators and meaningful graphics. Dark mode does not automatically provide sufficient contrast, so dark surfaces, placeholder text, disabled controls, subtle borders, charts and selected states are reviewed separately.

Where reasonably possible, Hawi should remain usable when users:

• enlarge text using browser or operating-system controls;
• use significant browser zoom;
• alter line height, paragraph, letter or word spacing;
• use desktop, laptop, tablet or mobile-sized layouts; or
• change device orientation.

At increased zoom, essential text and controls should remain available, content should reflow where required and unnecessary page-level horizontal scrolling should be avoided.

8. Motion, time and input methods

Some Hawi interfaces use transitions, loading indicators and other motion. Hawi aims to respect the prefers-reduced-motion setting and reduce or remove non-essential animation while preserving understandable state changes and feedback.

Hawi does not intend to create content that flashes at a frequency known to create seizure risk. Essential information should not rely on rapidly changing content, unexpected sound or animation.

Where Hawi imposes a time limit, we consider whether warning, extension, cancellation or an alternative is needed. Security-related expiry may still require a user to authenticate again, but Hawi should avoid unnecessary loss of user-entered information where reasonably possible.

Essential functionality should not depend only on precise drag-and-drop, complex multipoint gestures or path-based movements. Where required, an accessible alternative should be available. Controls should have appropriate target size and spacing for users with limited dexterity.

Sound should not be the only way important information is communicated. Audio notifications should generally have a visual or textual equivalent.

9. Hawi Agent experiences

Agent interfaces introduce dynamic and sometimes consequential information. Hawi aims to make it possible to identify what happened, when it happened, the current status, whether action is required and the result.

Agent states such as active, paused, waiting, failed, awaiting approval, completed, disconnected or rate limited should use more than colour alone.

Agent and team chat should allow users to distinguish participants, navigate the conversation, identify new responses, access attachments and operate message controls by keyboard and assistive technology. Incrementally streamed responses should avoid excessive screen-reader interruption.

Agent-generated content may not always have ideal headings, link wording, table structure or image descriptions. Hawi seeks to render generated information through accessible components where reasonably possible, but cannot guarantee that every generated response will be perfectly structured or accurate.

Approval interfaces for purchases, financial actions, permissions, deletions and other consequential actions should clearly identify what is being approved, the relevant Agent, amount where applicable, consequence and available action. Important actions should use safeguards such as confirmation, review, validation, approval, cancellation or clear warning where appropriate.

10. Content, documents and media

Hawi-controlled tables should expose row and column relationships to assistive technology. Where charts or visualisations communicate essential information, we aim to provide an accessible alternative such as a text summary, labels, numerical values, tabular data or structured download where appropriate.

Meaningful images should have suitable text alternatives. Icons should not be the only carrier of essential meaning unless that meaning is otherwise programmatically available.

Prerecorded video with meaningful spoken content should have captions where appropriate. Essential visual information may require audio description, a descriptive transcript or another alternative. Prerecorded audio should have an appropriate text alternative where required.

Voice functionality is not intended to be the only way to access essential Account or management controls. Where transcripts are provided, Hawi seeks to make them selectable, structured, navigable and readable by screen readers. Automated captions and transcripts may misinterpret names, accents, technical terms, numbers or speech in noisy environments, so critical information should be verified.

Important Hawi legal and policy information should be available as accessible HTML wherever practical. Hawi-produced documents should use meaningful headings, logical reading order, descriptive links, accessible tables and image descriptions where reasonably practicable. If an important PDF is published, Hawi should seek to provide an accessible PDF or equivalent HTML version.

11. Third-party services and content

Hawi integrates with third-party products and platforms. External authentication, consent, payment, financial connection and Connected Service pages may be controlled by those providers. Their accessibility can depend on the provider's own implementation.

Customer-uploaded files, user-generated marketplace content and information retrieved from external services may be inaccessible. Examples include image-only PDFs, uncaptioned video, poorly structured spreadsheets, embedded widgets and inaccessible external pages. Hawi cannot guarantee the accessibility of every item supplied by a Customer, creator or provider.

Where a significant third-party barrier affects a core Hawi journey, we will consider reasonable alternatives where possible. When Hawi renders retrieved information inside Hawi, we aim to make the Hawi-controlled presentation reasonably accessible.

Security, CAPTCHA and anti-abuse tools can also create barriers. Where such a mechanism is used, Hawi aims to minimise exclusion and provide an accessible alternative where reasonably possible.

12. Mobile, browser and assistive-technology support

Hawi aims to maintain readable text, appropriate target sizes, responsive layout and sensible reading order on supported mobile-sized screens, including compatibility with modern mobile assistive technologies.

Accessibility may be reduced with very old or unsupported browsers, operating systems or assistive technologies. It is not practicable to test every combination of browser, operating system, device, assistive technology and configuration. Hawi prioritises common, reasonably current combinations and expands testing over time.

Relevant technologies may include screen readers, keyboard-only navigation, browser zoom, screen magnification, voice control, switch access and operating-system settings such as reduced motion.

13. Testing and continuous improvement

Hawi's accessibility testing may combine:

• automated accessibility scanning;
• semantic HTML and code inspection;
• keyboard and focus-order testing;
• contrast checking;
• zoom, text-spacing and responsive-layout testing;
• screen-reader testing;
• form and error-state testing; and
• manual review against applicable WCAG criteria.

Automated tools alone are not enough to establish conformance. They cannot reliably decide whether alternative text is meaningful, focus order makes sense, instructions are understandable, an error is useful or a screen-reader workflow is coherent.

Accessibility should be considered during design, implementation, code review, testing and release. Improving a shared component can improve many areas at once, so Hawi seeks to address issues at the component-system level where possible.

Where reasonably practicable, Hawi intends to consider feedback and testing from people with disabilities and people who use assistive technologies.

14. Known and potential limitations

Hawi is an evolving product with complex dashboards, dynamically generated Agent content, real-time responses, third-party integrations, external authentication and payment pages, user-uploaded content and third-party documents. Accessibility issues may therefore exist.

Until a representative audit is completed, Hawi cannot provide an exhaustive list of every unresolved issue. Areas receiving particular review include:

• keyboard navigation through complex dashboards;
• focus management in dialogs and overlays;
• streaming Agent responses and dynamic notifications;
• charts, complex tables and drag-and-drop interfaces;
• payment, financial connection and Connected Service flows;
• file previews, generated and marketplace content; and
• voice-related functionality.

If a limitation prevents an essential task, please contact us so we can investigate the barrier and consider an alternative.

15. Improvement priorities

Hawi's accessibility work may include auditing shared components, improving keyboard support and focus management, increasing contrast, improving labels and validation, reviewing dialogs and status announcements, testing mobile layouts, reducing unnecessary motion, improving tables and charts, reviewing onboarding and Account settings, and incorporating accessibility into release review.

Issues may be prioritised according to severity, impact on essential functionality, number of affected users, frequency, available workaround and remediation complexity. A barrier that prevents an essential task should generally receive higher priority than a cosmetic issue.

Core priorities for Hawi include Account access, Agent creation and control, Workspace navigation, integration permissions, human approvals, financial controls, messages, Agent status, error information, privacy settings, billing, security settings, Account deletion and support.

16. Report an accessibility problem

We welcome feedback from users who encounter an accessibility barrier.

Email hello@hawiagents.com and tell us what you were trying to do, what prevented you from doing it and which part of Hawi you were using. You do not need to disclose a diagnosis or the nature of your disability.

If you are comfortable providing them, the page or feature, browser, operating system, device, assistive technology, screenshot, recording or error message can help us investigate. Please do not send passwords, API keys or other authentication secrets.

Hawi has not published accessibility@hawiagents.com as an active contact method because the availability of that dedicated mailbox has not been verified.

17. Our response and accessible alternatives

We aim to review accessibility feedback in good faith. Where we identify a barrier, we may provide guidance or an alternative, correct the issue, add it to planned remediation, or explain why a particular solution is not currently reasonably practicable.

If Hawi-controlled information is inaccessible, ask for an alternative and identify the information you need and the format that would work for you where known. Depending on the information, alternatives may include accessible HTML, plain text, an accessible document, structured data or a text explanation.

If email is not accessible to you, use another Hawi contact method available to you and ask for an alternative form of communication.

18. Privacy, security and non-discrimination

An accessibility request may include Personal Data, for example information about an assistive technology or access requirement. Hawi should process that information only as necessary to respond, provide support, improve accessibility and comply with applicable law. Detailed medical records are not required to report a barrier.

Hawi will not intentionally disadvantage a user merely because they report a barrier, use assistive technology, request an accessible alternative or ask for a reasonable accessibility accommodation.

Accessibility and legitimate security requirements sometimes need to be considered together. Hawi seeks solutions that protect both security and equitable access. Security should not be used as a blanket justification for avoidable barriers.

19. Legal position and business customers

Accessibility obligations differ by jurisdiction, organisation, service and user relationship. Nothing in this statement is intended to reduce or replace rights available to disabled people under applicable law.

Hawi recognises the importance of accessibility, non-discrimination and reasonable adjustments for users in the United Kingdom. Hawi is a private commercial service and does not claim that the United Kingdom Public Sector Bodies accessibility regulations apply to all Hawi services unless the circumstances bring a particular service within their scope.

Business, enterprise and public-sector Customers may have accessibility obligations beyond Hawi's own. Customers remain responsible for assessing their own services, including how Hawi is incorporated into them. Customers seeking accessibility information for procurement may contact Hawi about available assessments, known issues, testing and remediation information.

Hawi will not claim that W3C, the UK Government, a regulator or another organisation has certified Hawi unless that certification has actually occurred.

20. Contact

Company: Hawi Inc.

Website: HawiAgents.com

Accessibility and general contact: hello@hawiagents.com

This statement was prepared on 22 August 2026 and was last reviewed on 22 August 2026. Hawi intends to review it after significant accessibility audits, after material product changes affecting accessibility, when known limitations change, and at least annually as a good-practice baseline.

The registered-office address and a dedicated accessibility mailbox have not been published here because they have not been verified. This statement should be updated when those details are confirmed.

© 2026 Hawi Inc. All rights reserved.