Trust at Amicus
Accessibility
We would rather tell you exactly what works and what does not than claim a level of conformance we have not tested. Everything below describes the product as it actually ships today, including the parts that are not good enough yet.
Where we stand
Amicus and Rooster target WCAG 2.1 Level AA as the standard we design to. We have not completed a formal audit, and we have not had the apps reviewed by an independent accessibility tester or by people who use screen readers daily. So we are not claiming conformance. We are claiming the specific, verified things listed here.
If something in either app blocks you, that is a bug and we want to hear about it. Email support@amicusapp.us with the screen and what happened. Accessibility reports go to the front of the queue ahead of feature work, and you will get a human reply rather than a ticket number.
Colour and contrast
Rooster's colour tokens were measured rather than eyeballed. Every text-on-background pair in the shipping theme — body copy, headings, accent text, button labels, chip labels, the small print used for safety and legal notices, and both active and inactive navigation states — meets or exceeds the 4.5:1 ratio WCAG requires for normal-size text, in both the light and dark themes. The lowest pair measures 5.24:1; most are well above 10:1.
We deliberately hold the small 12px text used for disclaimers to the same 4.5:1 bar as body text, rather than the relaxed large-text threshold, because that is the copy carrying safety information.
Where a control's state is shown by colour, the state is also exposed to assistive technology directly, and in the daily-step and habit lists the button's own label changes (“Do” to “Done”) alongside a check mark, so the change does not depend on seeing the colour.
The weekly plan is the place this mattered most. Each day row used a coloured bar for the kind of day, a coloured dot for intensity, and a coloured border to mark today — three pieces of information carried entirely by hue, which is unreadable if you cannot separate those colours. All three are now also stated in words in the row's spoken name.
Motion and vestibular safety
Rooster honours the system Reduce Motion setting everywhere, and it is enforced structurally rather than remembered case by case: every animation in the app is required to go through a single motion module, and that module checks the setting.
Critically, Reduce Motion does not make state changes disappear. Animations resolve immediately to their finished state instead of being skipped, so you still see the result — you just do not see it move. The animated rooster mascot resolves to a distinct static pose for each of its moods, so the mascot still communicates what it was communicating.
Nothing in either app flashes, strobes, auto-scrolls, or moves on a loop behind text you are reading.
Text size and touch targets
Rooster never disables text scaling, so all of its text responds to the system text-size setting, including Larger Accessibility Sizes on iOS. Layouts use flexible spacing rather than fixed text heights.
Interactive controls are sized at 52pt minimum — above Apple's 44pt guideline — and the workout player specifically uses oversized targets and large numerals, because it is used while moving, sweating, and out of breath, which is a temporary impairment worth designing for.
Rooster follows the system light or dark appearance rather than forcing one, and both are fully themed.
Screen readers
Headings are marked as headings, so VoiceOver's heading rotor works: each screen exposes its own title, then the section labels within it, which is how you skip to the part you want instead of swiping through everything. Roughly a hundred elements across the app carry the role. We deliberately did not mark list-item names as headings — a rotor listing every workout, habit, and step is as useless as one listing nothing.
Buttons, chips, tabs, form fields, tappable cards, and dialog close controls all expose a name, and selected, disabled, and busy states are announced rather than shown only visually. Progress indicators report their value. Read-only tags are deliberately built as non-interactive, so a decorative label is not announced as a button that does nothing. Illustrations carry text descriptions, and both the bar chart and the line chart give every data point its own value.
Toggles that appear in a list say what they act on: the buttons in the daily-step and habit lists announce the step or habit by name, rather than a column of identical “Done”s. A tappable card cannot be added without a name — that requirement is enforced by the type system rather than left to review, because it is exactly the kind of thing that gets forgotten.
What is still not right. Most multi-part cards are still read out piece by piece rather than grouped into a single item; only one is grouped so far. Hints — the extra sentence explaining what a control will do — are used in exactly one place, on the readiness check-in, and we would rather add them sparingly where a label genuinely cannot carry the consequence than narrate every button.
And the honest limitation behind all of it: this list comes from reading the code and from the platform's own accessibility APIs, not from watching a person navigate the app with a screen reader. Until that happens, treat this section as a description of intent that has been verified mechanically, and tell us what we got wrong.
Hearing, speech, and alternatives to voice
No feature in Rooster requires hearing. Spoken coaching is optional and off unless you turn it on, and every cue it speaks is also on screen as text. Video calls with a character are an optional extra, never a required step, and full text chat with the same character covers the same ground — so there is a complete non-audio path through the product.
Video calls do not currently have captions or transcripts. If you rely on captions, text chat is the equivalent feature today, and we would rather say so plainly than let you buy a plan expecting captioned calls.
Vision-dependent features
Form Check uses the camera to look at how you are moving, so it needs enough sight to aim a camera. It is an optional extra on the highest plan, it is labelled beta, and nothing else in the product depends on it — plans, workouts, logging, progress, habits, daily steps, and coaching all work without it.
Not requiring things of you
A lot of what makes an app usable is not a screen-reader label. Rooster asks for as little as possible and makes almost all of it optional: no weight, height, measurement, or photo is ever required, the baseline fitness tests can all be skipped, importing health data is optional and declining changes nothing but manual entry, and onboarding questions that do not apply to you are not asked.
Sessions can be shortened to the time and energy you actually have, reporting pain removes a movement and substitutes another rather than warning you and carrying on, and missing sessions rebuilds the week instead of scoring you against it. Time pressure, guilt mechanics, and streak-loss framing are absent by design, which matters for anyone managing fatigue, chronic pain, an eating disorder history, or a fluctuating condition.
How this page is maintained
Last reviewed 29 July 2026 against the shipping build. The contrast figures come from measuring the colour tokens the app actually uses, and the screen-reader notes come from reading the components rather than from intent. When we fix something on the gap list we will move it out of the gap list, and if we find a new problem we will add it here rather than wait until it is solved.