Accessibility Statement

Email security should not be harder to use for someone who depends on assistive technology. We treat accessibility as part of building the product, not as a separate task at the end.

• ▸We design and build against a published standard rather than a personal opinion of what looks usable.
• ▸We check accessibility when we ship new pages and components, not only during a periodic sweep.
• ▸We tell you what we have tested and what we have not, so you can make your own assessment.
• ▸We treat a reported barrier as a defect and put it in the same queue as any other defect.

We target the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. WCAG is the standard most procurement teams and most accessibility laws point to. Level AA is the level normally asked for.

WCAG is built on four principles. Content should be:

• ▸Perceivable. People can take the information in, whether they see it, hear it, or read it through assistive technology.
• ▸Operable. Everything can be reached and used, including with a keyboard alone.
• ▸Understandable. Language, structure, and behaviour are predictable.
• ▸Robust. Content works with current browsers and assistive technology, and keeps working as they change.

Please read WCAG 2.1 Level AA as our working target. It is the bar we build to. It is not a claim of certified conformance, and we say so plainly in Section 04.

We have completed an accessibility pass across our marketing site, meaning the public pages such as the home page, product pages, pricing, and these legal pages. The pass covered:

• ▸Semantic structure and landmarks. Proper heading order, and real landmark regions for navigation, main content, and footer, so a screen reader user can move around a page instead of reading it end to end.
• ▸Keyboard navigation and visible focus. Interactive elements can be reached and used with a keyboard, and the focused element is visibly marked so you can see where you are.
• ▸Colour contrast. Text and interface colours were reviewed against the WCAG 2.1 Level AA contrast ratios. This matters on a dark interface like ours, where low contrast is easy to introduce by accident.
• ▸Screen reader labelling. Icons, icon-only buttons, and controls carry accessible names, so they are announced as what they do rather than as an unnamed button. Decorative images are hidden from assistive technology.
• ▸Reduced motion. We respect the operating system setting for reduced motion, so animation is cut back for people who find movement uncomfortable or disorienting.

We also keep our written content in plain English for the same reason we keep it short: it is easier for everyone to follow.

These are the gaps we know about today:

• ▸Authenticated dashboard. Some controls, tables, and dialogs in the dashboard may have missing labels, weak contrast, or focus behaviour that does not meet our target. This work is planned and not finished.
• ▸Self-assessment only. Without an independent audit, issues that our own review missed will still be present. Treat our claims as a good faith self-assessment.
• ▸Email content we display. When the product shows you an email, the structure, colours, and images in that email were written by the sender. We cannot control the accessibility of someone else's message.
• ▸Third-party screens. Sign-in screens hosted by Google, Microsoft, or Apple, and payment screens hosted by Stripe, are built and controlled by those providers. Their accessibility is outside our control.
• ▸Documents and downloads. Reports, guides, and other files we publish may not be fully tagged for screen readers. Ask us and we will supply the content in an accessible format.
• ▸Third-party embeds. Where we embed content from another service, that content follows the other service's accessibility, not ours.

• ▸SO Labs Inc. is a Canadian company based in Calgary, Alberta. Accessibility in Canada is set at both the federal and the provincial level, and the rules that apply depend on the organisation and where it operates.
• ▸We take account of the federal Accessible Canada Act and of provincial requirements, including the Accessibility for Ontarians with Disabilities Act (AODA), which many of our Ontario customers are themselves subject to.
• ▸We are not certified or registered under any of these laws, and nothing on this page should be read as a compliance certificate. WCAG 2.1 Level AA is the target we work to, and it is the standard those regimes generally point at.
• ▸If your organisation has a specific accessibility obligation you need us to meet, raise it before you buy so we can tell you honestly whether we meet it today.

If something on our site or in our product blocks you, please tell us. Email support@soemailsecurity.com. Reports from users are how most real accessibility problems get found.

It helps if you can include:

• ▸The page address or the screen in the app where the problem happens.
• ▸What you were trying to do, and what happened instead.
• ▸The assistive technology, browser, and operating system you were using, if you know them.

You do not need to use technical language. Describe it however is easiest for you.

Alternative formats. We will provide information from this site, including our legal pages and product documentation, in an alternative format on request, at no charge. Tell us what format works for you and we will do our best to match it.