feat(onboarding): panel signup wall variant

[tsahimatsliah]

Adds a panel background to the signup wall (FunnelStepType.HeroLanding): the form sits in a left column with the marketing landing page's hero artwork framed in the right one.

Selected by Freyja config via the step's background parameter — the default (cards) is untouched, so nothing changes until the parameter is set.

Layout

Desktop (laptop+) — two columns. Form left, artwork right in a rounded frame with an "ambilight": a blurred, over-saturated copy of the artwork behind the frame, so the panel casts its own colour onto the page. A glass QR card floats bottom-right of the frame.

Stacked (below laptop) — the artwork takes the top of the screen and dissolves into the page background; the form is bottom-anchored underneath, matching the spacing of the existing cards/desk walls. The footer links and disclaimer only exist in the two-column layout.

Compact phones — a second tier keyed on viewport height (max-height: 759px, bounded to below laptop), because height is the axis under pressure: a 375×812 phone gets the roomy treatment, a 375×667 one does not. The artwork drops 50dvh → 32dvh and the type/gaps tighten with it.

Notes for review

• The app-install card is a real link to https://r.daily.dev/get, daily.dev's smart link, so the destination is reachable by pointer and keyboard and not only by scanning. The QR is decorative (aria-hidden) and the link is named by its destination. Covered by LandingAppInstall.spec.tsx.
• The same smart link routes iPhone → App Store, Android → Google Play, desktop → extension. Because the URL is fixed, the QR is a static asset: the module matrix was generated once at error-correction level H and baked in as a single SVG path. Worth scanning on a real device before merge — that is the one thing not verifiable in CI.
• Fixes a pre-existing bug in OnboardingRegistrationForm: tertiarySignupButtonClass hardcoded !text-white on a button sitting on the page background, making its label invisible in light mode. Now !text-text-primary. This affects every onboarding signup surface, not just this variant.
• splitSignupStyle already existed and was fully plumbed but nothing switched it on. This variant enables it, which gives "Sign up with GitHub/Google" + "Create account". Its unused full-width "Sign in" button is removed in favour of the standard MemberAlready link.
• A few onb-* class hooks in heroStyles.ts are set from OnboardingRegistrationForm (onb-split-cta, onb-split-login). They are inert wherever the hero's CSS is not present; both ends are commented.

Known gaps

• className.onboardingSignup is dead across the auth stack: OnboardingRegistrationForm declares it and AuthOptionsInner forwards it, but the component never destructures className, so it has never applied for anyone passing it. Left alone here as out of scope.

Storybook

Components/Onboarding/Steps/FunnelHeroLanding → Panel, plus Components/Onboarding/Signup wall comparison, which renders the current Cards/Desk walls next to Panel in real iframes at Mobile / MobileSmall / Tablet / Desktop sizes. Iframes rather than scaled divs because breakpoints come from the viewport in both CSS and useViewSize.

🤖 Generated with Claude Code

Preview domain

https://claude-signup-wall-panel.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
daily-webapp	Ready	Preview	Jul 29, 2026 1:43pm
storybook	Building	Preview	Jul 29, 2026 1:43pm

[capJavert]

The panel variant still has an accessibility blocker before merge: the QR card is the only app-install destination, but the SVG is aria-hidden and there is no link a keyboard or screen-reader user can follow. Please add an accessible smart-link fallback (it can be visually hidden if needed) and cover it with a test. The real-device QR scan noted in the PR should also be completed before final approval.

[tsahimatsliah]

@capJavert good catch — fixed in ceff7d8.

The card is now an anchor to the same smart link (https://r.daily.dev/get) rather than a <div> wrapping a decorative SVG, so the destination is reachable by pointer and by keyboard, not only by scanning.

Two details worth calling out:

• The link is named by its destination, not by the visible copy. It carries aria-label="Get the daily.dev app for iOS or Android". "Scan to get the app" describes the QR, which is no use to anyone who cannot scan it, so it would have been a poor accessible name. The QR SVG stays aria-hidden.
• I made the whole card the link rather than adding a visually-hidden one. You said hidden was acceptable, but a sighted desktop user has the same problem — they can see a QR they cannot scan from the machine they are on. This way the card is clickable for them too, and there is one destination instead of two. It also picks up a focus-visible ring, so the focus target is visible.

Test coverage in LandingAppInstall.spec.tsx: one asserts the link exists with the right href and rel, one asserts the scan copy does not become the accessible name (guards against someone later dropping the aria-label and silently regressing it).

On the real-device scan: still outstanding and I can't do it from here. I've verified the encoding round-trips to an identical matrix and that the smart link resolves correctly per platform (iPhone UA → apps.apple.com, Android → play.google.com), but a camera against the rendered code with the logo badge over it needs a human. Worth doing before approval as you say — the badge is a solid dark block over the centre, which level H should absorb, but that's theory until someone points a phone at it.

Also rebased onto latest main since the branch had fallen behind.

[capJavert]

Reviewed by AI.

One blocking accessibility finding remains. CI is green, and I independently verified that the baked QR payload decodes to https://r.daily.dev/get.

[capJavert]

Blocking: the visible label is "Scan to get the app", but this aria-label replaces it with a name that does not contain that text. This fails WCAG 2.5.3 Label in Name and prevents voice-control users from activating the link using the wording they can see. Please include the visible label verbatim, for example aria-label="Scan to get the app — daily.dev for iOS or Android", and update the test that currently asserts /scan/i is absent.

Reviewed by AI.