VOCABULARY / ENTRY
Progressive Enhancement
progressive-enhancement
Start from the most basic capability: use semantic HTML so core content and the primary task (a working link or form) succeed under the most basic browser, device, and network conditions, then layer on styling and scripted enhancements as the environment actually supports them.
Recognizing it
- Core content is delivered as semantic HTML that stays readable and keeps links and forms usable with scripting disabled or on an older browser
- Each enhancement layer is gated by detecting the actual feature, not by reading a browser or device string
- Modern browsers get a fuller experience; the baseline layer is a starting point, not the final delivery for everyone
Concept boundary
Progressive enhancement is about reach across environments and capabilities: whether the core function works under the most basic conditions, with richer layers added on top of that. This differs from progressive disclosure, which reveals information detail on demand and has nothing to do with device or scripting capability. It also differs from graceful degradation: graceful degradation starts from the most advanced experience and subtracts for older environments, while progressive enhancement starts from the most basic working version and adds. The two directions are opposite but can complement each other.
When to consider it
- The network, device, and scripting environment of every visitor cannot be guaranteed to be the same
- A core task, such as submitting a form or following a link to a detail page, must work for the widest possible set of visitors
- The product is a public service, content site, or similar context with a high bar for reach
When to be cautious
- Making the baseline worse than modern browsers deserve on the excuse that a richer layer will follow anyway
- Judging capability from a browser or device string instead of detecting whether the specific feature exists
- Treating the pacing of how much information is shown as progressive enhancement, when that belongs to progressive disclosure
Tradeoff
Building from the most basic capability upward and layering on top takes more design, implementation, and testing effort than coding only for modern browsers; in exchange it buys wider reach and more tolerance when the environment is uncertain.
Conditional rules · Editorial advice
Related entries
Inclusive design identifies who is excluded by ability, device, or network conditions; progressive enhancement is a construction method that lets those people still complete the core task.
Both stage things in phases, but progressive disclosure phases content by importance while progressive enhancement phases the experience by supported capability — a different axis.
Server-side validation belongs to the baseline layer that must always hold; client-side instant validation is an enhancement layered on once scripting is detected, and cannot substitute for the baseline check.
Sources and what they support
Defines progressive enhancement as delivering baseline content and functionality to as many users as possible first, with the best experience reserved for modern browsers that can run all the code; explains that feature detection determines browser capability while polyfills fill missing features with script.
Retrieved: 2026-09-15 · Archived 2026-09-16Defines graceful degradation as building the fully-featured experience for the newest browsers first and keeping a reduced but usable experience for older ones, a direction opposite to progressive enhancement, with both approaches able to complement each other.
Retrieved: 2026-09-15 · Archived 2026-09-16Uses the peanut/chocolate/candy-shell analogy to explain that progressive enhancement 'thinks from the content out': semantic markup is the base layer every user gets, with CSS and unobtrusive JavaScript layered on top in sequence.
Retrieved: 2026-09-15 · Archived 2026-09-16Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
No operable specimen yet; the illustration is editorial. When applied to a product, still verify that the core task truly works with scripting disabled or on an older browser, that every enhancement layer is gated by feature detection rather than browser-string checks, and that modern browsers keep the full experience rather than a lowered one adopted in the name of progressive enhancement.
{
"values": [
"Reach first",
"Capability-driven layering",
"Detect capability rather than guess the environment"
],
"tension": "Reliability of the baseline versus the richness modern browsers could get",
"questions": [
"If scripting were turned off and the browser were as basic as possible, would the core task still work?",
"Is this layer of the experience unlocked by a detected capability, or by guessing the browser?"
]
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.