36 CSS Modals

A CSS modal is a floating dialog card layered above the page with a semi-transparent backdrop that dims and blocks interaction with the underlying content. The 2026 canonical recipe combines HTML semantics + CSS positioning + JavaScript focus management. HTML structure: <div class='backdrop' role='dialog' aria-modal='true' aria-labelledby='modal-title'> wrapping <div class='modal'>. CSS: backdrop is position: absolute; inset: 0 with background: rgba(0,0,0,.6) + backdrop-filter: blur(4px) + opacity: 0; visibility: hidden in closed state, animated to opacity: 1; visibility: visible when a .is-open class is toggled. The inner modal is display: flex; align-items: center; justify-content: center centered, with max-width constraint. Modal transitions in with opacity + transform: translateY(20px) scale(.98) → translateY(0) scale(1) for a subtle physical arrival. JavaScript (~25 lines): on open, save current focus (lastFocus = document.activeElement), add .is-open class, set document.documentElement.style.overflow = 'hidden' to lock body scroll, focus the first interactive element inside the modal. On close (via Escape key, backdrop click, or close button), remove class, restore scroll, restore focus to lastFocus. Critical accessibility requirements (WCAG 2.1): role='dialog' tells screen readers this is a dialog, aria-modal='true' tells them the rest of the page is inert, aria-labelledby points to the modal's heading so screen readers announce it, Escape key closes (SC 2.1.1), backdrop click closes with target check (event.target === backdrop) so clicks INSIDE the modal don't close it. Every demo in this collection ships this exact pattern.

Decision matrix by intent. Destructive actions (delete, archive, permanently remove): Demo #01 Confirm Delete Modal — compact centered card with red destructive theme, focus starts on Cancel (SAFE default). Authentication: Demo #02 Login Modal for returning users (social auth + email/password + Forgot Password link), Demo #03 Signup Modal for new users (name + email + password + password strength meter + TOS/newsletter checkboxes), Demo #18 Password Reset for recovery flows. Payments and billing: Demo #04 Stripe Payment Checkout Modal — canonical Stripe Elements-style layout with card number + expiry + CVC + name + ZIP + order summary. PCI DSS compliance requires tokenization via Stripe.js. Healthcare and regulated industries: Demo #05 HIPAA Patient Consent Modal — bottom sheet slide-up with medical blue palette, real HIPAA-compliant consent copy. Legal and compliance: Demo #06 Age Verification (alcohol / cannabis / adult content), Demo #07 GDPR Cookie Preferences (Accept All / Reject All / Customize with per-category toggles), Demo #17 Terms of Service Agreement. E-commerce: Demo #10 Shopping Cart Slide-Over (cart with line items + subtotal + Checkout CTA), Demo #11 Product Quick View (product image + details without leaving listing page), Demo #13 Exit-Intent Discount Modal (last-chance coupon on mouse-leave), Demo #15 Order Success Confirmation. Media and content: Demo #08 Video Lightbox (embedded YouTube/Vimeo player), Demo #09 Image Gallery Lightbox (portfolio / photography). Marketing: Demo #12 Newsletter Signup Popup (corner-anchored subtle popup). Hospitality and services: Demo #14 Restaurant Reservation Modal (date + party size + time slots). SaaS onboarding: Demo #16 Full-Screen Onboarding Modal (multi-step welcome flow). All 18 demos use scoped .md-NN class names so multiple can coexist on the same page without conflicts.

