Accessibility

Accessibility statement

Prepared and last updated: 25 August 2026

Tenthwise aims to make personal-finance learning and organization usable by people with diverse access needs, devices and assistive technologies.

Current status: not yet assessed for conformance. WCAG 2.2 Level AA is the production target, not a claim that the current preview fully conforms. An expert audit, user testing, remediation record, operator identity and monitored accessibility contact are required before commercial launch. Counsel must also confirm how the European Accessibility Act and Italian Legislative Decree 82/2022 apply to the final service.

1. Our commitment

The target is Web Content Accessibility Guidelines (WCAG) 2.2 Level AA across the public site, account and core workspace. Where the European Accessibility Act applies, the final service will also need to satisfy the relevant functional requirements and applicable harmonized standards or technical specifications; WCAG alone may not cover every legal duty.

Accessibility is treated as an ongoing product requirement, including procurement, design, code review, content, support and release testing. No user should have to disclose a disability to request information in an accessible format.

2. Conformance status

Not evaluated. The production-preview interface has not completed the audit needed to classify it as conformant, partially conformant or non-conformant with WCAG 2.2 AA. We will publish the tested scope, browser/assistive-technology combinations, evaluator, date and unresolved findings after that assessment.

This statement does not rely on a blanket exemption or disproportionate-burden claim. Any such legal assessment would need to be specific, documented, periodically reviewed and accompanied by the most accessible alternative reasonably available.

3. Measures already designed into the preview

  • A skip link and semantic page regions.
  • Keyboard-operable native controls and visible focus styling.
  • Text labels or accessible names for interactive controls.
  • Responsive layouts and support for text resizing without a fixed desktop-only canvas.
  • A reduced-motion mode that respects the device preference.
  • Information conveyed with text in addition to color where implemented.
  • Workspace export and plain-language explanations of calculations and limits.

These design choices are useful evidence, but they do not prove end-to-end conformance.

4. Known and suspected limitations

The following areas require particular audit and may present barriers in the current preview:

  • Charts, derived financial summaries and drag/reorder interactions may need richer text equivalents and tested keyboard alternatives.
  • Single-page-app focus may not always move or announce view, modal and validation changes as expected by screen-reader users.
  • Status messages, errors and sync states need testing across screen readers and voice-control tools.
  • Color contrast, zoom/reflow, touch-target size and high-contrast/forced-colors behavior have not completed systematic verification.
  • Localized content, right-to-left layouts and third-party authentication or payment screens may have gaps outside Tenthwise’s direct code.
  • Downloaded JSON/CSV data is machine-readable but may not meet every user’s preferred accessible format.

If a feature is inaccessible, the operator should provide the same information or outcome through an accessible route without surcharge or avoidable delay.

5. Assessment and remediation plan

Before paid launch, testing should cover automated checks plus manual keyboard-only use, 200% and 400% zoom/reflow, text spacing, contrast, reduced motion, touch, screen magnification, voice input and representative screen readers on current browser/platform combinations. Critical journeys include onboarding, local entry, import/export, sign-in, sync, sharing, consent, checkout, cancellation/withdrawal and account deletion.

Issues will be prioritized by user impact and legal severity, assigned an owner and retested before closure. The launch team must set and publish the initial audit date and regular review cadence. Accessibility regressions should block releases that make a core journey unusable.

6. Feedback and accessible alternatives

When reporting a barrier, it helps to include the page or feature, what you were trying to do, the problem, and—only if you wish—your browser, operating system and assistive technology. Do not include financial workspace data, passwords or sensitive documents.

Accessibility email/form, telephone or relay-compatible route, operator name and postal address: pending before commercial launch. The final channel will acknowledge requests and provide a substantive response within a published, reasonable timeframe.

Requests can include an accessible copy of information, help completing a service action, or another communication format. The operator will not charge for a reasonable accessible alternative required to provide equal access.

7. Escalation and legal routes

Please contact the operator first once the monitored route is published. If the response is missing or unsatisfactory, legal complaint or enforcement routes may be available depending on the service, provider size, user and applicable law. The final statement must identify the competent Italian authority and procedure after counsel confirms the service’s exact coverage; this preview does not guess that allocation.

Useful official background: WCAG 2.2 and Agenzia per l’Italia Digitale accessibility guidance. Nothing in this statement limits a right or remedy available under applicable law.