SaaS Infrastructure
Start free
Legal

Accessibility Statement

Last updated: 2026-08-15

Our Commitment

Tessora LLC wants Notavia to be usable by as many people as possible, including people who rely on assistive technologies. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, which is the standard referenced by the EU harmonised standard EN 301 549 and the European Accessibility Act.

Current Status

We do not conform to WCAG 2.1 AA today, and we are not going to imply otherwise while our own testing says we do not. On 15 August 2026 we ran an automated accessibility audit over the public marketing site, and it found failures against Level A and AA. Those results are set out in full below. Three of the five failures the previous run found have been fixed and are gone from this page rather than restated more gently — the ones that remain are the ones that need a change to the site's colour palette and page layout rather than to a stylesheet rule, and they are the larger ones.

One more was closed after that run, on the day the site became public. The home page's Reflow failure is fixed and re-measured, so Reflow no longer fails on any page we measure. That was a targeted re-measurement of one criterion, not a fresh audit: every other number on this page still comes from the 15 August run and has not been re-taken, and the contrast figures in particular predate the fix and were not affected by it.

We have still not commissioned a formal third-party accessibility audit, and no independent audit report of any kind exists. Our own audit does exist — it is what this page publishes. What follows is that testing, run by us on our own tooling with no outside reviewer, with the limits of it stated plainly.

We treat accessibility defects as bugs and prioritise them accordingly. That is a statement about how we triage, not a schedule, and we do not attach a date to it.

The European Accessibility Act

The European Accessibility Act (Directive (EU) 2019/882) sets accessibility requirements for specified products and for services provided to consumers.

Notavia is sold worldwide to businesses only, for business, trade, craft or professional use. Signup and checkout each require the accepting person to confirm that they are at least 18, that the account or purchase is for a professional activity and not for personal, family or household use, and that they have authority to bind the customer named. We do not offer a consumer purchase path, and our Terms of Service do not invite personal purchases.

On those facts, our position is that the Act's consumer-service obligations are not engaged by Notavia as it is sold today. That is a determination made by the Tessora LLC owner role on the evidence above.

Two things we are not going to dress up:

  • No qualified counsel has reviewed this determination. None was available. We are recording an owner decision and accepting the risk that it is wrong, not reporting a legal conclusion that somebody qualified has confirmed. Our other legal documents say the same about counsel, for the same reason.
  • We are not relying on the microenterprise exception. The Act relieves microenterprises that provide services from the service requirements, and we have not published a headcount or turnover figure that would let anyone check whether we qualify. We are not going to claim an exception whose test we have not evidenced. If it applies, it is a second and independent argument; the determination above does not depend on it.

If we ever open a consumer purchase path, this determination stops being true and has to be taken again. And it changes nothing about the target: we aim at WCAG 2.1 AA because it is the right standard for the people using this, not because a directive is pointing at us.

What We Measured, and What Failed

Method. Chromium, headless, driving a production build of the public marketing site, with the axe-core 4.12.1 rule engine injected into each page. Thirty URLs — every URL in the site's own sitemap, plus a 404 page — at a 1280×900 desktop viewport and a 375×812 mobile viewport, in both the default light theme and the dark theme. Reflow was checked at a 320 CSS-pixel viewport and text resize at 200% of the root font size. Keyboard order and focus were walked by hand through the site header and the contact form. The runner is committed alongside its output so that anyone can reproduce these figures rather than take them on trust.

Failures against WCAG 2.1 Level A and AA.

  • Contrast of text (1.4.3, AA) — fails on 29 of the 30 pages. This is the largest problem on the site by a wide margin and it is the one still open. Small muted labels, monospaced metadata and some link text sit under the required 4.5:1. Twelve distinct failing ratios were measured, the worst of them 2.07:1, and the rest running through 2.75, 2.79, 2.81, 2.86, 3.13, 3.57, 3.80, 4.00, 4.12, 4.25 and 4.27:1. There were 274 failing elements at the desktop size and 246 at the mobile size, down from 339 and 382 at the previous run because the legal pages' small labels moved off the worst of those tokens. The dark theme is worse than the light one, not better — 280 failing elements against the light theme's 274, and on the home page 21 against 16. A further 233 elements came back as "needs human review" rather than pass or fail, and nobody has reviewed them. Exactly one of the thirty pages — the 404 page — is free of contrast failures, and it is also the only page free of any Level A or AA failure at all.
  • Resize text (1.4.4, AA) — every page sampled. At 200% root font size the page becomes wider than the window and scrolls horizontally. This is now the only Level AA failure on this page other than contrast.