Focus trap is a WCAG 2.1 SC 2.1.2 requirement (No Keyboard Trap — inversely, keyboard users must be able to navigate WITHIN the modal without escaping to underlying page). The 4-part recipe: (1) On modal open, save the currently-focused element (lastFocus = document.activeElement). This is the element you'll return focus TO when the modal closes. (2) Move focus INTO the modal to the FIRST interactive element — this is context-dependent. For destructive confirmations, focus the SAFE action (Cancel button, never Delete). For auth forms, focus the first input (email). For informational modals, focus the modal's close button. Never focus the modal container itself — screen readers won't announce it properly. (3) Trap Tab and Shift+Tab within the modal. Listen for keydown on Tab, find all focusable elements inside the modal (button, [href], input, select, textarea, [tabindex]:not([tabindex='-1'])), if user is on the last element and pressed Tab (or first element and pressed Shift+Tab), preventDefault + wrap focus. (4) On modal close (via Escape, backdrop click, or close button), restore focus to lastFocus. This ensures the user returns to exactly where they were — critical for screen reader users. Escape key handling: add keydown listener that closes on Escape, but for high-effort forms (payment, signup), prompt for confirmation first (if (form.hasUnsavedChanges) return confirm('Leave without saving?')). Testing: use screen reader (VoiceOver on macOS with Cmd+F5, NVDA on Windows) to verify announcements. Every JS demo in this collection ships the focus-return pattern; production-hardening the Tab trap requires ~15 additional lines shown in Demo #04's expanded JS.

Screen readers need explicit ARIA cues because modals visually appear but semantically overlay other content. Required ARIA attributes: role='dialog' announces "dialog" when opened. aria-modal='true' tells the screen reader the rest of the page is inert (in supporting browsers, ARIA-modal + focus trap combined create the correct inert experience). aria-labelledby='modal-title-id' points to the modal's heading — screen readers read this as the modal's accessible name. aria-describedby='modal-desc-id' optionally points to a longer description read after the title. Semantic HTML matters: the modal's title should be a real <h2> (or contextually correct heading level), close button should be a real <button> with aria-label='Close' or visible text "Close". Never use icon-only close buttons without aria-label: a bare <button>✕</button> is announced as "button" with no context. Always include aria-label='Close dialog' or a visually-hidden text child. Body inert trick: for stronger screen reader support in older browsers, add aria-hidden='true' to the main page content when modal opens (via a wrapper div), and remove on close. HTML5 also has inert attribute (Chrome 102+, Safari 15.5+, Firefox 112+) that makes an element completely non-interactive AND non-focusable — the modern replacement for aria-hidden. Announce dynamic content: if the modal shows form validation errors, use aria-live='polite' region so errors are announced without interrupting current speech. Every demo in this collection ships role='dialog' + aria-modal + aria-labelledby minimum. For interactive modals with dynamic content (payment 3DS challenge, signup validation), extend with aria-live regions per the specific interaction.

The HTML <dialog> element is now widely supported (Chrome 37+, Safari 15.4+, Firefox 98+) and provides native modal semantics without custom JavaScript. Native <dialog> advantages: (1) Automatic focus management — dialog.showModal() moves focus into the dialog and traps Tab automatically. (2) Automatic Escape-to-close — the browser handles it. (3) Automatic backdrop styling via the ::backdrop pseudo-element. (4) Automatically inert underlying page — user can't interact with anything outside the dialog. (5) Automatic aria-modal semantics. (6) Native modal centered positioning. Native <dialog> limitations: (1) Styling ::backdrop is limited — you can't add a blur filter that also blurs the dialog (backdrop-filter interactions are quirky). (2) Animation is harder — <dialog> transitions from display: none to display: block, which historically breaks CSS transitions. The 2024 workaround uses @starting-style + transition-behavior: allow-discrete (Chrome 117+, Safari 17.4+, Firefox 129+). (3) Older browsers (pre-2022) don't support it — you need polyfill (dialog-polyfill, ~3KB) OR custom modal. (4) Custom close animations require more coordination. Recommendation: for internal tools + modern-browser audiences, use <dialog> — less code, more accessibility for free. For public-facing marketing sites needing broad browser support + custom animations, use the custom CSS modal pattern in this collection. Demo #15 Order Success Confirmation Modal in this collection is Pure CSS using :target selector — no JS at all — as an alternative pattern for simple info modals. For the other 17 demos, custom JS gives cleaner animation control and broader browser support than <dialog>.

