Does your site work for everyone, everywhere?

Your visitors use different browsers, screen sizes, operating systems, and assistive technologies — and their JavaScript sometimes fails: blocked, half-loaded, or crashing after it arrived. A site tested only in your own browser will quietly break for a slice of real users. The durable approach is progressive enhancement: build a broadly compatible HTML baseline, then layer on styling and interactivity without making supported core tasks depend on them.

Progressive enhancement in practice

1. Content and structure first. Semantic HTML that delivers the actual content with no CSS and no JS — the baseline you protect hardest, because everything else stands on it.
2. Presentation next. CSS enhances layout and style. Supported browsers get the enhanced treatment, while deliberately designed fallbacks keep baseline content readable where newer features are missing — that part comes from your fallback values and testing, not for free.
3. Behavior last. JavaScript adds convenience. A form should submit to a working server endpoint (with the appropriate method) even when client-side validation never loads — and the server must validate every submission anyway, because client-side checks can always be bypassed.

This replaces the old "best viewed in browser X" mindset: begin with a compatible baseline and add enhancements, rather than requiring a specific browser and patching holes afterward (that reversed approach — build fancy, then add fallbacks — is graceful degradation, and it tends to miss more).

Takeaway: Start with a broadly compatible baseline and enhance upward — the fewer things a visitor's browser must get right before your content works, the fewer visitors ever meet a broken page.

What to do

1. Write semantic, valid HTML as the foundation — real links for navigation, native controls where possible, labeled fields, forms backed by a working server endpoint. Validity helps; it doesn't by itself guarantee accessibility or function.
2. Define a practical support matrix and test it — representative browser, OS and device combinations, with responsive layouts rather than fixed widths. Then test what browser choice alone misses: keyboard-only use, zoom and text resizing, a screen reader, slow connections, and blocked or failing resources.
3. Keep core tasks usable without JavaScript where practical — and where a task genuinely requires it, say so clearly and offer a recovery path or alternative contact route. Keep baseline content visible until an enhancement succeeds, so a failed script leaves a page, not a blank.
4. Use feature detection, not browser sniffing. Detect the specific capability you need (if ('IntersectionObserver' in window)), provide a fallback — and handle runtime failure too, because presence isn't proof the call succeeds.
5. Build in accessibility from the start: native HTML controls first, labels and text alternatives, keyboard operability with visible focus, zoom and reflow support, sufficient contrast — and ARIA only where native semantics fall short, implemented together with the keyboard behavior it promises.
6. Respect user preferences. Honor prefers-reduced-motion; if you offer alternate color schemes, treat prefers-color-scheme as the initial preference and test every scheme's readability and contrast.