Browser and device support.

Railmoor sells regional rail tickets from railmoor.example. Most of its visitors arrive on a phone or a laptop running a browser that updated itself last month. A smaller group arrives in person: at 212 stations there is a ticket kiosk, a portrait touchscreen with no mouse and no typing keyboard, only a tactile arrow keypad beside the screen. The kiosk vendor froze its software on a Chromium 128 build from August 2024 and will not ship another one before the contract renews. Those kiosks produce 3.4% of Railmoor's sessions and 14% of its tickets.

Without a policy, every compatibility bug turns into an argument. Does the seat map have to animate on the kiosk? Must the site work in a browser from 2019? Is a layout glitch on a tablet in landscape a release blocker? A support policy settles these questions once. It names tiers: the browsers where everything must work and is tested on every change, the ones where the core task must work but extras may be missing, and the ones Railmoor promises nothing about. The tiers come from Railmoor's own traffic and from what each group is worth to the business, not from a list copied from another company.

The engineering half is how one codebase honours those tiers without forking. Railmoor starts every page from HTML that works on its own, asks the browser whether it has a capability before using it, and adds the richer version only where the answer is yes. The kiosk then gets the same site as everyone else, minus the few pieces its engine cannot do, plus a fallback wherever the missing piece matters.

Start from the server's access logs, not only from the analytics script. A browser the site breaks in may never run that script, so analytics under-counts exactly the users you are failing. Group requests by engine and major version, and put devices with fixed software (kiosks, TVs, in-app web views, company-managed laptops) in rows of their own, since they will not update on your schedule.

Then draw the lines. The full tier is what you test on every change: current evergreen browsers plus any group whose business value earns a place. The functional tier is where the core task (search, choose, pay) must work but extras may be missing. The unsupported tier gets no testing and no promises, which is different from being blocked: a page built in layers usually still works there, and a "browser not supported" wall turns an accidental success into a certain failure. Write the policy down, give it an owner, and revisit it every quarter, because the browsers move even when your code does not.

Checking every feature against every browser table is slow, and teams used to argue about what "supported" meant. Baseline is the web platform's shared answer. It watches a core set of browsers: Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. A feature is newly available once the current version of every one of them supports it, and it is labelled with that year (Baseline 2025). Thirty months later it becomes widely available, meaning most sites can use it without a fallback. Before either milestone it has limited availability.

Baseline describes browsers, not your users. Railmoor's kiosks do not care what the latest Safari supports; they care what Chromium 128 supports. So Baseline is the default line for the full tier, and any row with a pinned engine gets checked by hand against the features you plan to use.

Progressive enhancement builds upwards. The first layer is HTML that completes the task by itself: Railmoor's timetable search is a form that sends a GET to /timetable and gets a page of results back. CSS makes it look right, and a script, if it runs and if the browser passes its checks, turns the form into an in-place search with a station combobox and a calendar. Each layer is optional to the one below it.

Graceful degradation starts from the finished experience and patches it downwards: build for the newest browsers, then find what breaks elsewhere and add workarounds. It can reach a similar result, but the core task only works in older browsers if someone remembered to test there. Both have a place. Enhancement suits pages whose core is a form, a list or a document; degradation is honest for things with no simpler form, like a live seat map drawn on a canvas, where the fallback is a plain list of free seats rather than a lesser seat map.

Detection handles features at run time; the build handles them before shipping. One file, .browserslistrc, lists the browsers the full tier covers, and every tool reads it: Babel's preset-env rewrites newer syntax and, with useBuiltIns set to usage, adds core-js imports only in files that use an API the targets lack; Autoprefixer adds the CSS prefixes those targets still need; eslint-plugin-compat flags calls to APIs they do not have. Change the policy and every tool follows.

Three different gaps need three different answers. Syntax (optional chaining, class fields) can be transpiled. A missing API (Intl.DurationFormat) can often be polyfilled with script. Platform behaviour (a styleable select, the top layer, a new media feature) usually cannot be recreated at all, so it needs a fallback or nothing. The old trick of shipping two bundles, a modern one with type="module" and a legacy one with nomodule, belongs to the era when a large share of traffic could not run modules; every browser in a current full tier can, so one modern bundle plus targeted fallbacks is simpler.

Screen size says nothing reliable about input. A laptop can have a touchscreen, a tablet can have a keyboard and trackpad, and the kiosk is a large screen whose only pointer is a finger. CSS media features describe the input directly. pointer tells you how precise the primary pointing device is (fine for a mouse, coarse for a finger, none), and hover tells you whether it can hover conveniently. any-pointer and any-hover ask the same about every input attached, which is how you notice the stylus on a touch laptop. In script, pointer events report pointerType as mouse, pen or touch per event, so one handler can serve all three.

The rule that follows: hover may add a hint, but it must never be the only way to reach an action. Anything revealed on hover also needs to appear on keyboard focus, and on a device with hover: none it should simply be visible. Tooltips shown on hover or focus have their own WCAG 2.2 rule (1.4.13): they must be dismissible, stay up while the pointer moves onto them, and stay visible until the pointer or focus leaves, the user dismisses them, or they stop being relevant. Target size and zoom are covered with the other perceivable-UI requirements in Announcing changes and respecting preferences.

The audit held two surprises. The features the team feared most (the modal dialog and :has()) were already in the kiosk's engine; Baseline dates track the slowest core browser, and Chromium had often shipped years earlier. The features that were actually missing were small and recent, and each had a cheap answer: a few lines of script, one lazily loaded polyfill, and one styling rule that simply does not apply.