Fixed since the previous run, and named rather than quietly dropped.

  • Reflow on the home page (1.4.10, AA) — the last page still failing it, fixed on 15 August 2026 and re-measured the same day. It measured 491 pixels against a 320-pixel viewport; it measures 320 now, and does not scroll horizontally at 320, 360, 375, 414, 640, 768, 1024, 1280 or 1440. Two separate causes, both in fixed-width layout rather than in content. The product list on the home page placed a number, a logo, a description and a button in one row whose column widths were fixed in pixels, so the button was pushed past the edge on a narrow screen; the button now moves to its own row below the small breakpoint. The site header put the full wordmark and the access button on one line, which did not fit at 320, and above 768 it added seven navigation links, which did not fit either; the wordmark is now visually hidden below the large breakpoint while remaining available to a screen reader, and the navigation is spaced more tightly until then. The first attempt at the header fix measured clean and looked broken — allowing the wordmark to shrink removed the scrollbar by wrapping the brand onto three lines that overlapped the navigation, which is why the fix is pinned with an explicit no-wrap and was checked by eye at four widths rather than by the measurement alone.
  • Use of colour (1.4.1, A) — 80 instances across all eleven legal pages. Links inside body paragraphs were distinguished from the surrounding text by colour alone. They are underlined now, and the rule reports nothing.
  • Keyboard (2.1.1 and 2.1.3, A) — 12 blocks across 6 pages. Code samples and the plan-comparison table scrolled sideways on a narrow screen and could not be scrolled with a keyboard. Every one of those regions is now focusable and carries a name, and the rule reports nothing.
  • Reflow on the legal pages (1.4.10, AA) — six of the eleven. The cookie policy was the worst at 811 pixels against a 320-pixel viewport; the subprocessor list 740, the transfer addendum 585, this document's siblings 455 and 442, and the acceptable use policy 341. All six measure 320 now. With the home page above, Reflow 1.4.10 no longer fails anywhere we measure it.

One thing that went the other way, and we would rather point at it than let you find it. The count of elements axe reports as "needs human review" rose from 188 to 233. That is a consequence of the reflow fix, not a new defect: table text now sits inside a scroll container, and where the content is wider than the container the engine can no longer resolve with confidence what is behind a partially clipped cell. Those elements are not newly failing — they are newly unmeasurable by this tool, and like the previous 188 they have not been reviewed by a person.

That is the complete list, and we are not going to pad it: a finding the measurement does not support as a Level A or AA failure is reported in the section below instead, not counted here.

Structural defects that are not themselves Level A or AA failures. Recorded because they affect how a page reads under assistive technology, and separated out because calling something a WCAG failure when the standard's own test passes is the same kind of error as claiming conformance we have not measured — it is just pointed the other way.

  • Skipping the header (2.4.1, A) — this one passes. No page carries a skip link, and every page opens with ten header links and a theme toggle before the content. But the standard is satisfied by a skip link or a landmark or a heading at the start of the content, and every page has a heading. We ran the standard's own test explicitly across all thirty pages and it reported zero violations. What is true, and is a real limitation for some people, is that the home page exposes no main landmark, so landmark-aware assistive technology has nothing to jump to on it even though a heading-based route exists. (The 404 page has no main either — but it also has no site header at all, so there is nothing there to skip in the first place.)
  • Heading levels skip a level on all 29 content pages.
  • Content outside landmarks — 41 blocks across two pages, the home page and the 404 page, sit outside any landmark region.
  • The pricing page has no level-one heading.

The last three are reported by our tooling as best-practice findings rather than as WCAG failures, and we are repeating that classification rather than upgrading it.

Practices we do not implement. Nothing in the site's stylesheets responds to a reduced-motion preference — we checked, and there are zero such rules. That is not a Level AA requirement, and we are not presenting it as a failure; it is a thing people reasonably expect that we do not do.

What the same testing confirmed does work. These are measured, not asserted:

  • Every page declares its language.
  • Every image carries an alternative-text attribute.
  • Every form control on the contact form and the early-access form has a programmatic label. The one unlabelled input on each of those pages is an anti-spam honeypot, correctly hidden from assistive technology and not reachable by keyboard.
  • Every button on every page tested has an accessible name.
  • Keyboard order followed the visual order everywhere we walked it, and nothing trapped focus.
  • Links and buttons keep the browser's own focus outline. Form fields replace it with a border-colour change and a ring, which we confirmed on each field of the contact form rather than assuming. We have not measured either against a focus-indicator contrast threshold — that is a WCAG 2.2 criterion and outside what we tested.
  • Every page satisfies the bypass-blocks test described above.
  • Apart from the failures listed above, no other WCAG 2.1 A or AA rule in the engine's ruleset reported a violation on any page tested.

