SB Sommar – Project Documentation

Site structure: page inventory, the homepage pre-camp section, navigation, footer, hero CTAs, accordions, anchor IDs.

Part of the requirements index. Section IDs (02-§N.M) are stable and cited from code; they do not encode the file path.

2. Site Pages

The following pages must exist:

ID	Page	URL	Audience
`02-§2.1`	Homepage	`/`	Prospective families, participants
`02-§2.2`	Weekly schedule	`/schema.html`	Participants
`02-§2.4`	Today view	`/idag.html`	Participants
`02-§2.4a`	Display view	`/live.html`	Shared screens
`02-§2.5`	Add activity	`/lagg-till.html`	Participants
`02-§2.6`	Archive	`/arkiv.html`	Prospective families, returning participants
`02-§2.7`	RSS feed	`/schema.rss`	Anyone subscribing to the schedule
`02-§2.11`	Edit activity	`/redigera.html`	Participants who submitted the event
`02-§2.12`	iCal feed	`/schema.ics`	Anyone subscribing to the schedule
`02-§2.13`	Calendar tips	`/kalender.html`	Participants wanting to sync the schedule
`02-§2.14`	Admin activation	`/admin.html`	Administrators

The homepage, schedule pages, add-activity form, and archive share the same header and navigation. None require login.

The Today view (/idag.html) uses the standard site layout with header and navigation. The Display view (/live.html) has no header or navigation — it is a minimal, full-screen display intended for shared screens around the camp. Both show today’s activities; they differ only in presentation context.

3. Homepage — Pre-Camp Requirements

The homepage is for families who know nothing about the camp.

It must answer, in order:

What is SB Sommar, and who is it for?
Is this the right place for my child?
When and where does it take place?
How do I register, and what are the deadlines?
What does it cost, and what is included?
Where do we stay, and what do we eat?
What are the rules and what should we bring?
What do previous participants say about it?

It must also include a frequently asked questions section.

The homepage must feel complete and trustworthy even when no camp is currently active. When a camp is active or upcoming, the schedule and add-activity links are prominent. The upcoming-camps list renders each camp as a compact one-liner (icon, name, location, and dates on a single line) with no visual separators between items.

The registration section must link to the external booking site, where families complete the full sign-up form. The specific URL lives in the build code, not in this requirement.

The pricing and rules sections must document the cancellation refund tiers and the organiser’s right to refuse participation, matching the terms that bind participants at the point of registration.

Tone: Warm, calm, and clear. Written in Swedish. Not corporate. Not promotional. The goal is that a parent visiting for the first time leaves thinking: “I understand what this is. I know how it works. I feel comfortable taking the next step.”

11. Activity Order and Overlaps

Activities must always be displayed in chronological order (by date, then start time).
Overlapping activities are allowed (see §4.8).
The schedule must remain readable when multiple activities occur at the same time (see §4.8).

17. Simplicity

The site must:

Work well on mobile devices. Schedule viewing and event submission are frequently done from a phone during camp week.
Be readable on shared display screens (see Today view in §4).
Require no explanation to use. A first-time visitor should understand the schedule and the add-activity form without instructions.
Avoid complexity that does not serve a clear user need.

The purpose of the schedule is coordination, not administration.

A shared footer must appear at the bottom of every page. Its content is maintained in a single Markdown file so non-technical contributors can update it without touching any template or layout code.

Every page produced by the build must include a footer element at the bottom of <body>.
Footer content is maintained in source/content/footer.md.
The build reads footer.md, converts it to HTML using the same Markdown pipeline as other content pages, and injects the result into every page via the shared rendering layer.
There must be no duplicated footer markup in any template or render function — the Markdown file is the single source of truth.
If footer.md does not exist at build time, every page must still render successfully with an empty footer. The build must not crash or exit with an error.
Updating footer.md and running the build must change the footer on all pages without modifying any other file.

The site must have exactly one navigation component, appearing at the top of every page. There must be no secondary or duplicate navigation menus elsewhere on any page.

24.1 Structure

Every page must include the same navigation header.
The navigation must appear only once per page, in the header area, before any page content.
The index page must not have an additional section-navigation menu below the hero image.