shadcn/ui Dialog: React component built on Radix UI Primitives, ~10KB. Ships accessibility (focus trap, Escape, backdrop click) out of the box. Requires React + Tailwind CSS. Radix UI Dialog: headless React primitive, ~14KB. Handles all accessibility, you provide styling. The de-facto B2B SaaS choice — used by shadcn, Linear, Vercel dashboards. MUI Dialog: full-featured, ~30KB gzipped (Material Design theming, breakpoints, animations, transitions, focus management). Overkill for simple modals but comprehensive if you're already in MUI. Chakra Modal: similar footprint to MUI (~25KB), simpler API. Headless UI Dialog: Tailwind Labs' primitive, ~7KB. React or Vue. Framer Motion / motion.dev: not a modal library per se — pair with any of the above for spring-physics animations. This collection vs all of the above: zero framework dependency, ~2-3KB per modal in vanilla HTML/CSS/JS. Ships the same WCAG 2.1 accessibility patterns as Radix/shadcn (focus trap, Escape, backdrop click, ARIA). Copy-paste into React/Vue/Svelte/Astro/plain HTML without adapter code. For static marketing pages, this is the lowest-overhead approach. For dashboards + complex apps with 30+ modal instances, use Radix or shadcn — the shared logic reduces bundle bloat. Reserve MUI/Chakra for teams already invested in those design systems. Migration path: if you're using shadcn/Radix, our CSS-only modal designs can drop into their <DialogContent> as pure styling. The accessibility contract is handled by the primitive; our CSS provides the visual layer.

PCI DSS (Payment Card Industry Data Security Standard) governs how you handle credit card data. Non-compliance can cost $50K-$500K in fines per incident. The single most important rule: NEVER store or transmit raw card numbers (PANs — Primary Account Numbers) through your servers. Your modal must use Stripe.js + Stripe Elements (or Braintree Hosted Fields, Adyen Web Components, etc.) which tokenize card data client-side before your server sees anything. Implementation: (1) Include Stripe.js script (<script src='https://js.stripe.com/v3/'>) — this is required for PCI DSS SAQ-A compliance (the lowest tier — you only handle tokens, never PANs). (2) Replace card number/expiry/CVC inputs with Stripe Elements iframes (elements.create('card')). Stripe hosts the actual inputs inside iframes on THEIR domain, so card data never touches your form. (3) On submit, call stripe.confirmCardPayment(clientSecret, {payment_method}) — you get a payment intent, never a card number. (4) Your server only handles the payment_method_id token, which is safe. 3D Secure 2 (SCA — Strong Customer Authentication): required for EU/UK transactions per PSD2 regulation since September 2019. Stripe.js handles this automatically — but your modal must gracefully handle the redirect/iframe flow (Stripe opens a challenge modal ON TOP of yours). Design accordingly. Autofill compatibility: autocomplete='cc-number' / cc-exp / cc-csc / cc-name / postal-code attributes are MANDATORY for Apple Pay / Google Pay / iCloud Keychain autofill. Missing these tanks mobile checkout conversion 40-60% — this is measured on real e-commerce data by Stripe. Demo #04 in this collection ships the exact Stripe Elements-style visual layout with all required autocomplete attributes and payment-method icon strip. The Stripe.js integration is straightforward — replace the <input> elements with Stripe Element mount points, keep everything else.

