A charity donation page at 400% zoom truncates campaign titles, cuts off preset amount buttons and scrolls sideways; how do you fix it in the design system?
answer
- 400 percent zoom equals 320 wide
- shared components, not one page
- wrap by default
- truncate only if full text reachable
- unpin sticky bars when narrow
basics
~20 sTreat it as a reflow and resize failure in shared components: stack the amount buttons, let titles wrap instead of truncating, keep only two-dimensional content in its own scroll area, and truncate only where the full text stays reachable.
solid answer
~50 sAt 400 percent zoom a 1280-wide window behaves like one 320 wide, which WCAG 1.4.10 Reflow requires to work without two-dimensional scrolling, and 1.4.4 requires text to reach 200 percent without loss. The page fails because components assume desktop room: a row of fixed-width amount buttons that cannot wrap, titles clamped to one line with no way to read the rest, and a wide element pushing the page sideways. Fix it in the system, not the page: the amount group wraps or stacks, button labels wrap inside buttons that grow, and campaign titles wrap by default. Truncation becomes a documented exception, allowed only when the full text is reachable, for example on the linked campaign page, and never for values the donor must check, such as the amount. Pinned donate bars stop being pinned at narrow widths. Then test every component at 320 wide and at 200 percent text.
go deeper
Recall that 400 percent zoom on a 1280-wide window means a 320-wide layout, that text should wrap by default, and that amounts and action labels must never be cut off.
Explain which symptom maps to which criterion and why truncation is acceptable only when a link or reveal mechanism exposes the full text.
Show how you trace each symptom to a shared component assumption, write one wrap-versus-truncate rule, and add narrow-width and large-text checks for every variant.
Weigh conversion-driven requests, such as a pinned donate bar, against reading space at high zoom, and decide which patterns the system forbids and which it allows with conditions.
## Reading the symptoms A 1280-wide window at 400 percent zoom lays out as if it were 320 wide, which is exactly the reference size of WCAG 2.2 **SC 1.4.10 Reflow** (Level AA). Each symptom points at a criterion and a component assumption: | Symptom | Criterion at stake | Likely cause in the system | |---|---|---| | The page scrolls sideways to read lines | 1.4.10 Reflow | A component or template with a minimum width wider than 320, or a row that cannot wrap | | Preset amount buttons cut off at the edge | 1.4.10 and 1.4.4 (loss of functionality) | Fixed-width buttons in a single, non-wrapping row | | Campaign titles truncated with no way to read them | 1.4.10 and 1.4.4 (loss of content) | A one-line clamp with no link or reveal | | A pinned donate bar covering much of the screen | Reading space; 2.4.11 Focus Not Obscured (Minimum) if it hides focus | A sticky element that stays pinned at every width | Because the campaign card, the amount selector and the donate bar are shared components, the same failure appears on every campaign page. Patching one page leaves the rest broken. ## Wrap versus truncate: the decision rule The core design question is what text does when it no longer fits. A system should write the rule down once: 1. **Wrap by default.** Text that wraps onto more lines keeps all of its content and needs no extra mechanism. 2. **Truncate only in genuinely fixed space, and only when the full text is reachable.** The Understanding document for Reflow gives the pattern: truncated content is acceptable when a link leads to a page where it is fully visible, or a mechanism on the page reveals it. A campaign card whose title links to the campaign page can truncate. 3. **Never truncate values the user must verify or act on**: the donation amount, its frequency, the cause it goes to, the primary action label, error messages. 4. **Unbounded, user-supplied strings** (a supporter's long name on a donor wall) are the classic acceptable truncation, with the full value available on focus, on activation, or on a detail page. ## Fixing the components - **Amount selector**: the group wraps into two rows or stacks into a column at narrow widths; each button sizes to its label with padding; a custom-amount field goes full width. - **Buttons**: labels wrap inside a button that grows in height, rather than being cut at a fixed width. - **Campaign card**: the title wraps; if a line limit is kept for layout reasons, it comes with the link to the full page and is expressed in lines, not a fixed height. - **Summary rows**: label and value stack when side-by-side no longer fits, so the amount is never cut. - **Wide content**: a chart of funds raised or a table of results scrolls inside its own container, since two-dimensional content is excepted but the page around it is not. ## Fixing the templates - The page collapses to a **single column**, with the story, the donation panel and related campaigns stacked. - A **pinned donate bar** stops being pinned at narrow widths, or becomes toggleable, as the Understanding document suggests for sticky content, so it cannot eat the viewport or hide the focused control. - Navigation collapses behind a menu button, keeping every option reachable. Native apps are outside WCAG's web criteria in the literal sense, but the charity's app meets the same pressure through the operating system's largest text sizes, so the same wrap-first rule and stacking layouts serve both. ## Keeping it fixed - Add a **narrow-width and large-text check** for every component variant to the component workshop: 320 wide, and 200 percent text. - Stress each component with the **longest real content**: the longest campaign title, a large custom amount, a translated label. - Document the wrap-versus-truncate rule in each text-bearing component's guidance, including which fields may never truncate. - Re-check the page templates as well as the components, because a component that wraps correctly can still be clipped by a fixed-height parent region or a rail with a fixed width. A senior answer diagnoses the shared component assumptions behind each symptom, applies one written rule for wrapping and truncation, and adds a test that stops the failure coming back.
- Why is truncating the donation amount worse than truncating a campaign title in a card?The amount is a value the donor must verify before paying, and a cut-off figure can be misread as a different amount. A card title that links to its campaign page loses nothing, because the full title is one step away. Values to verify, action labels and errors must wrap; linked teaser text may truncate.
- The team fixes the campaign page but the same clipping appears on the homepage's quick-donate widget. What went wrong?The fix was applied to a page instead of to the shared components. The amount selector and buttons need their narrow-width and large-text behaviour built in, so every surface that uses them inherits it. Add a component-level test at 320 wide and 200 percent text so a page-only fix cannot pass review again.
Truncation is like a newspaper teaser that ends with 'continued on page 6': fine when page 6 exists and the reader can get there, a loss when the rest of the story was simply cut.
saying these in an interview costs you the question
- An ellipsis on any text at high zoom is an automatic WCAG failure.
- Fixing the one reported page is enough; the components are fine.
- Truncating the donation amount is acceptable if the full value appears on hover.
- Sideways scrolling is acceptable at 400 percent zoom because that is an extreme setting.
- A pinned donate bar must stay pinned at every width to protect conversions.