DRAFT — NOT IN FORCE. This document is an unreviewed placeholder. It has not been reviewed by counsel and does not bind anyone.

Accessibility Statement

Effective date: [EFFECTIVE DATE] Last updated: [EFFECTIVE DATE]

1. Our commitment

[PRODUCT NAME] is an ordering tool that people use to do their jobs. Someone placing a weekly coffee order should be able to finish that order whatever device they are on, whether they use a mouse, a keyboard, a screen reader, a magnifier, or a phone held in one hand in a noisy back-of-house.

We treat accessibility as part of building the product, not as a later clean-up pass. We also treat it plainly: this page describes what we have actually done and what we have not yet looked at. Where we do not know something, we say so rather than guessing.

2. The standard we aim for, and where we actually stand

We aim for WCAG 2.2 Level AA.

We have not been independently audited, and we do not claim conformance. Everything below is our own assessment of our own code. Specifically:

  • No third party has audited [PRODUCT NAME].
  • We hold no accessibility certification and have not published a VPAT or Accessibility Conformance Report.
  • We have not tested the product with screen readers, switch access, voice control, or any other assistive technology, and we make no claim about how it behaves with them.
  • We run no automated accessibility checks in our build.

So: an aim, plus deliberate work toward it, plus real gaps. Not a conformance claim.

3. What we have deliberately built

These are things we have built on purpose. They describe what the product is designed to do for you, as it stands today; section 4 lists what has not been checked.

Keyboard use and focus. You can reach and operate the product from a keyboard, and the control that has keyboard focus is clearly outlined in a color that stays visible against whatever is behind it. The outline is not drawn for mouse clicks, so it does not clutter the screen for pointer users. Only things you can act on are in the tab order.

Page changes are built to be announced (untested with a screen reader — see section 2). When you move between screens, the browser tab title changes to name the screen and your distributor, and keyboard focus moves to the top of the new screen, so assistive technology has something to announce and keyboard users start in the right place. This applies on the sign-in screens too, not only inside the app.

Loading, error, and empty states are built to be spoken, not just shown. Screens that fetch data use one shared pattern, so a loading indicator, an error, or an empty result is marked up to be read out, not only displayed. Controls that need a name beyond their visible text carry one, and controls governed by a heading are linked to it.

We chose where NOT to announce, too. Surfaces that save on every tap and keystroke — the cart, the special-instructions note, the Favorites list — show a quiet "Saved" rather than announcing every change, because an announcement per keystroke is unusable.

Forms are labeled and typed. Fields carry a real label rather than placeholder text, and declare their purpose so browsers and password managers can fill them and a phone raises the right keyboard for an email address, a number, or a phone number.

Contrast is computed, not eyeballed. Text colors in our own palette are chosen by measured contrast against their background, in both the light and dark themes, rather than by taste. A distributor's brand colors are adjusted for legibility against the surface they are drawn on, so a very pale or very dark brand color does not disappear into the page.

Mobile-first, and touch targets sized for a thumb. Most people using this are on a phone. On narrow screens the navigation becomes a drawer, primary actions go full width and stack with the main action nearest the thumb, and the controls you tap most — such as quantity buttons — are sized for a finger rather than a mouse pointer.

Text. The typeface is chosen for interface legibility, with unambiguous characters. Figures that change in place — money, quantities, counts — use fixed-width numerals so they do not jitter. On narrow screens text is shortened with an ellipsis rather than hidden.

Light and dark are both real. Both themes are fully defined and both are checked for contrast. The page declares its language as English.

Motion. The loading animation is disabled when your device asks for reduced motion.

Printing. The picking slip prints black on white, whatever the distributor's colors or your display theme.

4. Known limitations and things we have not assessed

