Keep functions reachable; reduce only presentation

What it is

Degradation cuts presentation: resolution, motion, density, effects, decorative media. Function entries stay — the same action can still be found and finished, just less dressed. Shipping the low end as a "missing-features edition" (no search, no checkout, no comments) is another product, not degradation. Reachable means the task path still runs for keyboard, screen reader, and a small screen, not merely that animation turned off.

This is which layers a degrade is allowed to touch — not which signal trips it, and not which decoration is cut first inside presentation.

Why it happens

Function and presentation share a surface, but budget is spent mostly on presentation: fills, textures, tweens, extra requests. The function layer is thinner: a focusable control, a submit, a result. Stripping the function layer saves little (one fewer button barely reduces paint) and drops completion to zero. Presentation can be reduced continuously: images from 2x to 1x to a placeholder, motion from tween to instant to none, lists from large cards to dense text rows — each rung still points at the same action. What the low end needs is "I can still finish", not "the same skin as the flagship".

Unreachability wears disguises. The entry is present but a tap has no continuation (it depended on script that was cut); the entry lives only on a gesture or drag that was turned off, so the keyboard cannot reach it; density compression parks the entry under another hit target. Those look like presentation cuts and are function cuts. The mark of presentation-only is: the same task still completes with the same kind of control, feedback still exists (it may be plainer), and the result still writes back.

Where it stops holding

Law, safety, and capacity can make a function unavailable in an environment (regional rights, risk rejection, storage quota) — that is a business refusal, not a performance degrade. Experimental capabilities (WebGPU effects, device sensors) already have a "without it, none" branch; reachability applies to main tasks the product promised, not every lab feature. An offline first tier can be read-only cache with submits queued until online; that still counts as reachable (the action was accepted) if the queue and state are visible. Sending low-end users to a "please use another device" page is refusal of service, not degradation. A brand page that is only for display can reduce to almost text and remain reachable, because the task is to read that sentence.

Applying it

• For every degrade tier, list tasks that must still complete (search, read, submit, pay, settings). Presentation may get plainer each tier; the list must not shrink.
• Only image quality, motion, blur, autoplay, and decorative extra modules may be cut. Replacement paths must still be focusable, submittable controls, not something that lives only on a gesture you turned off.
• When an enhancement that needed optional script fails, fall back to an HTML form or an ordinary link; do not leave a dead button.
• How to check: on the lowest tier (weak CPU, slow net, reduced motion on), walk the main task list. Any step with no entry, a tap with no continuation, or a continuation that required motion you turned off, cut function. Compare the flagship tier: what is missing should be skin, not steps.

Related

• Same group: R3.16.1 Degrade by measured capability, not by device model · R3.16.2 Order degradations by impact on task completion
• Nearby: R3.08 Animation Cost · R3.04 Performance Budgets · K1.02 Screen Size and Density
• Search terms: functional reachability · graceful degradation · progressive enhancement · capability detection