The short version
We want The Nut Tracker and this website to work for everyone who is old enough to use them. We aim for WCAG 2.2 level AA, we have done a lot of the work, and we have not finished. The gaps we know about are listed below. If something gets in your way, email support@thenuttracker.com and we will answer within 48 hours.
1. Our commitment
Kallos Labs LLC aims for thenuttracker.com to conform to the Web Content Accessibility Guidelines (WCAG) 2.2, level AA, and applies the same standard, as far as it translates, to The Nut Tracker app on iOS and Android.
Accessibility is part of how the app and the site are designed and built, not a pass at the end. It is checked when things change, not just once.
2. The website
Work done on thenuttracker.com so far:
- The page language is declared, and each page uses a real heading structure, so screen readers can navigate by heading. The legal pages, this one included, have a table of contents built from those headings.
- Interactive elements show a visible focus indicator when you use a keyboard.
- Animation is reduced when your device asks for reduced motion.
- Nothing on the site depends on analytics, so rejecting cookies never breaks a page.
- The cookie banner offers Accept and Reject with equal weight. [CONFIRM] that the banner is fully usable by keyboard and screen reader and does not trap focus, once it is built.
[CONFIRM] Dima to run an audit of the live site against WCAG 2.2 AA (at least an automated check plus a keyboard and screen reader pass on the home page, support, a legal page and an article) before this statement goes live, and to record the result in section 5.
3. The app
Work done on The Nut Tracker app so far:
- Screen readers. Controls on the core screens (Home, logging, History and Stats) have a role and a label for VoiceOver on iOS and TalkBack on Android. Charts and streak strips are read as one spoken summary rather than a row of unlabelled shapes. Badges announce their name, tier and whether you hold them, because the visual difference between held and not held is not something a screen reader can see.
- Text size. The app follows your device’s text size setting (Dynamic Type on iOS, font scaling on Android). Body text scales freely and wraps rather than clipping. The single large number on a screen is capped at 1.6 times its size so the layout holds, and at the largest sizes layouts switch to fewer columns.
- Touch targets. Every control has a target of at least 44 by 44 points, extended with extra hit area where the artwork is smaller.
- Colour and contrast. Text and graphic colour pairs have been checked for contrast on every background in light and dark mode, and the failures found were fixed in the design tokens. Badge tiers are never told apart by colour alone: the tier name and the percentage are always printed.
- Motion. When Reduce Motion is on, animations drop to a simple fade or to nothing. No animation blocks input for more than 1.2 seconds.
- Sound and haptics. Sound is off by default. Celebrations use a haptic and an on screen message, so nothing relies on sound alone.
- Dark mode is fully supported.
4. Known limitations
These are the gaps we know about today, and we are working on them:
- Screen reader pass on a real device. Labels and roles are in place on the core screens, but a full VoiceOver and TalkBack pass on a physical device, on every screen, has not been completed yet. Some secondary screens may still have unlabelled or awkwardly ordered elements.
- One control clips at the largest text sizes. A small pill style control used on some screens has a fixed height and can cut off its label at the very largest accessibility text sizes.
- Mascot animations are decorative. They carry no information you would miss, but their movement is not described.
- Content we do not control. App Store and Google Play pages, the store purchase and subscription screens, and websites we link to are run by others and follow their own accessibility standards.
[CONFIRM] Dima to update this list after the device screen reader pass and before the app’s public release.
5. How we check
This statement is based on a self assessment by the team, using the design system’s contrast records, automated tests in the app that keep contrast and animation timings in bounds, and manual checks. It has not been audited by an independent third party.
[CONFIRM] whether an independent audit is planned, and whether any accessibility law (for example the European Accessibility Act) applies to Kallos Labs LLC at its current size.
6. Report a barrier
If you cannot use part of the app or the website, or something is harder than it should be, please tell us:
It helps to include what you were trying to do, which page or screen you were on, your device and operating system, and any assistive technology you use (for example VoiceOver, TalkBack, a screen magnifier, switch control or voice control). Please do not send us your log history.
We aim to answer within 48 hours. If we cannot fix the problem quickly, we will tell you when we expect to, and help you get what you need in another way in the meantime where we can.
7. Last review
This statement was last reviewed on 24 September 2026. We review it when the app or the website changes in a way that affects accessibility, and at least once a year.