We would rather you know these before you hit one.

  1. No audit and no assistive-technology testing. As section 2 says, nobody has driven this product with a screen reader and reported back. Everything in section 3 is reasoning about markup, not observed behavior in NVDA, JAWS, VoiceOver, or TalkBack.
  2. No automated accessibility checks run in our build. Regressions in this area are currently caught by review, or not at all.
  3. Our own internal operator console — which distributors and their customers never use — has had less attention than the customer screens. It is a dense, desktop-first, table-heavy tool for our own staff. It does not affect you as a user of a distributor's site; it is listed for completeness.
  4. A distributor's uploaded logo is not checked for accessibility. We validate that an uploaded file really is an image of an allowed type, and we sanity-check the theme colors — but we do not and cannot check whether a logo has enough contrast against the app bar, whether text baked into the logo image is legible, or whether it is readable at small sizes. See section 5.
  5. The theme contrast check is advisory, not a gate. When a distributor saves brand colors, the server returns contrast warnings and the settings screen shows them — but the save succeeds either way. We do not overrule a business about its own brand colors. That means a live site can carry colors we warned about. The check also only covers the two brand colors against our surfaces; it does not evaluate the whole rendered page.
  6. There is no "skip to content" link. Keyboard users currently tab through the app bar and navigation on each page. The route focus move in section 3 reduces but does not remove this.
  7. Not assessed: behavior at 400% zoom and at 320px reflow; Windows High Contrast / forced-colors mode; the complex framework components we use for data tables, dialogs, menus and file upload, beyond their default behavior; the printed picking slip as an accessible document; and how live order updates pushed to an open screen are (or are not) announced.
  8. Reduced motion is honored in one place only — the pre-load skeleton. We have not audited the framework's own transitions and overlays against that preference.
  9. English only. There is no translated or simplified-language version.
  10. No first formal audit is scheduled yet. [FACT NEEDED: whether and when a formal WCAG 2.2 AA audit or assistive-technology test pass is planned]

5. How a distributor's branding affects accessibility

[PRODUCT NAME] is white-label. The logo, the wording, and the accent colors on the screen belong to whichever distributor you are ordering from, not to us. That affects what we can promise.

What we check. Brand colors must be valid hex values or we reject the save outright. Valid colors are then checked for contrast and the distributor is shown a plain-English warning for any that may be hard to read, per theme. Separately, at render time, we hold the borrowed color to a legibility floor against the surface it is actually drawn on, adjusting lightness only, so a very pale or very dark brand color does not disappear into the page. Our own palette — status colors, text, backgrounds, and their foreground inks — is fixed by us and is not affected by branding.

What we do not check. The uploaded logo and site icon (see "Known limitations" above), any text a distributor writes into their own notices and footer, and whether a distributor acts on the contrast warnings we show them.

Who to talk to. If the barrier is the distributor's own content — their logo, their notice text, their colors — the fastest fix usually comes from them. If it is the product itself, that is ours. Tell us either way; we would rather sort out which it is than have you chase the wrong party.

6. Reporting a barrier

If any part of [PRODUCT NAME] stops you doing something, please tell us. You do not need to know why it is broken or use any particular words.

Email [SUPPORT EMAIL], and if you can, include:

  • the web address of the page;
  • what you were trying to do;
  • what happened instead;
  • the device, browser, and any assistive technology you were using.

What to expect. We will acknowledge your report and tell you what we find and whether we can fix it. [FACT NEEDED: target acknowledgment and response time for accessibility reports]

We cannot promise every barrier is fixable quickly, and we will not pretend otherwise. If a fix will take time, we will say so and, where we can, describe another way to get the task done.

If you need to place an order right now and cannot, contact your distributor directly — they may be able to take the order another way. [FACT NEEDED: whether an alternative ordering channel (phone or email) is guaranteed by every distributor, or is per-distributor]

This statement is our own self-assessment as of [EFFECTIVE DATE]. We will update it as the product changes and as the gaps in section 4 are closed. Reports from real users are the main thing that moves this list.

7. How to contact us

Accessibility reports and questions: [SUPPORT EMAIL]

Formal or legal notices: [NOTICE EMAIL]

By post:

[LEGAL ENTITY NAME] [PRINCIPAL ADDRESS]