A smaller available width should trigger a reasoned change in arrangement, not automatic shrinking of everything.
By the end: derive a content-based column change and distinguish a layout model from actual reflow validation.
Start with the content's minimum useful space
Responsive design changes presentation as available space and other conditions change. Breakpoints should follow content constraints rather than a belief that every tablet has one fixed width. A card containing a long name or translated action can need more space than a short placeholder suggests.
For a simple equal-card model, choose a minimum card width of 180 design units and a gutter of 16. Two cards need at least 376 units; three need 572. Below those widths, reduce the column count. The arithmetic states a layout constraint, not a measured optimum for every card.
Derive the width that the content actually receives
Available page width and available text width are different quantities. Imagine a container 640 design units wide with 24 units of padding on each side. The interior receives 592 units because both outer spaces consume width. If two cards share that interior with a 16 unit gutter between them, subtract the gutter before dividing. Each card receives 288 units. Giving each card half of 592 before adding the gutter would exceed the interior by sixteen units.
Now account for the card's own padding. If each 288 unit card reserves sixteen units on both sides, its text receives 256 units. This second subtraction is easy to miss when a diagram labels only the outside rectangles. Borders can consume more width depending on the sizing rules. The worked budget below omits borders and states that assumption. Drawing units describe the allocation, not this panel's CSS pixel width or physical display dimensions.
Subtract outside space, then the card's inside space
Horizontal geometry uses a one-to-one drawing-unit scale. The 640-unit outer box contains 24-unit padding, two 288-unit cards, one 16-unit gutter, and another 24-unit padding. Each card's 16-unit inner padding leaves 256 units for text. Vertical sizes and label leaders are schematic; borders consume no budget here.
The same calculation generalizes by counting spaces instead of memorizing a device breakpoint. Three cards require two internal gutters; four require three. There is no gutter before the first card or after the last unless a separate outer space has been specified. For three cards in the 592 unit interior, two sixteen unit gutters consume 32 units. The remaining 560 gives about 186.667 per card. After the card padding, only about 154.667 units remain for each card's text. That is a different content constraint from its outside width.
Predict where the pressure will first appear in the specimen pair. Both cards preserve the same workshop title, day, start time, entrance, and booking condition. The narrower text allocation may create another title line or split the booking condition across lines. It need not remove any words. Compare the actual line breaks on your platform and trace the outside card edge separately from the text edge. The specimens use real text rather than scaled placeholder strokes, so their height follows the rendered lines rather than a drawn rectangle's promise.
Do not infer a universal minimum from the title's nominal font size. An 18 CSS pixel font does not make every glyph eighteen pixels wide or eighteen pixels tall. Glyph advances determine how much horizontal space the text uses, while line boxes allocate vertical room. A different installed generic font can change both wrapping and apparent size. A maximum width expressed in ch uses the zero glyph's advance, not a guarantee about the number of arbitrary letters that fit. Actual names and punctuation still require inspection.
The text edge is inside the card edge
More available measure
Clay workshop
Saturday · 14:00
West entrance
Booking required. Bring your confirmation to the desk.
Less available measure
Clay workshop
Saturday · 14:00
West entrance
Booking required. Bring your confirmation to the desk.
Both notices contain identical facts in 18 CSS pixel text, with a 22 pixel title. Each uses sixteen pixels of card padding. The second requests a narrower maximum width, capped by its panel. These are actual HTML specimens, so font availability and panel space determine the observed wrapping; the earlier diagram's exact design-unit widths are not simulated here.
A calculated column can be positive yet unsuitable. At 186.667 units the arithmetic fits three card boxes into the interior, but it does not establish that their real content works. An unbroken identifier, a minimum control width, or an intrinsic image size may impose another constraint. Real CSS grid sizing considers content and track minimums that the simple equal division omits. Treat the width budget as a way to identify where space went, then test the actual content instead of declaring every mathematically feasible arrangement successful.
Preserve order and information
The model lays out six numbered cards in source order, left to right and then down. It keeps a wide three-column reference beside the selected arrangement. Only the container width changes. It does not remove lower-priority cards, change the source order, or shrink a text font to make more columns fit.
The drawings are scaled schematics of card placement. Numbers identify cards, and strokes stand for text rather than rendering full miniature interfaces. A real implementation needs tests with actual text, input controls, zoom, and browser layout. A valid column count in this model is not a WCAG conformance result.
Keep relationships intact when columns disappear
Changing the number of columns changes where a reader encounters neighboring content. Suppose each workshop has its own title, date, entrance, and booking condition. In a wide layout, two workshop cards can sit beside each other. In a single column, one complete card should usually precede the next complete card. If the markup instead puts all titles first, all dates next, and all conditions last, a narrow layout may separate a condition from the workshop it qualifies. The problem is association.
Follow the paired notice examples as a reading task. Read the clay workshop's title and continue until you have its booking requirement. Then do the same for printmaking. The grouped version keeps each fact inside one workshop unit. The separated version has the same facts but asks you to retain a category while moving through several detached groups. That arrangement may suit a different comparison task, but it is a poor default for finding all details about one workshop. The task determines the needed proximity.
Keep each workshop's facts together
Facts separated by role
Clay workshop Printmaking workshop
Clay: Saturday, 14:00 Printmaking: Sunday, 10:00
Clay: Booking required Printmaking: No booking required
Facts grouped by workshop
Clay workshop
Saturday, 14:00 Booking required
Printmaking workshop
Sunday, 10:00 No booking required
Both arrangements preserve clay on Saturday at 14:00 with booking required, and printmaking on Sunday at 10:00 with no booking required. The left groups facts by role. The right groups by workshop. Follow a single workshop through each arrangement to compare the needed cross references.
Source order is the sequence in the document, while visual order is the sequence suggested by placement. They can differ when layout rules move items to other positions. Keyboard focus order is another sequence, involving focusable elements rather than every text node. Headings can be read without keyboard focus. Rearranging rectangles demonstrates neither meaningful reading order nor a useful keyboard path. The underlying structure and actual navigation need their own inspection in a real interface.
Consider a booking process whose meaningful sequence is choose a workshop, review its conditions, then confirm the booking. The order schematic shows this sequence alongside a visual-only repair that leaves the source as choose, confirm, review. Moving review upward repairs the screenshot but not the underlying sequence. A more direct repair puts the steps in meaningful document order and uses a layout that preserves it. These numbered blocks are explanatory marks, not functioning controls or a demonstration of browser focus movement.
Moving the block does not rewrite the document
These are schematic sequences, not controls. The first two rows describe a visual-only repair: review moves before confirm visually, but source order still puts confirm first. The final row changes the underlying order. No arrows here represent a tested keyboard focus path.
WCAG 1.3.2 concerns a programmatically determinable meaningful sequence where order affects meaning. It does not demand one universal order for every independent item. Two unrelated workshop articles might appear in either order if each article stays coherent. Instructions within one booking process have a stronger sequencing constraint. Do not turn a source order observation into a claim about all keyboard behavior or complete accessibility. Test the actual focus path through actionable elements, because a document can have sensible prose order while its interactive navigation still creates a separate problem.
Try a paper adaptation before touching a layout control. Take the workshop facts shown here and write a one column version that preserves complete workshop units. Then write a comparison version that aligns the two start times. Explain which question each version answers with fewer cross references. Both can retain the facts and still organize them differently. If you change copy to shorten a label, record that as a content change rather than crediting width alone. A combined revision cannot isolate which individual change caused a different reader response.
Inspect the relationship
Budget the minimum width for n columns
With minimum card width a = 180 and gap g = 16, two columns need 376 inner design units and three need 572.
Reduce columns rather than shrinking content
1 column; 6 rows; 320 units per card. Source order stays 1, 2, 3, 4, 5, 6.
Both drawings share a horizontal scale. Six schematic cards keep order 1–6. The model requires at least 180 units per card and 16-unit gutters; controls change only the selected inner width. Card numbers remain readable diagram labels, not scaled body text. No card or its contents is removed.
Explore the threshold on both sides
The existing card model chooses a column count from an assumed minimum card width. Start by deriving the two column threshold instead of accepting the preset's name. Two cards at 180 units consume 360. They need one gutter of sixteen, so the interior must reach 376 units. Three cards consume 540 plus two gutters totaling 32, giving 572. These are inner widths without outside padding. Adding padding later would increase the required outer width, not reduce the space each card was promised by the minimum assumption.
The threshold figure shows the neighboring numerical cases that the slider does not select directly. At 375 inner units, two equal columns with a sixteen unit gutter would each receive 179.5, below the assumed minimum. At 376, each gets exactly 180. For three columns, 571 gives about 179.667 per card, while 572 gives exactly 180. One unit can change the count. That discontinuity belongs to the selection rule, not to a sudden improvement in anyone's reading ability.
The exact boundary is arithmetic, not a slider state
Inner width
Candidate columns
Width per card
Meets 180?
375 units
2
179.5 units
No
376 units
2
180 units
Yes
571 units
3
approximately 179.667 units
No
572 units
3
180 units
Yes
Candidate card width subtracts n−1 gutters of sixteen units, then divides by n. Widths immediately below 376 and 572 miss the assumed 180-unit minimum. These exact boundary cases are static calculations, not extra lab controls.
Use the actual presets to investigate a larger jump. Select the wide 640 unit state and predict the result before looking at the status. Two gutters consume 32 units, leaving 608 for three cards, or about 202.667 each. Next select 400 units. One gutter leaves 384 for two cards, so each receives 192. Finally select 320. The two column requirement is no longer met, so the model uses one 320 unit card per row. The card width can grow when the column count drops.
Watch card numbers as well as widths. Six cards in three columns require two rows. In two columns they require three rows. In one column they require six rows. The numbers keep their order throughout, so card four changes position without becoming a different card or losing its contents. This makes the model useful for reasoning about placement. The horizontal text strokes are still placeholders. Their apparent fit cannot tell you whether a long title, a translated action, or a spacing override would remain usable in the corresponding real component.
Explore the in between values with the slider after recording those preset predictions. Its selected widths run in forty unit steps starting at 280. They do not include the exact thresholds 376 and 572, so do not claim to have observed those boundary states through the control. At 560 the model still uses two columns; at 600 it can use three. The static boundary arithmetic explains the unseen transition. The diagram's common horizontal scale lets you compare allocations, while the numerical labels state the assumed design units.
Dropping a column can give each card more width
Outer widths share a 0.75 drawing-unit-per-design-unit scale. At 560 units, two 272-unit cards fit with one sixteen-unit gutter. At 600, three cards are about 189.333 units each. The wider container therefore gives each card less width after the count changes. Card heights and labels are schematic, not miniature text layouts.
A fixed minimum is an input to this example, not a discovered property of every card. If a real workshop card needs 220 units, the two column requirement becomes 456 and the three column requirement becomes 692 with the same gutters. The existing model does not offer a minimum width control, so treat those as separate paper calculations. Inspecting real content may justify a different breakpoint or a different composition altogether. Drawing tidy boxes does not validate the assumed minimum.
Enlargement creates width constraints too
At high zoom, a desktop viewport can expose a narrow effective CSS width. WCAG's reflow criterion generally checks vertical content at a width equivalent to 320 CSS px without loss or two-dimensional scrolling, with exceptions for content whose meaning requires two dimensions. Those exceptions do not excuse clipping ordinary paragraphs.
Keep essential comparisons visible when they are the teaching task. Bound the example, simplify secondary details, or use an appropriate table or diagram rather than arbitrarily hiding one side. This library prioritizes tablet comparisons; a complete narrow-viewport audit is separate from the schematic model here.
Test retained information rather than a miniature screenshot
Scaling shrinks everything together. Reflow changes line breaks and block arrangement while text can remain readable. The difference matters when someone enlarges a page. A paragraph that once occupied four lines may need eight, and later content should move downward to make room. Shrinking the whole card to preserve its original height would reverse the reader's enlargement. The specimens retain facts and readable type while allowing different widths and heights.
Use the booking condition as a specific retained information test. Read the final words in the wider specimen, then find them in the narrower one. They should remain present, even if another line is necessary. A fixed height that clips those words would alter what the visitor can know before booking. Merely removing the visible overflow would not solve the problem. The comparison lets content grow; it does not implement or simulate every spacing override, zoom mode, or translated string that a real page would need to accommodate.
Let the notice grow instead of deleting its last line
Clay workshop
Saturday · 14:00
West entrance
Booking required. Bring your confirmation to the desk.
Clay workshop
Saturday · 14:00
West entrance
Booking required. Bring your confirmation to the desk.
Identical facts remain at 18 CSS pixels in both notices; the title stays 22 pixels. The narrower maximum measure can add lines without clipping the booking condition. There is no fixed text height, hidden overflow, or scale transform. These specimens are not a completed zoom or spacing-override audit.
Text spacing can also consume room without changing the facts. At a nominal 18 CSS pixel size, line height 1.5 allocates a nominal 27 pixels per line box. That is not 27 pixels of empty space between letter outlines. Under WCAG 1.4.12, the specified spacing values concern surviving user overrides without lost content or function, subject to the criterion's scope. They are not a universal default recipe. A taller text block must still leave following content and actions reachable rather than hidden beneath a fixed neighbor.
WCAG 1.4.10 generally asks vertically scrolling content to work at a width equivalent to 320 CSS pixels without information or function loss or scrolling in both dimensions. A 1280 CSS pixel starting viewport at 400 percent zoom is the stated equivalent example. This does not mean that every physical tablet is 320 hardware pixels wide. CSS pixels are layout units, and zoom changes the effective layout space. The existing schematic's 320 design units are not an actual browser reflow test at that CSS width.
Some information needs two dimensions to preserve its relationships. A seating map needs neighboring seats to stay neighbors; turning it into an arbitrary sequence would lose that geometry. The seat plan below labels rows and seat numbers so those relationships are explicit. Reflow exceptions can apply to parts such as necessary diagrams and data tables, not automatically to every nearby paragraph. A workshop description should still wrap normally. Even within an excepted table, ordinary text in individual cells needs attention rather than permission to clip or remain unreadable.
Seat relationships need two dimensions
This seating plan is schematic, not a measured room. Rows A and B and seats 1 through 4 retain their neighborhood across the central aisle. Ordinary workshop prose can wrap, but preserving a seat map's relationships may require a different layout treatment. The picture alone is not a reflow exception or conformance verdict for a real page.
For a final guided check, compare the narrow notice with the seating plan and name what each must preserve. The notice needs every fact and its workshop association, but its lines can change. The plan needs the seat relationships as well as labels, so its geometry has a different constraint. Then state what remains untested here. Real browser layout with zoom, keyboard access, content variations, and user spacing adjustments requires actual inspection. These examples explain recomposition, not full WCAG conformance or measured usability.
Exercises
Find the breakpoint
Cards need at least 200 units each and a gap of 24. What is the minimum inner container width for two columns? What if the outer container also has 20-unit padding on both sides?
Hint
Count one gap between two cards, then add outer padding separately.
Worked answer
Budget
Width
Two cards
400
One gap
24
Inner container
424
With both outer paddings
464
Distinguish the inner width from the outer width.
Two columns need 2 × 200 + 24 = 424 units of inner width. With 40 units of total outer padding, the full container must be at least 464. These thresholds assume equal columns and no extra borders or intrinsic-content requirements.
Handle a long translated label
A translated button no longer fits a card. Is reducing all body text to 11 px a sound first response?
Hint
The problem may be the allocation, not the reader's need for readable text.
Worked answer
Option
What to preserve
Wrap the label
Complete meaning
Grow the card
No overlapping controls
Reduce columns
Readable text and source order
Recomposition is often preferable to global shrinking.
No. Test wrapping or a clearer equivalent label, allow more height, or reduce column count. Preserve the action's meaning and operability. Check surrounding controls, source order, and enlarged text. A single tiny-font workaround can conceal a layout constraint while making the entire page harder to read.
Sources and further reading
These optional references support the stated mechanisms and technical criteria. Selected relevant passages were reviewed. The notices, diagrams, and numerical examples are original teaching comparisons, not empirical usability results. Design hypotheses need tests with intended readers; technical checks do not establish aesthetic quality or whole-site conformance.