24.2 Page links

The navigation must contain links to all main pages:

Hem (index.html)
Schema (schema.html)
Idag (idag.html)
Lägg till (lagg-till.html)
Arkiv (arkiv.html)

The link for the current page must be visually marked as active.

On desktop, the page links use the short labels listed above and are displayed in uppercase via CSS (text-transform: uppercase).

On mobile, the hamburger menu uses longer, more descriptive labels:

Hem
Lägrets schema
Dagens aktiviteter
Lägg till aktivitet
Lägerarkiv

24.3 Section links

The navigation must also include anchor links to the main sections of the index page.

Short nav labels are defined per section in sections.yaml via the nav: field.
Section links on non-index pages must point to index.html#id.

24.4 Mobile behaviour

On mobile (viewport narrower than 768 px), the navigation must be collapsed by default and toggled via a hamburger button.
The hamburger button must have an accessible label (aria-label).
The hamburger button must use aria-expanded to communicate state to assistive technologies.
The expanded menu must be closable by pressing Escape.
The expanded menu must be closable by clicking outside it.
The expanded menu must close automatically when the user clicks a navigation link inside it.

24.5 Desktop behaviour

On desktop (viewport 768 px and wider), the hamburger button must be hidden and all navigation links must be directly visible.

35. Location Accordions on Index Page

The Lokaler section on the index page must display each location from local.yaml as an individual accordion item. The section heading and introductory text remain visible; only the individual locations are collapsible.

35.1 Section heading

