Accessibility

1.Our commitment

Aiome is where a team communicates, tracks its work, and requests time off. If someone cannot use it, they cannot do their job — so accessibility is not a compliance checkbox for us; it is a question of whether the product works for everyone it is bought for.

2.The standard we work to

We target Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, published by the W3C. It is the standard referenced by the Americans with Disabilities Act in practice, by Section 508 of the U.S. Rehabilitation Act, and by the European Accessibility Act and EN 301 549.

This statement covers aiome.io and the Aiome web application.

3.Current status

Aiome is partially conformant with WCAG 2.2 Level AA. "Partially conformant" means most of the standard is met but some parts are not yet verified or not yet met.

We say partially rather than fully for a specific reason: we have not yet commissioned an independent accessibility audit. Our assessment is based on our own testing — automated checks, keyboard navigation, and screen reader spot checks. That is a genuine effort, but it is not the same as an expert review, and we will not claim otherwise.

We intend to commission an independent audit as the company grows. When we do, we will publish the date, the auditor's name, and whatever the revised conformance claim turns out to be — including if it is less flattering than this one.

4.Known limitations

We are aware of the following, and are working on them:

• Product screenshots and interface illustrations on our marketing pages are decorative recreations of the app. They are hidden from assistive technology, and the surrounding text carries the meaning — but a user relying on a screen reader gets less from those sections than a sighted user does.
• Animated content on our marketing pages. Several of them use motion — a scrolling feature carousel, drifting background shapes, and animated counters. All of that respects the prefers-reduced-motion setting in your operating system, and switching it on stops the animation.
• Comparison and data tables scroll horizontally on small screens. They are navigable by keyboard, but on a narrow viewport this requires more effort than it should.
• Third-party components. Parts of our site and checkout flow are provided by other companies, including our payment provider and our website platform. We influence but do not control their accessibility.
• Uploaded content. Files, images, and documents that your own team uploads into a workspace are outside our control. If a colleague uploads an image without a description, we cannot supply one.

And in the Aiome application specifically. These are the gaps we know about in the product itself, as opposed to this website:

• Motion preferences are not yet respected in the app. The website honors prefers-reduced-motion; the application does not yet, so its transitions and animations still play even if you have asked your system to reduce motion. This is a genuine failure against the standard, we know about it, and it is on our list.
• Dialogs do not trap keyboard focus. When a dialog or panel is open, pressing Tab can move focus to content behind it instead of cycling within it. Every dialog can be closed with Escape, but the focus behavior is not yet correct.
• There is no skip-to-content link, so keyboard users pass through the navigation on every screen.
• No automated accessibility testing runs in our build. Our checks are manual today, which means regressions can reach you before we notice them.
• Color contrast and zoom behavior have not been formally measured across the application. We have built to the ratios in the guidelines, but we have not verified every screen against them.

We would rather list these than publish a statement that only mentions marketing-page issues, which would tell you the product had never been checked.

5.What we've built in

• Keyboard navigation throughout, with a visible focus indicator on interactive elements, and Escape closing dialogs, menus and panels.
• Semantic structure — proper headings, landmarks, and lists, so assistive technology can navigate by structure rather than guessing.
• Labelled controls — menus, dialogs, tabs, and pickers carry the roles and names assistive technology needs, rather than being unlabelled boxes.
• Reduced motion support on this website — its animations are disabled when your system requests it. The application does not do this yet; see Section 4.
• Color contrast built to WCAG AA ratios for body text and interface elements. Verified on this website; not yet formally measured across every screen of the application.
• Text resizing — layouts use relative units and reflow without loss of content up to 200% zoom.
• Labelled forms — every input has an associated label, not just placeholder text.
• Color is never the only signal — status and meaning are also conveyed by text or shape.
• Legal documents print cleanly to PDF, with navigation removed and page breaks respected.

6.Tell us about a barrier

If you encounter something in Aiome you cannot use, we want to know. Reports from people actually using assistive technology are worth more to us than any automated scan.

Contact us at aiome.io/contact or [email protected]. It helps if you can tell us the page or feature, what you were trying to do, and what assistive technology and browser you are using — but please report it even if you cannot.

Acknowledgement

Within 2 business days.

Assessment and plan

Within 10 business days we will tell you what we found and when we expect to fix it.

If we cannot fix it quickly

We will tell you honestly, and offer a workaround in the meantime.

7.If something blocks you today

A fix can take time; being unable to do your job cannot wait for it. If an accessibility barrier is stopping you from using Aiome right now, contact us and we will help you get the task done another way — walking through it with you, making the change on your behalf, or providing the information in a format that works for you.

There is no charge for this and you do not need to justify the request.