Accessibility statement

Version 1.0Effective October 19, 2026

BurTech Solution ("we", "us") wants everyone to be able to use Zamilo, including people who use a screen reader, a keyboard instead of a mouse, magnification, voice control or other assistive technology. This statement covers the Zamilo website at zamilo.io and the Zamilo app at https://app.zamilo.io. It explains the standard we build to, what we do to meet it, what we know still falls short, and how to tell us about a problem.

1. Our commitment

We treat accessibility as part of building Zamilo, not as an extra. We design and test for it as we build, fix the problems we find, and are open about the ones we have not fixed yet. People with disabilities should be able to use Zamilo independently, with the same information and the same results as anyone else.

2. The standard and the laws

Our goal is for the website and the app to conform to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, published by the World Wide Web Consortium (W3C). WCAG 2.2 is the current version of the guidelines and includes everything in the earlier versions, 2.0 and 2.1.

We are based in Ontario, Canada. Ontario's Accessibility for Ontarians with Disabilities Act, 2005 (AODA) and its Integrated Accessibility Standards Regulation (O. Reg. 191/11) set requirements for accessible websites, information and communications, and customer service. That regulation refers to WCAG 2.0 Level AA; building to WCAG 2.2 Level AA meets that and goes further.

Zamilo is used by businesses in many countries, so we also design with other accessibility laws in mind, such as the Accessible Canada Act, the European Accessibility Act and the Americans with Disabilities Act (ADA) in the United States. We do not claim that Zamilo has been certified under any of these laws or standards, and it has not yet been audited by an independent party.

3. What we do

  • Meaningful structure. Pages use semantic HTML: real headings, lists, tables, buttons and form labels, so assistive technology can describe them and move through them. Every form field has a name a screen reader reads out, and every page starts with a link to skip straight to its main content.
  • Keyboard access. Everything is designed to be reached and used with a keyboard. The app's shared inbox also has keyboard shortcuts for common actions.
  • Visible focus. The control that has the keyboard focus always shows a clear outline.
  • Colour contrast in both themes. The app has a light and a dark theme, and the website follows your device's light or dark setting. In both themes, text has a contrast ratio of at least 4.5:1 against its background, and the edges of fields, the focus outline and buttons at least 3:1. For the app, our automated tests recompute every colour pair in both themes, so a colour change that falls short is caught before release.
  • Not colour alone. A link inside a sentence is underlined, so it never relies on colour alone.
  • Any screen size. Layouts are tested at widths from 320 to 1440 pixels, so that pages fit a phone without scrolling sideways. A wide table scrolls inside its own box, and on touch screens the app's buttons and fields grow to a comfortable size.
  • Automated checks. We test pages with axe-core, an automated accessibility checker, against the WCAG 2.2 Level A and AA rules, in both the light and the dark theme.
  • Reduced motion. If your device is set to reduce motion, we turn off animations and smooth scrolling.
  • No flashing content. Nothing on the website or in the app flashes.
  • Works without scripts. The website's menus and forms work even if JavaScript is turned off.

4. Known limitations

These are the problems we know about. We are working on them, and the alternatives below are available now.

  • Dragging. Dashboard tiles can be arranged, and deals moved between stages on the deals board, by dragging. Each has a button alternative that works with a keyboard: the arrow buttons on a dashboard tile, and the Move menu on a deal card. We are reviewing both for keyboard and screen reader users, to make sure they are as easy to use as dragging.
  • Documents from other systems. Zamilo shows documents that come from elsewhere, such as suppliers' PDFs and the emails customers send, as they arrive. We cannot make them accessible if their authors did not. If you need one in another format, ask the person or company who sent it, or ask us for help.
  • PDF documents Zamilo creates. Quotes, packing slips and catalogue PDFs have not yet been checked for accessibility. A quote can also be opened as a web page from the link sent with it, and a price list can be opened as a link or downloaded as a spreadsheet.
  • Other companies' sign-in pages. When you connect Microsoft 365, QuickBooks Online or Shopify, you sign in on Microsoft's, Intuit's or Shopify's own pages. Those pages, and their accessibility, belong to those companies.

5. Feedback and help

If something on the website or in the app is hard to use, or you need information in another format, please tell us:

It helps us to know the page address, what you were trying to do, and the browser and any assistive technology you use, but send whatever you can.

You can ask for any information on our website, including our policies, in an accessible format or with a communication support, such as plain text or large print. We provide it promptly and at no extra cost, in a way that suits your needs.

We aim to respond within five business days.

6. How we keep improving

  • We check new and changed pages with the same tests and checks described above.
  • We fix accessibility problems as part of our normal work, and give priority to anything that stops someone completing a task.
  • We read every piece of accessibility feedback, and use it to decide what to fix next.
  • We review and update this statement when we change something it describes.

7. Last review

This statement was last reviewed on October 19, 2026, the effective date shown at the top of this page.

Questions about this document? Write to [email protected] or use the contact form.