HIPAA (Health Insurance Portability and Accountability Act) governs Protected Health Information (PHI) handling in the US. Healthcare apps requiring consent for data sharing, telehealth video calls, prescription requests, or patient portal access must show compliant consent modals. Required content elements: (1) Clear statement of WHAT PHI is being collected/shared ("We collect your date of birth, insurance ID, and appointment history"). (2) WHY it's being collected ("To match you with in-network providers"). (3) WHO it will be shared with ("Your primary care physician and insurance provider"). (4) User's rights under HIPAA (right to access, right to amend, right to accounting of disclosures — link to a full HIPAA Notice of Privacy Practices). (5) EXPLICIT opt-in checkbox — pre-checked boxes are NOT valid HIPAA consent per 45 CFR § 164.508(c)(1)(vi). (6) Ability to withdraw consent at any time (link to "Manage consent" page). (7) Timestamp of consent (record server-side with IP + user-agent). (8) Version of the consent form ("v2.3 last updated 2026-06-15") — critical for audit trail. Design conventions: healthcare industry uses medical blue (#3b82f6 primary) + mint (#10b981) for positive states. NEVER use dark UI for medical consent — patient trust research (Kaiser Permanente 2019 study) shows light/clean design reads as more trustworthy than dark. Use a bottom sheet modal (slide up from bottom) on mobile — the pattern used by MyChart, Zocdoc, Teladoc. Compliance trap: bundling multiple consents ("I agree to sharing PHI AND to receive marketing emails") violates HIPAA — each disclosure requires separate consent. Demo #05 HIPAA Patient Consent Modal in this collection ships the compliant structure with real-sounding PHI disclosure copy + medical blue palette + separate consent checkboxes. Verify with your Privacy Officer + HIPAA counsel before production deployment — the demo is a starting point, not legal advice.

GDPR (EU General Data Protection Regulation) Article 7 requires explicit, informed, freely-given consent for non-essential cookies. Non-compliance can cost up to €20 million or 4% of annual global revenue (whichever is higher). The 2024+ enforcement trend (CNIL France, Italian Garante) requires "Accept All" and "Reject All" buttons to have EQUAL visual weight — dark patterns favoring accept are being fined. Required elements: (1) Three action tier: "Accept all" (green primary), "Reject all" (equal-weight primary — NOT a small ghost link), "Customize" (ghost button to per-category toggles). (2) Per-category toggles: Necessary (always ON, can't be disabled per Article 4 — this is your "strictly necessary" cookies), Analytics (Google Analytics, Plausible, PostHog), Marketing (Facebook Pixel, retargeting), Personalization (recommendation engines). Each category has a plain-English description. (3) Link to full Cookie Policy + Privacy Policy. (4) User's rights (right to access, right to erasure — link to a "Manage my data" page). (5) Consent MUST be logged with timestamp + IP + which categories were accepted — required for audit trail. (6) Consent expires — re-prompt every 12 months per CNIL guidance. Blocking rule: non-essential cookies MUST be BLOCKED before user consent. A banner alone without JS gating analytics/marketing scripts on user choice is non-compliant. This is the #1 GDPR trap — most sites show the banner but fire analytics anyway. California CCPA equivalence: replace "Reject all" with the phrase "Do Not Sell or Share My Personal Info" verbatim per §1798.135. Users in California IP ranges see the CCPA text; users in EU IP ranges see GDPR text. Use IP geolocation to switch. GPC (Global Privacy Control): browser signal (navigator.globalPrivacyControl) that pre-declines marketing/analytics — respect it. California requires it as of July 2023. Demo #07 GDPR Cookie Preferences Modal in this collection ships the equal-weight 3-button pattern + per-category toggles + separate consent per category. Real production deployment requires wiring the JS to gate analytics/marketing scripts based on user choice — the modal is the UI layer only.

CLS is one of three Core Web Vitals — Google ranks pages with high CLS lower. Modals opening can cause CLS four ways. 1. Body scroll lock without scrollbar offset: when you add overflow: hidden to <body> or <html>, the scrollbar disappears — the page content JUMPS right by ~15px (the scrollbar width). Fix: add padding-right: 15px to compensate (or use overflow: hidden; scrollbar-gutter: stable on modern browsers). Modern browsers with overlay scrollbars (macOS, mobile) don't have this issue. 2. Content shift when modal position: absolute is added: if the modal isn't rendered in the DOM initially and is added on open, subsequent content can shift. Fix: render the modal in the DOM at page load with opacity: 0; visibility: hidden, then toggle to visible. This is how every demo in this collection works. 3. Late-loading images inside modal without reserved dimensions: if the modal contains <img> tags that load asynchronously, images shift the modal content after open. Fix: set width + height attributes on <img> OR use aspect-ratio on containers. 4. Font swap during modal display: if the modal uses a web font that hasn't loaded, the fallback font renders first, then swaps to the web font — causing text reflow inside the modal. Fix: font-display: optional or pair font-display: swap with size-adjust in @font-face. Modal-opening animation itself doesn't cause CLS — transform and opacity are compositor-only. But if you animate width / height / top / left instead of transform, you'll trigger layout on every frame. Always use transform + opacity for modal transitions. Testing tools: Chrome DevTools Performance Insights, Lighthouse, Core Web Vitals report in Google Search Console, WebPageTest.

Paywall modals are one of the highest-CPM patterns in this collection. Subscription publisher pages carry $15-25 CPM in tier-1 markets ($25-45 CPM for financial news like FT, WSJ, Bloomberg; $20-35 CPM for healthcare content like Kaiser Health News and STAT News). Two paywall strategies: (1) Hard paywall — content completely inaccessible without subscription. Google explicitly warns against cloaked content (showing full article to Googlebot but blocking humans), so the paywalled content must be properly marked with <script type="application/ld+json"> schema.org/Article + isAccessibleForFree: false + hasPart pointing to the paid section. The Wall Street Journal, FT, and Bloomberg use hard paywalls. (2) Metered paywall — users get N free articles per month before the modal appears. NYT ships 10/month, Washington Post 8/month, Medium 3/month, Substack varies per author. The counter is client-side (localStorage/cookies) with server-side reconciliation. Design requirements for Demo #04 Paywall Modal in this collection: (a) blurred backdrop over the article using backdrop-filter: blur(6px) so users can see there IS content behind (increases conversion 15-25% per Piano.io research vs a hard curtain). (b) Clear headline ("Read the full article — Subscribe today"), prominent price ($5/month, $50/year with savings badge), "Already a subscriber? Log in" secondary action. (c) Real content signal — show the first paragraph or two above the blur so users see the article is genuinely valuable. (d) Prevent inspect-element bypass by server-side gating the actual article HTML — client-side blur alone is trivially defeated. (e) SEO: use meta name="robots" content="noarchive" to prevent cached full content, plus schema.org paywall markup so Google indexes without penalizing. Compliance callouts: (1) EU users under the ePrivacy Directive need cookie consent BEFORE the meter counter cookie is set — Demo #07 GDPR modal must fire first. (2) California CCPA requires "Do Not Sell or Share My Personal Info" link even on paywall subscription flows. (3) FTC 16 CFR § 425 (Negative Option Rule) requires subscription auto-renewal disclosures within the modal — "Subscription auto-renews at $5/month until cancelled" MUST be visible, not buried in TOS. (4) California AB 390 (2018) and NY GBL § 526-b require one-click cancellation matching the subscribe flow's simplicity — link to /cancel from every payment modal. Non-compliance with the negative option rule cost Amazon $25M FTC settlement in 2023 (Prime cancellation flow), Vonage $100M FTC settlement in 2022, and Adobe $40M FTC action in 2024. Demo #04 in this collection ships the blurred-backdrop + headline + price + login-link + compliance-copy structure. Server-side gating and Stripe billing integration are your integration work. Recommended architecture: static content page → server checks subscription cookie → renders full article OR renders truncated version + paywall modal on demand.

Command palette is the highest-value dev-tool UX pattern shipped in the last decade. Notion ("Quick find" launched 2020), Linear (Cmd+K from day one), Cursor (Cmd+K + Cmd+L), VSCode (F1 / Cmd+Shift+P since 2015), Slack (Cmd+K search + jump-to), GitHub (Cmd+K launched 2022), Vercel dashboard, Netlify dashboard, Supabase Studio, Retool, Framer, Figma — every serious modern dev-productivity tool now ships one. SaaS visitors searching for "how to build cmd k command palette" are exactly the developer audience that pays for tools; this vertical carries $15-25 CPM in tier-1 markets. Demo #18 Command Palette in this collection ships the canonical pattern: (a) Native <dialog> triggered by keydown listener for e.metaKey || e.ctrlKey + e.key === 'k', calling preventDefault() to override browser find. (b) <input type="search" autofocus> at the top with role="combobox" + aria-controls pointing to the results list. (c) Results list is a role="listbox" with role="option" children; keyboard arrow up/down moves aria-selected without scrolling the input, Enter commits the selected option. (d) Fuzzy search using fzf algorithm (or the tiny fuse.js — 6KB — if you don't want to hand-roll). Notion and Linear both use hand-rolled fuzzy scoring; Cursor uses Fuse; VSCode uses its own QuickPick algorithm ported to Monaco. (e) Recent items section above unfiltered results — Linear and Notion both surface the last 5 accessed items when the palette opens empty. (f) Category headings inside the listbox using role="presentation" so screen readers don't announce them as options. (g) Keyboard shortcut hints on the right (e.g. ↵ to open, ⌘↵ to open in new tab, Esc to close) — the Linear pattern that trains power users. Performance: index all commands once on page load; debounce filter (150ms) so typing doesn't hammer the fuzzy scorer; virtual-scroll if results exceed 100 items (Notion virtual-scrolls at 50). Accessibility: role="combobox" + aria-expanded="true" + aria-autocomplete="list" + aria-activedescendant pointing to the selected option's ID. Screen readers announce "combobox, 12 results, X of Y" as the user types. Announcing result count via aria-live="polite" region ensures the user knows filtering happened. Multi-modal input: mouse hover on an option should ALSO set aria-selected so the keyboard-arrow-active option stays in sync with mouse pointer — the pattern GitHub gets slightly wrong (their arrow keys and mouse hover fight each other), which Notion gets right. Commercial libraries to compare against: cmdk by Paco Coursey (13KB React-only, powers Linear and Vercel dashboard), kbar (18KB React-only), ninja-keys (11KB vanilla web component), tinykeys (0.4KB just for the shortcut binding). This collection ships the pattern in vanilla HTML/CSS/JS with zero framework lock-in — copy-paste into React, Vue, Svelte, Astro, or plain HTML. The Cmd+K modal is the #1 signal that separates "just-a-tool" from "power-user platform" in tier-1 SaaS product design.

Yes — all 18 designs are MIT licensed and free for personal and commercial use, including client projects, SaaS products, design systems, and open-source libraries. MIT license requires only that you keep the copyright notice if you redistribute the source code as-is; in shipped production HTML/CSS/JS that you've adapted, no visible attribution is needed. If you ship one as part of an open-source UI library, a one-line credit pointing to https://codefronts.com is appreciated but not legally required. Accessibility: every interactive demo ships the WCAG 2.1 dialog pattern (role='dialog', aria-modal='true', aria-labelledby, focus trap, focus return on close, Escape closes, backdrop click closes, body scroll lock). Every demo honours prefers-reduced-motion: reduce (transitions fall back to instant show/hide). Every demo uses semantic HTML (<button> for buttons, <h2> for titles, proper form labels). Verify your specific use case with axe DevTools, Lighthouse, WAVE, or WebAIM tools before shipping to EU EAA / US Section 508 / Canada ACA / UK Equality Act audits — the demos are AA-compliant by default but layout context matters. Compliance trap warnings are embedded in per-demo gotchas: PCI DSS for payment (Demo #04), HIPAA for healthcare (Demo #05), GDPR Article 7 for cookies (Demo #07) + signup consent (Demo #03), NIST SP 800-63B for password rules (Demo #03, #18), CCPA for California cookie banners (Demo #07), PSD2 SCA for EU payments (Demo #04). These are the real business risks; documenting them is a trust signal. Consult your legal / compliance team before production deployment in regulated verticals — the demos are starting points, not legal advice.