Accessibility at tchop

Our approach

Accessibility in a communication platform is not a checkbox, it is shared responsibility. The platform provides the technical foundation: structure, labelling fields, adaptable typography. What gets published on top of it is in the hands of the editorial teams and organisations that run tchop. This page describes both sides honestly, without conformance promises.

Unlike some vendors, we do not claim full conformance with BITV 2.0 or EN 301 549. Our native apps have been independently audited twice against these standards. We work through the findings by priority: whatever helps screen-reader users most comes first. On request, we share the current status per criterion and per platform.

The standards we work against

Our reference points are WCAG 2.1 and 2.2, the European standard EN 301 549 and the German BITV 2.0. For public-sector organisations in Germany, BITV is binding, and external agencies test its requirements in clearly defined steps. Exactly such audits are what our apps have been through.

What the platform provides today

• Alt-text fields for images across all content formats. Whether they get filled is an editorial decision.

• Fully configurable typography and colours. Important: this puts contrast in your hands. A low-contrast brand palette creates barriers that no platform feature can prevent.

• Menu slots for an accessibility statement and a feedback route. The content comes from you, just like imprint and privacy policy. Keeping those links reachable is the platform's job.

What we are building right now

In build now: text resizing to 200 percent per WCAG 2.2 (success criteria 1.4.4 and 1.4.12), on iOS, Android and web. We use each system's native mechanism: Dynamic Type on iOS, system font scaling on Android, rem-based typography on the web. An improvement iteration for the web app runs in parallel.

What we deliberately do not do

• No accessibility overlay. Overlays mask barriers instead of fixing them; disability organisations such as the European Disability Forum reject them. So do we.

• No font-size slider in the web app. There, the right place for text size is the browser and the system settings. The mobile apps do include a text-size control for comfortable reading; the accessibility mechanism remains system-level scaling.

Where the limits are

Some structural topics are not supported today: dark mode (which conflicts in most cases with UI customisation) and high-contrast on iOS, landscape orientation. iOS and Android also differ on individual criteria, in both directions. If you are preparing an RFP with accessibility requirements, you get the honest per-criterion status from us instead of a blanket claim.

What editorial teams contribute

Even the most accessible platform fails when content builds barriers. Three rules with outsized impact: write alt text for images, never bake text into graphics, provide transcripts for audio content. No platform can take these tasks over; they belong in the editorial routine.

Questions?

For RFPs, audits or detail questions: talk to us, and we will answer per platform and per criterion, with the actual status.

* * *