Implementation worksheet · 5 min read
An iOS Onboarding Dynamic Type Acceptance Test
Test onboarding at six text sizes rather than one: the smallest, the default, the largest standard size, and the three accessibility sizes. At each, check that no text truncates, no control falls off screen, no two elements overlap, every tap target stays at least 44 points, and — the one specific to onboarding — every coach mark still points at its target. Anchoring guidance to a view rather than to a coordinate is what makes the last one pass. A layout that only holds at the default size is not a layout; it is a screenshot.
Dynamic Type is a system setting many people adjust and never think about again, and it changes layout far more than a designer working at the default size expects. Onboarding is the worst place for it to break, because it is the first screen a new user sees and the coach marks are anchored to a layout that just moved.
Put it into practice
1. Anchor coach marks to views, never to coordinates
A stored frame is correct until the text above it grows by two lines. Anchoring to the view means the system moves the highlight for you. This single decision removes most of the dynamic-type failures in onboarding and cannot be retrofitted cheaply once the flow is built around positions.
2. Test the three accessibility sizes, not just the largest standard one
The accessibility sizes are substantially larger than anything in the standard range and are where single-line labels become three lines and horizontal button rows stop fitting. A test that stops at the largest standard size passes while the real failures sit one setting further along.
3. Check that nothing truncates and nothing overlaps
Truncated text in onboarding removes the explanation the step exists to deliver. Overlapping elements make a screen look broken on first launch. Both are visible in seconds per size and neither is caught by a test suite that only asserts view presence.
4. Keep tap targets at 44 points and reachable
Growing text pushes controls down and sometimes off screen entirely. Verify the primary action is reachable and still meets the minimum target size at every setting, including with the keyboard shown where a step takes input.
5. Let content scroll rather than fixing it to the screen
An onboarding step designed to fit exactly will not fit at accessibility sizes. Scrollable content with a pinned primary action handles every size gracefully; a fixed layout handles one and breaks the rest.
6. Capture a screenshot at each size and review them together
Six screenshots side by side make problems obvious that are easy to miss one at a time. It also makes the check reviewable by someone who is not running the build, which is what turns it into an acceptance test rather than a developer habit.
The six sizes
Copy this structure into your review document and record your observed result for each row.
| Text size | No truncation | No overlap | Targets ≥44pt | Coach marks aligned |
|---|---|---|---|---|
| Smallest standard | ||||
| Default | ||||
| Largest standard | ||||
| Accessibility Medium | ||||
| Accessibility Large | ||||
| Accessibility Extra Large | ||||
| Default + keyboard shown | ||||
| Largest + landscape |
A failure worth checking
The coach mark anchored to a stored frame. At the default size it sits perfectly over the button. At an accessibility size the paragraph above grows by two lines, the button moves down 60 points, and the highlight now covers empty space with an instruction pointing at nothing. The user reading at that size is, by definition, someone who needed the guidance most, and what they get is a broken first impression.
Common questions
How many users actually change text size?
Enough that it is not an edge case, and the exact share varies by audience — an app with an older user base sees far more of it. Rather than guessing, note that this is an accessibility setting, which makes it a baseline rather than a numbers question.
Can this be automated?
Partly. Snapshot tests across the size range catch truncation and overlap regressions well. Coach-mark alignment and reachability are easier to verify by eye, which is why the screenshot-review step is in the list rather than assumed away.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.