What This Testing Did Not Cover

Automated tooling finds a minority of accessibility problems. Everything below is outside what we tested, and we are not claiming anything about it.

  • The product dashboard. It is a Blazor application behind authentication, and it is not publicly reachable: it is refused at the edge unless the request arrives over our private network. We could not reach it to test it, and nothing on this page describes the dashboard's conformance. This site being public does not change that — the two are served from the same host but only this one answers publicly.
  • The sign-in and account pages, the documentation site, the in-product copies of these legal documents, our email templates, and the hosted unsubscribe and notification-preference pages. None were tested.
  • Assistive technology. No screen reader was used. No test was performed with voice control, switch access or magnification, and no disabled person has tested this service for us. A page can pass every automated rule listed above and still be unusable with a screen reader.

If you see this page cited as evidence that Notavia is accessible, it is being cited wrongly. It is evidence of one automated audit of one marketing website on one day.

Measures We Take

These are practices we follow, not conformance we have measured, and we would rather draw that line ourselves than let a list of bullets imply an audit.

  • We build with semantic HTML and native form controls, so keyboard operation and focus order follow from the markup rather than from something we bolted on.
  • Form fields carry labels, and where a field is required or a control needs a name that its visible text does not give, we mark it up so assistive technology can announce it.
  • Meaningful images carry alternative text.
  • We use a component library for the dashboard and our own stylesheet elsewhere. We intended colour contrast and scalable text to be sufficient. The audit above shows that intention did not hold — contrast fails on almost every page, and text does not scale to 200% without horizontal scrolling. We have left this bullet here rather than deleting it, because the gap between what we intended and what we shipped is the point.

What we do not do, and will not claim. We run no automated accessibility check in our build, and nothing fails a release because of an accessibility defect. The audit described above was run once, by hand, outside the build; it is not wired into anything, no future change is checked against it, and a regression would not be caught. We have no written accessibility step in our design or code review — our engineering standards do not mention accessibility at all, and we would rather say that than describe a review gate we do not operate. Contrast and scale are design intent rather than an enforced rule: nothing in the product measures a contrast ratio or refuses a combination that fails one.

Scope and Proportionality

We are a small provider. Where a specific accessibility requirement would impose a disproportionate burden relative to our size and resources, we will document the limitation here and offer an accessible alternative on request. As the service and the organisation grow, we will commission an independent audit and expand conformance accordingly.

We are not currently claiming that exemption for anything, and we could not evidence it if we did. A disproportionate-burden argument is a size-and-resources argument, and we have published no headcount, turnover or balance-sheet figure that would let anyone test one — the same reason we decline the microenterprise exception above. So nothing on this page is excused on burden grounds: every failure listed above is a defect we own, not a requirement we have exempted ourselves from. If we ever do rely on this paragraph, we will name the specific requirement, say what the alternative is, and expect to be asked for the figures.

Feedback and Help

If you encounter an accessibility barrier in Notavia, or need information in an alternative format, please contact:

We do not operate a telephone support line, so email is the only channel; if you need a different one, say so in your message and we will arrange it.

Tell us the page or feature, what went wrong, and the assistive technology you were using, and we will work with you to provide the information or function you need.

Who handles it. Accessibility reports go to the same mailbox as everything else and are triaged by the Tessora LLC owner role, which also owns the fix. There is no separate accessibility team, no specialist reviewer, and no rota — one role receives the report, decides what to do about it, and does it. We are describing the arrangement we actually have rather than an escalation path drawn for the page.

What we will do while a barrier stands. If a defect on this site stops you completing something, tell us what you were trying to do and we will give you the information, or complete the step for you, by email. That is a commitment one mailbox can honour, which is why it is the one we are making. We are not committing to a fix date for any individual defect, and the failures listed above are published as known limitations rather than as a work plan.

We do not publish an acknowledgement deadline. We used to publish a five-business-day figure here and we have removed it, because it was not staffed and we could not point at anything that made it true. Our Security & Trust page says the same about vulnerability reports, for the same reason: a small team cannot honour a clock it has not staffed, and we would rather make no promise than one we would miss. The mailbox above is read.