Built to be used by every employee, including those using a screen reader
We work to WCAG 2.2 AA. Our apps have been audited twice by the accessibility agency d-SIRE against BITV 2.0 and EN 301 549, and they run every day at organisations like AOK. This page says what works today, what does not, and what we are building next.
One standard, named
Accessibility only means something when you name the yardstick. Ours is WCAG 2.2 AA.
For public-sector customers, two further frameworks apply: BITV 2.0, the German implementation of the EU accessibility directive, and EN 301 549, the European standard for ICT products. Our native apps have been tested against both.
Tested by an external agency, not by us
Most vendors publish a self-assessment. Our apps are battle-tested in the field and audited from outside it.
Health insurer AOK runs tchop as its employee app across several regional organisations. For that rollout, the accessibility agency d-SIRE audited our native apps twice against BITV 2.0 and EN 301 549:
94 test steps per audit, of which 35 apply to a native mobile app
iOS and Android tested separately, with VoiceOver and TalkBack
Testing by accessibility specialists, including people who use assistive technology daily
Every criterion rated on its own, with the screen and the element named
The audits found real problems. We fixed the labelling, semantics and form issues that block screen-reader users, and we deferred structural items that need a redesign rather than a patch.
Conformance summary: we share a per-criterion conformance table on request, covering the native apps and the web app against WCAG 2.2 AA. Ask your contact or write to accessibility@tchop.io.
What works today
Screen readers
The apps and the web app work with VoiceOver, TalkBack and NVDA. Labels, roles and states are set on interactive elements.
Alt text
Every image and media card takes an alternative text, set by the person publishing the content.
Keyboard operation
The web app is operable by keyboard with a visible focus indicator.
Text size
Set the font size on your device and the app follows it, up to 200 percent, on iOS, Android and the web app. Tested against WCAG 2.2 success criteria 1.4.4 and 1.4.12.
Contrast
Interface contrast meets WCAG 1.4.3. Because every tchop app carries the customer’s own colours, we check the contrast of a customer palette during setup.
Language and structure
Headings, lists and paragraphs are marked up so screen-reader users can move through an article instead of hearing one block of text.
What we have not solved
We would rather you find this here than in a test. These are the open items from our last audit, in plain terms.
Hardware keyboards on phones and tablets. Connect a physical keyboard to a phone and a few dialogs and menu layers cannot be reached or closed by keyboard alone. Touch and screen-reader gestures work. This is our most-cited open finding.
Contrast on small functional details. Interface contrast passes the 3:1 minimum, but the audits measured single functional elements below it, for example timestamps on a post and placeholder text inside input fields. Since every app carries the customer’s own palette, we check these during setup and fix them per app.
The dark mode on mobile apps does not work properly in some UI and brand cases, high-contrast system settings are only partly reflected.
The mobile apps run in portrait orientation. Landscape is not supported except in a few card types.
Content embedded from external sources, for example a social feed or a supplied web page, keeps the accessibility of its source. We cannot correct it inside our app.
We build the platform. You write the content.
An accessible app can still carry inaccessible content. Both parts have to be right.
What tchop provides
An app that assistive technology can read, alternative-text fields on every image, semantic structure, keyboard operation, contrast checks during setup, and menu slots for your accessibility statement and your barrier-reporting route.
What your team provides
Alternative texts that describe the image, clear headings, plain language, subtitles for video, transcripts for audio, and no text baked into images.
What we do together
We advise your editors during onboarding, and we re-test after each release.
Three questions we get asked
Can you guarantee a fully accessible app?
No, and neither can anyone else. Accessibility depends on your configuration, your structure and your content. Audits are run on a representative app with typical content. We can tell you exactly which criteria we meet, on which platform, and what we are working on.
Should we add an accessibility overlay?
We advise against it. Overlays claim to repair a platform from the outside and interfere with the assistive technology people already use. The European Disability Forum and the International Association of Accessibility Professionals have published a joint statement on this, and the European Commission refers to it. We would rather fix the app.
Do you offer in-app font-size buttons or a built-in screen reader?
No. People who rely on assistive technology have already configured it across their device. Our job is to work with those settings, not to add a second set of controls that only works inside one app.
Found a barrier? Tell us.
If something in a tchop app blocks you, report it. Customers can reach their contact directly. Everyone else can write to accessibility@tchop.io.
Every app also carries a menu slot for the operator’s own accessibility statement and barrier-reporting route, which public bodies need under BITV.
See it with your own content
The fastest way to judge accessibility is to open an app with a screen reader and try it. We will set up a test app with your content and walk through it with you.
