Notification Preferences — Channel Toggle Matrix UI

Every app with notifications eventually needs a preferences screen where users control *what* they're notified about and *how* — a grid of event types crossed with delivery channels (email, push, SMS). Done as a clear matrix, it lets people opt out of noise without turning everything off, which keeps the important notifications welcome. This snippet builds that preference matrix in plain HTML, CSS, and vanilla JavaScript: per-event toggles for each channel, a save gate that activates only when something changes, and accessible switch semantics.

A matrix, not a flat list

The layout is a grid: each row is an event type (Mentions, Comments, Security alerts, Billing…), and three columns are the delivery channels (Email, Push, SMS), each cell a toggle. This matrix is far clearer than a flat list of "Email me about X" checkboxes, because it lets the user see and set the whole picture at once — "I want security alerts on every channel but product updates on none" is two glances and a few taps. The column headers carry channel icons so the grid reads quickly even on a narrow screen.

Dirty-state save gate

The Save button stays disabled until the user actually changes something, and a status line reflects the state: "All changes saved" → "Unsaved changes" (amber) the moment a toggle differs from the saved snapshot → "✓ Saved" (green) after saving. This is implemented by comparing a JSON snapshot of the current preferences against the last-saved snapshot, so the dirty check is exact — toggling something and toggling it back correctly returns to "saved" with the button disabled again. This honest dirty-tracking is what prevents both pointless empty saves and the anxiety of not knowing whether your changes took.

Accessible toggle switches

Each toggle is a real <button> with role="switch" and aria-checked reflecting its state, plus an aria-label naming both the event and the channel ("Security alerts via SMS") — so a screen reader announces exactly what each of the eighteen toggles controls, which a grid of unlabeled switches completely fails to convey. The switch is styled as the familiar sliding pill (track + thumb) with a transform-animated thumb, so it's visually obvious and GPU-cheap.

Data-driven and snapshot-saved

The whole matrix renders from an EVENTS array, each event carrying a prefs object of channel → boolean. Adding an event type or a channel is a data edit. On save, the current preferences are captured as the new saved snapshot (and in a real app, sent to your backend) — the FAQs cover wiring that persistence. Because state lives in the data and the UI is its projection, the toggles, the dirty check, and the save all stay consistent automatically.

Sensible defaults matter

The starting preferences model good defaults — security and billing default to more channels (you want those), while product updates default to off (opt-in marketing) — because the defaults are what most users keep. A well-designed preferences screen still starts from defaults that respect attention: critical notifications on, promotional ones off, so the user only adjusts the exceptions. Swap the EVENTS and CHANNELS for your app's real notification types and delivery methods and it's ready.