Progressive enhancement is the discipline of building the baseline experience first with the most universally supported technologies, then layering enhancements that improve the experience for users with more capable browsers and devices. It's the opposite of 'graceful degradation,' which builds for the most capable browser and tries to fall back when capabilities are missing. **The three-layer model:** **Layer 1: Semantic HTML.** The content structure — headings, paragraphs, lists, links, forms. This layer must work without CSS or JavaScript. A user with the most basic browser, the slowest connection, or assistive technology should be able to access the content and complete primary tasks. **Layer 2: CSS.** Visual presentation — typography, layout, colour, responsive design. CSS enhances readability and brand expression, but the underlying functionality remains accessible without it. **Layer 3: JavaScript.** Interactive enhancements — dynamic interactions, client-side validation, single-page navigation, complex animations. JavaScript improves the experience for capable users without breaking it for users without JavaScript. **Why progressive enhancement matters in 2026:** **Reliability.** JavaScript fails for many reasons: third-party script blocking, network errors, browser bugs, ad-blocker interference, slow loads timing out. Sites built progressively work even when JavaScript fails; sites that depend entirely on JavaScript fail entirely when JavaScript fails. **Accessibility.** Screen readers and assistive technologies work most reliably with semantic HTML. JavaScript-heavy sites that build interactivity through divs and ARIA workarounds typically have worse accessibility than sites that use semantic HTML primitives directly. **Performance.** Sites that work with minimal JavaScript load faster, especially on slower mobile networks. Even when JavaScript is loaded, the page is usable while the script is downloading and parsing. **SEO.** Search engine crawlers and AI search engine crawlers parse HTML reliably; their JavaScript rendering varies in completeness and timing. Content delivered in the initial HTML is reliably indexed; content that requires JavaScript execution may or may not be indexed. **Resilience.** Browser bugs, third-party script failures, network issues, and other unexpected problems break JavaScript-dependent sites entirely while progressively-built sites degrade gracefully. **Common applications:** **Forms.** Progressively enhanced forms work as standard HTML forms with server-side validation; JavaScript adds client-side validation and inline feedback. If JavaScript fails, the form still submits and validates server-side. The reverse pattern (JavaScript-only forms with no server-side fallback) breaks completely when JavaScript fails. **Navigation.** Progressively enhanced navigation uses standard `<a>` links to real URLs that work without JavaScript; client-side routing enhances navigation speed for users with JavaScript. The reverse pattern (single-page apps with no real URLs) breaks completely without JavaScript and produces SEO challenges. **Interactive widgets.** Progressively enhanced disclosure widgets (accordions, tabs, dropdowns) use semantic HTML (`<details>`, `<summary>`, ARIA-described patterns) that works without JavaScript; JavaScript adds animation and richer interaction. **Where progressive enhancement is hard:** Truly application-style sites (interactive dashboards, complex data manipulation tools, real-time collaboration) inherently require JavaScript to function. Progressive enhancement doesn't apply uniformly to these contexts. The principle still applies for marketing pages, content pages, and conversion paths within otherwise-application-style sites. **Modern frameworks and progressive enhancement:** React, Vue, and Next.js can all support progressive enhancement when used carefully. Server-side rendering (SSR) and static site generation (SSG) deliver semantic HTML in the initial response; client-side hydration adds interactivity progressively. Frameworks like Astro and SvelteKit explicitly emphasize progressive enhancement patterns. Frameworks misused for everything-on-the-client patterns (SPA-only with no SSR, no fallback for JavaScript failures) produce sites that violate progressive enhancement principles even though the underlying framework supports it. **Practical recommendation for Canadian businesses.** Most marketing websites should be built with progressive enhancement principles. The cost is minimal; the resilience and accessibility benefits are substantial. Application-style functionality within marketing sites (live chat, complex calculators, interactive pricing tools) can use richer JavaScript while the surrounding marketing context remains progressively enhanced. For pure application contexts (member portals, internal tools, real-time collaboration), the cost-benefit shifts and full client-side architectures may be appropriate. Even there, accessibility and graceful degradation for failure cases remain important.