Accessibility statement.

1. Commitment

SweetNote is committed to making the platform usable by people with the widest range of abilities. The reveal page (the surface every recipient encounters) is held to the most demanding standard because we do not control the device, network, or assistive technology a recipient is using. The brand-facing dashboard is held to the same target with a longer remediation horizon as the product matures.

Conformance target: Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. Because the U.S. Section 508 standard incorporates WCAG 2.0 Level AA by reference (and our 2.1 AA target is a superset of it), our work also informs Section 508–relevant evaluations in federal-procurement contexts; SweetNote has not completed a separate Section 508 assessment or published a Voluntary Product Accessibility Template (VPAT) / Accessibility Conformance Report at launch. We do not currently claim full Level AAA conformance.

Honest framing. WCAG 2.1 AA is the target we build and design against; it is not a representation that every surface currently passes every Level AA success criterion. No formal third-party WCAG audit or Voluntary Product Accessibility Template (VPAT) has been completed at launch. Known issues are disclosed openly in Section 4. We address reported issues in good faith and update this statement as each one is fixed. A formal third-party audit and VPAT is on the platform roadmap; we will publish the VPAT here when complete.

2. Recipient-facing reveal page

The reveal page is the most-used surface across the platform and our highest-priority accessibility target.

• Keyboard navigation: every interactive element (poster play button, consent-ribbon Count me in / Not this time buttons, immersive-player controls, three-tap reactions, brand call-to-action) is reachable and operable via keyboard alone, with visible focus indicators.
• Screen-reader support: semantic HTML, descriptive labels, and ARIA where landmark or live-region semantics are needed. Tested with VoiceOver (iOS / macOS) and NVDA (Windows).
• Color contrast: minimum 4.5:1 for body text, 3:1 for large text and meaningful UI elements. Tenant-supplied brand colors are checked at onboarding; combinations that fail the floor are flagged before the reveal goes live.
• Reduced-motion respect: every CSS animation honors prefers-reduced-motion; recipients who set the OS preference see static layouts.
• Captions for prerecorded media (WCAG 2.1 SC 1.2.2). The platform automatically generates a captions track for each Customer-supplied video at upload, rendered through the reveal-page video player’s native captions track, recipient-toggleable via the player controls. Customer reviews the generated transcript before launch and remains responsible, under the Acceptable Use Policy, for the accuracy of the captions as published, including any edits. Customer may replace the generated track with its own WebVTT (.vtt) file.
• Mobile-first: touch targets meet at least the 24×24 px minimum (WCAG 2.2 SC 2.5.8); the play control is never smaller than 44 px and the consent-ribbon buttons never smaller than 36 px; the reveal page is designed primarily for phone use.

3. Brand-facing dashboard

The dashboard is used by trained operators inside Customer's organization. Conformance target is the same WCAG 2.1 AA, with a longer remediation horizon for complex visualizations.

• Keyboard navigation: primary navigation, filters, and KPI cards are keyboard-operable. Some custom chart components remain in remediation (see Section 4).
• Screen-reader support: data tables are properly marked up; chart visualizations have text alternatives summarizing the same data. Decorative chart elements use aria-hidden.
• Color contrast: the dashboard ships with a single approved palette that meets contrast minimums by default; Customer cannot override the dashboard chrome to a non-conformant palette.
• Print and PDF export: dashboard reports export to PDF in a layout that maintains semantic structure for downstream screen-reader use.

4. Known issues and remediation timeline

SweetNote operates under a "disclose openly" policy on accessibility. The current known issues:

• Custom chart components: some interactive chart elements (drill-down hover states, sparklines) do not yet expose a complete keyboard-operable interaction model. Remediation on the accessibility roadmap.
• Downloadable transcript: captions auto-generate at upload and Customer-supplied VTT files are supported; a separately downloadable full-text transcript is on the accessibility roadmap.
• High-contrast mode: the dashboard renders correctly in OS-level high-contrast modes; a dedicated high-contrast theme is on the accessibility roadmap.
• Disabled sample-size slider on the pricing calculator: before a methodology is selected, the recipient-count slider renders in a dimmed inactive state whose label sits below the 4.5:1 body-text ratio. This is retained deliberately. WCAG 2.1 SC 1.4.3 exempts text that is part of an inactive user interface component, and dimming a disabled control is the conventional signal that it is not yet operable. An automated scanner will flag it; we are recording here that it is an exemption rather than an oversight. The control meets the ratio as soon as it becomes active.

5. Testing approach

Accessibility is checked at three layers:

1. Automated: axe-core (or equivalent) is run against the reveal-page and dashboard surfaces during development; flagged failures are triaged and tracked in the development backlog.
2. Manual: periodic review with VoiceOver, NVDA, and keyboard-only navigation, conducted by the founder before each material reveal-page release, and otherwise as the surface changes.
3. External audit: on the post-launch roadmap, scheduled after the first cohort of paid customer studies. Reports shareable under NDA on request.

Latest assessment. Automated sweep conducted 2026-07-31 using axe-core 4.12.1 against WCAG 2.0 and 2.1 Level A and AA rules, covering the reveal page, all public marketing pages, and every document in this legal cluster. Every issue it surfaced was fixed in the same pass, across the reveal page, all public marketing pages and every document in this legal cluster; the one deliberately-retained exemption is recorded in Section 4. A structural keyboard and assistive-technology inspection of the reveal page was carried out in the same pass and is recorded here because it is the surface every recipient touches: focus order verified end to end, an accessible name confirmed present on every focusable element, no focusable element left inside an aria-hidden region, landmark and heading hierarchy checked, and the three-tap reaction exercised to confirm that selecting one announces a spoken confirmation through a polite live region and disables the remaining choices. A screen-reader listening pass was also carried out on the current reveal build, after the June 2026 redesign, confirming the page reads sensibly aloud including the native video control set. The current known-issue queue is summarized in Section 4 above and tracked in the development backlog. The next assessment runs before the next material reveal-page release. We deliberately do not commit to a fixed calendar cadence: the recipient-facing reveal is a nine-element page, and a promised quarterly audit we did not keep would be worth less than an honest account of when we actually look.

6. Reporting an issue

If you encounter an accessibility barrier on any SweetNote surface, the marketing site, a reveal page, the dashboard, please report it directly to accessibility@thesweetnote.com. Include:

• The URL or surface where the issue occurred.
• The assistive technology in use (if applicable: NVDA, VoiceOver, JAWS, etc.).
• What you expected to happen, and what happened instead.

We respond within five business days with an acknowledgement and remediation plan.

7. Changes to this statement

This statement is updated when conformance changes or a new issue is identified, and reviewed at least annually. The canonical version is published at thesweetnote.com/legal/accessibility.