Footer

R1 — Anatomy

A <footer> (the page's contentinfo landmark) with, top to bottom:

• Link column groups — one or more labelled columns, each a heading + a list of links (Docs / API / product areas / institutional). Laid on the column grid (column-grid.kmd).
• Social row (optional) — a row of icon links to external presences, each with an accessible name.
• Legal / institutional line — copyright (© <year> Koder. All rights reserved.), legal links (privacy, terms), and, for an institutional/gov surface, the org signature.
• Brand signature (optional) — the wordmark/logo, linking home.

Separated from the page by border-top: 1px solid var(--border); padded (landing default 40px 24px, scaling with the window-size class).

R2 — Variants

R3 — Responsive collapse

The link columns follow the window-size classes (window-size-classes.kmd): full side-by-side columns on Expanded+, and on Compact they stack — or, for a dense footer, collapse into accordions (one expandable section per column heading). The legal line stays visible (not collapsed) at every width.

R4 — Accessibility

• The root is a <footer> → the contentinfo landmark (one per page).
• Each link column is a labelled group — its heading is a real heading, and a navigational column MAY be a <nav> with an aria-label.
• Social/icon links carry an accessible name (not just an icon).
• Collapsed accordions (R3) expose expanded/collapsed state to AT and are keyboard-operable (Enter/Space on the heading).

R5 — Content rules (defer to the landing specs)

What goes in a landing footer — and what MUST NOT — is owned by the landing-pages specs, not this component. In particular: a public landing footer never links the source repository / Koder Flow / any code host (products.kmd privacy rule). This component fixes the STRUCTURE; the landing spec fixes the CONTENT.

R6 — gov.br parity

Satisfies the gov.br footer (govbr-ds-parity): collapsible link columns + social + legal/institutional. The KDS institutional landing footer is the parity surface.

Não-escopo / follow-up

• Adoption — upgrading the existing simple landing footer (products.kmd §7) and the app layouts onto this component's multi-column/collapsible structure is an incremental sweep (stack#448, opened). The doc-site footer already exists.
• Theme toggle / language toggle that sometimes sit near the footer — those are their own components (themes/light-dark.kmd, i18n/contract.kmd), not footer structure.

Requirements (testable)

Requirement: Footer anatomy and contentinfo landmark {#req-footer-anatomy}

The footer SHALL render as a single <footer> element exposing the contentinfo landmark, containing at minimum one or more labelled link column groups, and it SHALL be visually separated from the page content by a top border (border-top: 1px solid var(--border)).

Scenario: Footer exposes one contentinfo landmark

• GIVEN a page that renders the footer component
• WHEN the accessibility tree is inspected
• THEN exactly one contentinfo landmark is present on the page
• AND that landmark is the root <footer> element

Scenario: Footer is separated by a top border

• GIVEN a footer rendered at the landing default padding
• WHEN its computed style is measured
• THEN border-top resolves to 1px solid var(--border)
• AND the footer contains at least one labelled link column group

Requirement: Variant shapes {#req-footer-variants}

The footer SHALL support three variants — landing, app, and doc-site — where the landing variant SHALL present multi-column link groups (with optional social, legal, and brand rows), and the app variant SHALL present a compact legal line plus version and a short link set with NO marketing columns.

Scenario: Landing variant renders rich multi-column form

• GIVEN the footer is rendered with variant landing in its institutional (multi-column) form
• WHEN the footer is inspected
• THEN more than one labelled link column group is present
• AND a legal/institutional line is present

Scenario: App variant omits marketing columns

• GIVEN the footer is rendered with variant app
• WHEN the footer is inspected
• THEN a legal line and a version string are present
• AND no marketing link column groups are rendered

Requirement: Responsive collapse of link columns {#req-footer-responsive-collapse}

On Compact window-size widths the footer SHALL collapse its link columns into a stacked layout or, for a dense footer, into accordions (one expandable section per column heading), while the legal line SHALL remain visible and uncollapsed at every width.

Scenario: Columns stack on Compact width

• GIVEN a landing footer with multiple link columns laid side-by-side at Expanded width
• WHEN the viewport is resized to a Compact window-size class
• THEN the link columns are stacked vertically rather than laid side-by-side
• AND the legal line remains visible and is not collapsed

Scenario: Legal line stays visible at every width

• GIVEN a dense footer whose columns collapse into accordions on Compact
• WHEN the viewport is at a Compact window-size class with all accordions collapsed
• THEN the legal line is still rendered and visible

Requirement: Accessibility of groups, icon links, and accordions {#req-footer-a11y}

Each link column SHALL be a labelled group whose heading is a real heading element, every social/icon link SHALL carry an accessible name rather than an icon alone, and any collapsed accordion (R3) SHALL expose its expanded/collapsed state to assistive technology and be operable via Enter and Space on the heading.

Scenario: Icon links carry an accessible name

• GIVEN a footer with a social row of icon links
• WHEN each social link's accessible name is computed
• THEN every social link has a non-empty accessible name
• AND the name is not derived solely from the icon glyph

Scenario: Accordion heading toggles state via keyboard

• GIVEN a Compact-width footer whose columns are accordions and one accordion is collapsed
• WHEN the accordion heading is focused and the Enter or Space key is pressed
• THEN the accordion expands and its expanded/collapsed state (e.g. aria-expanded) updates to reflect the new state

Requirement: Landing footer never links a code host {#req-footer-no-code-host}

A public landing footer SHALL NOT link the source repository, Koder Flow, or any code host, deferring all landing content rules to the landing-pages specs while this component fixes only the structure.

Scenario: No code-host link in a public landing footer

• GIVEN a footer rendered with variant landing on a public landing page
• WHEN every link href in the footer is enumerated
• THEN no link points to Koder Flow, the source repository, or any code host