Skip to content

fix: remove the duplicated main landmark from the root layout - #110

Merged
joelpeace48-cell merged 1 commit into
FinesseStudioLab:mainfrom
defimomof2:fix/duplicate-main-landmark
Aug 30, 2026
Merged

fix: remove the duplicated main landmark from the root layout#110
joelpeace48-cell merged 1 commit into
FinesseStudioLab:mainfrom
defimomof2:fix/duplicate-main-landmark

Conversation

@defimomof2

Copy link
Copy Markdown
Contributor

What this changes

Removes the duplicated <main> element from the root layout, and adds a unit test so the same breakage cannot reach main a third time.

Why

app/layout.tsx on main currently renders two <main> elements and {children} twice:

<SiteNav />
<main className="container">{children}</main>
<SiteFooter />
<AnalyticsScript />
<WebVitalsReporter />
<main className="container" id="main" tabIndex={-1}>
  {children}
</main>

Two consequences, both user-visible:

  • Every page renders its entire content twice.
  • The skip link is broken. Its target is #main, which is the second element — so a keyboard user activating "Skip to main content" lands below a full duplicate of the page rather than at the start of the content. That is the opposite of what 2.4.1 asks for.

It came from a merge that resolved a conflict in the layout body by keeping both sides — the analytics branch's <main> and the accessibility branch's <main id="main" tabIndex={-1}>. Keeping the latter preserves the skip-link target; the footer and analytics components move back below it, where they were.

Why nothing caught it

This is the second time this exact block has been broken this way, and every existing gate is blind to it:

  • tsc and ESLint are both perfectly happy with two <main> elements.
  • landmark-unique is an axe best-practice rule, not WCAG A/AA — and e2e/accessibility.spec.ts runs only wcag2a, wcag2aa, wcag21a, wcag21aa, so the suite stays green.
  • Nothing asserts that {children} appears once.

tests/unit/layout-landmarks.test.ts closes that gap at the source, asserting the element count, the {children} count, and the skip-link wiring (href="#main" has a target that carries both id="main" and tabIndex={-1}, and sits ahead of the nav). I confirmed it fails against the current layout rather than passing vacuously.

A source-level test rather than a DOM one on purpose: the failure mode is a merge splicing the file, and that is exactly what this catches — cheaply, without a browser.

How it was verified

npm run lint      ✔ no warnings or errors
npx tsc --noEmit  ✔ clean
npm test          ✔ 113 passed (20 files) — 4 new
npm run build     ✔ exit 0
  • Existing tests pass
  • New tests cover the change
  • No change to a public contract interface

Risk

Very low, and it removes a defect rather than adding behaviour. The only semantic change is that content renders once instead of twice and the skip link reaches the top of it.

app/layout.tsx renders two <main> elements and {children} twice. Every
page therefore renders its entire content twice, and the skip link — whose
target is the second <main> — lands below the duplicate rather than at the
start of the content.

It came from a merge that resolved a conflict in the layout body by
keeping both sides: the analytics branch's <main> and the accessibility
branch's <main id="main" tabIndex={-1}>. Keeping the latter preserves the
skip-link target, and the footer and analytics components move back below
it where they belong.

This is the second time the same block has been broken this way, and
nothing caught it: typecheck and lint are both happy with two <main>
elements, and duplicate landmarks are a best-practice axe rule rather than
a WCAG A/AA one, so the accessibility suite does not fail either.
tests/unit/layout-landmarks.test.ts closes that gap by asserting the
element count and the skip-link wiring at the source. Confirmed it fails
against the current layout rather than passing vacuously.
@joelpeace48-cell
joelpeace48-cell merged commit ef253da into FinesseStudioLab:main Aug 30, 2026
3 checks passed
@joelpeace48-cell

Copy link
Copy Markdown
Contributor

Nice job @defimomof2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants