Large type may be on together with other assistive settings

What it is

Large type rarely travels alone. The same person often also has bold text, higher contrast, button shapes, or a larger display zoom. Each switch can pass on its own. Stacked, line boxes fill, strokes thicken, controls grow, and a layout that just fitted overflows again. Combined assistive type settings asks QA to cover the common cells of that Cartesian product, not only the type-size axis.

Why it happens

Accessibility switches are not mutually exclusive. A low-vision reader enlarges type to make letters bigger, turns on bold to make strokes clear, and raises contrast to lift letters off the ground — three parts of one reading task. Bold makes glyphs optically larger, equivalent to another type step on top of the step already taken; display zoom shrinks the viewport, cutting available width under already-large type. Maximum type plus bold plus a narrow viewport is the real worst cell. Engineering exposes the switches through different APIs, so the matrix is split into “type,” “bold,” “contrast” cases and the combination never reaches a device. Failures are combination-only too: bold adds a weight on top of a face already tuned for size, and the glyphs mud; contrast changes colour, and a hairline at large size disappears.

Where it stops holding

The full product of every switch is not required — some combinations cannot be on together, some cancel. Favour “large × bold,” “large × display zoom,” “large × high contrast,” the stacks most common on a reading task. Reduce Motion and voice control are orthogonal to type size and sit outside this compatibility claim. Desktop page zoom already enlarges type and the viewport together; stacking OS text size on top double-enlarges, so tests must know which layer is moving.

Applying it

• At maximum type, also turn on the system’s bold-text switch and walk forms and navigation. Muddy weight or clipped button copy is a combination failure, not a type-size failure.
• Add a pass of maximum type plus display zoom (or browser zoom) and watch wrapping after available width is eaten.
• Write these stacks as their own test cases. A footnote on the “Dynamic Type” case will not be run.

Related

• Same group: F4.16.1 Scale testing must include the system’s largest type bucket, not only the usual range · F4.16.2 Icon-plus-label controls must keep their alignment after type scales · F4.16.4 Interfaces that ignore Dynamic Type lose low-vision and older users
• Nearby: J5.13 System accessibility settings · J2.15 Dark and high-contrast compatibility
• Search terms: Bold Text · combined accessibility settings · Dynamic Type