The “Lokaler” heading (## Lokaler in locations.md) must render as a regular heading, not wrapped in an accordion.
The introductory paragraph below the heading must remain visible (not inside any accordion).

35.2 Location accordions

Each location entry in local.yaml must render as a separate <details class="accordion"> element.
The location name must appear as the <summary> text.
The location information text must appear inside the accordion body.
Locations with one or more image_path values must render each image as an <img> inside the accordion body, below the information text.
Locations with empty information and empty image_path must still render as an accordion (summary only, empty body).
Accordions must appear in the same order as entries in local.yaml.

35.3 Build integration

The build must pass the full location data (not just names) to the index rendering pipeline.
The collapsible: true flag in sections.yaml must be removed for the lokaler section (individual location accordions replace it).

Motivation

The mobile hamburger menu has usability problems on long pages: it scrolls out of view so users cannot access navigation without scrolling back to the top, and its visual design (same cream background as the page) makes it hard to distinguish from surrounding content. These issues were identified through manual testing on mobile devices.

On mobile viewports (≤ 767 px), the navigation bar must remain visible at the top of the viewport when the user scrolls.
The sticky behaviour must also apply on desktop viewports so navigation is always reachable.

61.2 Hamburger button design requirements

The hamburger button must have a terracotta (var(--color-terracotta)) background with white icon bars so it is clearly visible against the page background.
The button must have rounded corners (var(--radius-md)) for a softer appearance.

The dropdown menu panel must use a terracotta background with white text.
Text colour must be var(--color-white) to meet WCAG AA contrast for large text (14 px bold qualifies as large text; contrast ratio ≥ 3:1).
The panel must have fully rounded corners (var(--radius-lg)) and horizontal inset margins so it appears as a floating card.
Page links (top section) and section links (bottom section) must be visually separated: page links at 15 px / 700 weight, section links at 12 px / uppercase / reduced opacity, with a visible divider.

Opening and closing the menu must use a smooth CSS transition (max-height, 250 ms) instead of an abrupt display toggle.

61.5 Accessibility requirements

Focus outlines on the hamburger button and menu links must remain visible against the terracotta background (white outline).
Existing keyboard and ARIA behaviour (Escape to close, aria-expanded, click-outside-to-close) must be preserved.

70. Main Landmark Element

Every HTML page must contain a <main> landmark element so that screen readers can let users skip past navigation directly to the page content. This addresses the PageSpeed Accessibility audit flag for missing <main> landmark.

70.1 Structural rules

Every page must have exactly one <main> element.
The <main> element must wrap all page content between the navigation and the footer (or end of content if there is no footer).
The <main> element must NOT contain <nav> or <footer> elements.

70.2 Constraints

Adding <main> must not change any visual styling — it is a semantic element only.
Only one <main> element is permitted per page (HTML spec requirement).

71. Hero Action Buttons

When a camp is active and within its editing period, three quick-access action buttons must appear directly below the hero image on the index page. The buttons provide fast navigation to the most-used pages during an active camp.

71.1 User requirements

A camp participant visiting the home page during an active editing period must see three action buttons immediately below the hero image.
The buttons must link to, in this order: Idag (idag.html), Schema (schema.html), and Lägg till (lagg-till.html).
The buttons must be visually prominent, using terracotta pill-shaped styling.

71.2 Visibility rules

The buttons must be rendered in the static HTML at build time with data attributes for the editing period dates.
A client-side script must show the buttons only when the current date falls within [opens_for_editing, end_date + 1 day].
Outside the editing period the button container must be hidden (hidden attribute).

71.3 Styling

Each button must use pill-shaped border-radius (border-radius: 999px), terracotta background, white text, bold weight.
The button row must be centred within the hero container and have appropriate spacing between buttons.
The buttons must be responsive: wrapping naturally on smaller screens.

71.4 Constraints

The buttons must only appear on the index page.
No new JavaScript files may be added — the script must be inline in index.html.
CSS must use existing design tokens from 07-DESIGN.md §7.

72. Close Past-Day Accordions on Schedule Page

On the schedule page (schema.html), day accordions for dates that have already passed should be collapsed by default, so that the visitor sees current and future days open and past days closed.

72.1 User requirements

When a participant opens the schedule page, day sections whose date is before the visitor’s current date must be collapsed (closed).
Day sections for today and future dates must remain open.
The visitor must still be able to manually open a closed past-day accordion by clicking it.

72.2 Implementation rules

The comparison must use the visitor’s local date (client-side), not the build date.
The script must run on page load and close past days by removing the open attribute from <details class="day"> elements whose id (ISO date) is before today.
The script must be inline in the schedule page — no new JS files may be added.

72.3 Constraints

All days must still be rendered with the open attribute at build time, so that the page is fully usable without JavaScript.
The script must not affect event-row <details> elements, only day-level <details class="day"> elements.

74.1 Site requirements

The navigation bar remains at the same vertical position whether the page is at the top or scrolled — no visible shift when sticky positioning activates.
The navigation bar appears at the same vertical position on every page load.
When a user clicks an anchor link in the navigation, the target section is visible below the navigation bar, not hidden behind it.
The navigation bar remains at the same horizontal position when navigating between pages, regardless of whether the page content requires a scrollbar.

Navigation labels follow the principle: short where space is limited, descriptive where there is room.

75.1 User requirements

A visitor on desktop sees short, uppercase navigation labels so the menu stays compact.
A visitor using the mobile hamburger menu sees longer, descriptive labels so every link is self-explanatory.
A visitor using hero quick-access buttons sees short labels in the order Idag, Schema, Lägg till.

75.2 Site requirements

The desktop navigation bar displays page links with short labels (Hem, Schema, Idag, Lägg till, Arkiv) rendered in uppercase via text-transform: uppercase.
The mobile hamburger menu displays page links with descriptive labels: Hem, Lägrets schema, Dagens aktiviteter, Lägg till aktivitet, Lägerarkiv.
The hero action buttons use short labels in this order: Idag, Schema, Lägg till.
The <h1> page title on schema.html is “Lägrets schema – {campName}”.
The <h1> page title on idag.html is “Dagens aktiviteter”.
The <title> element on schema.html is “Lägrets schema – {campName}”.
The <title> element on idag.html is “Dagens aktiviteter – {campName}”.
The layout module renders separate label sets for desktop and hamburger rather than sharing a single list.

79. Section Anchor ID Consistency

Section anchor IDs on the index page must match their navigation labels. The id field in sections.yaml is the single source of truth for both the <section id="…"> attribute and the href="#…" in navigation links.

79.1 Anchor IDs

The testimonials section must use id="roster".
The pricing section must use id="kostnader".

The navigation link for “Röster” must point to #roster.
The navigation link for “Kostnader” must point to #kostnader.