Accessibility

This template includes an accessibility baseline intended to be preserved during buyer customisation. It is not a substitute for a final WCAG audit of your finished product, but it gives you a practical starting point.

Included Baseline

Semantic App Router pages and landmark-friendly layout structure.
Skip-to-content link in src/app/layout.tsx.
Keyboard-visible focus styles centralised in src/app/globals.css.
Light and dark colour tokens designed for contrast-aware theming.
Form labels, inline validation, and server-side validation errors.
Cookie consent controls with accept/reject parity.
Reduced-motion considerations for global animations.
Error pages and empty/loading states designed to stay readable.

Every interactive control should be reachable with the keyboard and should have a visible focus state. Prefer native elements (button, a, input, select, textarea) before adding custom interactive elements.

When you add icon-only buttons, include an aria-label that describes the action:

tsx

<button type="button" aria-label="Open navigation">
  ...
</button>

Forms

Forms should keep these behaviours:

visible labels or accessible names for every input
helpful error messages near the affected field
server-side validation for every API boundary
disabled and loading states that do not remove context
success/error notifications that do not rely on colour alone

Colour And Contrast

Colours are semantic tokens in src/app/globals.css. When changing the palette, check contrast in both light and dark modes. Pay special attention to:

muted text
border-only controls
badges and pills
selected rows/cards
chart labels
legal-page body copy

Motion

Animations should respect users who prefer reduced motion. Keep motion decorative, not required for understanding the interface.

Tables And Dashboards

Dashboard tables often need horizontal scrolling on small screens. Keep column headers visible, avoid truncating critical actions, and make sure row actions have accessible names.

Final Buyer Audit

Before public launch, run at least:

keyboard-only navigation through public pages, auth pages, and dashboard pages
mobile viewport checks at 360px, 390px, 768px, and desktop
Lighthouse accessibility checks
manual screen-reader spot checks for nav, forms, tables, and dialogs

Any buyer-specific content, colours, integrations, or new components can change the final accessibility outcome, so treat this as a scaffold rather than a final certification.