dynodoc

LEGAL

Accessibility statement

Dynodoc's accessibility goal (WCAG 2.2 level AA), what is done and tested, the known limitations, and how to tell us about a barrier.

Draft revised 12 October 2026 · Not yet effective

A transparent draft, pending operator details

The legal operator, public contact details, hosting jurisdiction and governing law have not yet been confirmed. This page describes how the service currently works and the terms proposed for it. It must be completed and reviewed before it is adopted for customer data or a public launch.

Our goal

Dynodoc aims for its website and workspace to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. That is a goal, not a claim of conformance: the product has not had a full manual audit by an independent accessibility specialist, and this statement does not assert that every page or feature meets the standard.

What we do

  • Pages use one main landmark, one top-level heading in order, and a skip link to the content.
  • The public site is built to be used with a keyboard, with a visible focus ring and targets of at least 24 pixels. Text colours are chosen for at least 4.5 to 1 contrast in the light and the dark theme.
  • Layouts reflow down to a 390 pixel wide screen without horizontal scrolling. Text can be enlarged with the browser, and legal pages print cleanly.
  • Content is in the page without JavaScript. Motion respects the reduced-motion setting, and moving content that lasts more than five seconds has a pause control.
  • Colour is not the only signal: change lines carry plus and minus marks, and decorative artwork is hidden from assistive technology.

How it is tested

The automated test suite runs the axe-core engine against the public pages, including the sign-in page and the legal and trust pages, with the WCAG 2 A and AA, WCAG 2.1 A and AA and WCAG 2.2 AA rule sets plus best-practice rules, and requires zero violations. A set of signed-in workspace and editor views are checked the same way in the authenticated test stack.

Automated tools find only part of the possible barriers. Testing with a screen reader, speech input and native input-method editors on real devices, and by people who use them, has not been completed and is still needed.

Known limitations

  • Editors. The rich-text and spreadsheet editors are complex custom components. They have labelled controls and keyboard navigation but are not guaranteed to work with every screen reader, and they are not meant to match the accessibility of Word, Excel or Google Docs.
  • Documents you create. Basic checks for heading order, image descriptions and table headers help authors, but exported files are not certified accessible.
  • Add-ins. The Word, Excel, PowerPoint, Docs, Sheets and Slides add-ins run in panes and sidebars provided by Microsoft and Google, whose own accessibility behaviour applies. They have not been tested with assistive technology in installed editors.
  • Comparison views. Change views are dense. Changes carry plus and minus marks as well as colour, but reading them with a screen reader can be slow.
  • User content. Images and files that people add to documents may lack text alternatives.

Feedback and requests

If you meet a barrier or need information in another form, please tell us what you were trying to do, the page address and the assistive technology you use. We will try to fix it or offer an alternative; no response time is promised by this draft.

Accessibility contact
Awaiting confirmation.
Meanwhile
Use the support page or contact the administrator who invited you.
Statement prepared
12 October 2026