CrystalFooter
Utility, reveal and minimal — with the reveal’s costs made visible
NN/g’s line is that a footer is “a cost-free addition to the user experience — it can help, but it can’t hurt”, with bloat the only stated exception. That is true of the utility footer, which is why it is the default. It is not true of the reveal, which carries two real costs. That asymmetry is the whole argument for the defaults here.
Variants
The reveal’s two costs — demonstrated, not asserted
1. A keyboard user can reach it while it is covered
It is in the DOM from first paint, so Tab can land focus on something invisible — WCAG 2.4.11 again, from a direction people do not expect. The component scrolls it into view on focus rather than leaving focus lost. Try it: click above the demo, then Tab until you reach the footer links.
2. Short pages have nothing to lift
If the content is shorter than the scrollport, the reveal never happens and reads as a mistake. Confirmation pages, 404s and thin legal pages are where this bites — and they are the pages nobody checks. The component measures for it and degrades to the flow layout. Toggle “short page” in the reveal demo to see it switch.
Every option, and its default
| Prop | Default | Which finding justifies it |
|---|---|---|
variant | 'utility' | NN/g’s “can’t hurt” applies to the utility footer and not to the reveal. |
columns | undefined | One level of links under one heading — NN/g caps footer site maps at a two-level hierarchy and names excessive hierarchy a top-four footer failure. |
legal | undefined | Utility links are recommended for all sites, so the legal row renders on every variant it is given to — including minimal. |
newsletter | false | A customer-engagement component in NN/g’s catalogue, but bloat is the one stated footer failure — so it is opt-in. |
revealHeight | 'content' | The covered region is exactly what a keyboard user can focus into unseen, so it should be as small as the content allows. |