Accessibility

A web page is accessible when it can be read, understood, and operated by everyone — including people with visual, motor, cognitive, or hearing impairments, people using assistive technologies such as screen readers or keyboard-only navigation, and people in difficult conditions such as poor lighting, slow connections, or small screens. Accessibility is not a niche concern: it benefits all users, in all situations. Learn more: W3C — Introduction to Web Accessibility, WCAG 2.1 Guidelines.

In Whakerexa, accessibility is not a feature you add at the end. It is the foundation the framework is built on. Every component, every stylesheet, every color decision starts from the question: will this work for everyone? The result: your pages are accessible by default, with zero extra effort on your part.

Your users choose how they read

Two buttons — already in the navigation bar of this page — give your users direct control over their reading experience. No settings panel. No account required. One click.

Light / Dark mode

Switches the entire page between light and dark palette instantly. Respects the user's OS preference on first load. The choice travels with the URL — share a link, keep the preference.

<button id="btn-color" class="menuitem accessibility"
        aria-label="Switch color scheme" aria-pressed="false"
        onclick="Wexa.accessibility.switchColorScheme()"></button>

High contrast mode

Activates a reading profile designed for users with low vision or sensitivity to visual noise: larger font, increased spacing, heavier weights, stronger borders. Compliant with WCAG 2.1 — 1.4.12 Text Spacing.

<button id="btn-contrast" class="menuitem accessibility"
        aria-label="Switch contrast scheme" aria-pressed="false"
        onclick="Wexa.accessibility.switchContrastScheme()"></button>

Accessibility is architectural

Whakerexa uses CSS Cascade Layers to make accessibility guarantees that cannot be accidentally broken by custom styles. The @layer accessibility layer owns contrast mode and enforces its rules with !important — exclusively within that layer, never elsewhere. Your own CSS, written outside any layer, wins over everything else and can never interfere with contrast mode.

What this means in practice: you cannot accidentally break accessibility by adding your own styles, even without knowing how CSS layers work.

Semantic HTML, ready out of the box

Whakerexa styles standard HTML5 elements directly — <header>, <nav>, <main>, <footer>, <button>, <dialog> — without requiring extra wrapper classes. Screen readers, keyboard navigation, and browser accessibility tools all work because the HTML is correct, not because workarounds were added.

All interactive components carry the right aria-* attributes. Focus outlines are always visible. Skip-to-content links are included in every page template. External links are marked with a visible icon and an implicit warning for screen readers.

No stored preferences — no surprises

Whakerexa never uses localStorage or cookies to persist user preferences. Mode choices (dark, contrast, theme) travel as URL parameters. Every page state is reproducible from a link: send a URL, your colleague sees exactly what you see. Close the tab, the next visit starts fresh.

Printing just works

A dedicated print.css silences all animations, resets backgrounds, and enforces readable typography for print. No black boxes, no disappearing content, no broken layouts on paper.

Wire it up in two lines

Add two buttons to your navigation — IDs and aria-pressed are the only requirements. AccessibilityManager, loaded automatically with wexa.js or the bundle, handles everything else.

<button id="btn-contrast" class="menuitem accessibility"
        aria-pressed="false" aria-label="Switch contrast scheme"
        onclick="Wexa.accessibility.switchContrastScheme()"></button>

<button id="btn-color" class="menuitem accessibility"
        aria-pressed="false" aria-label="Switch color scheme"
        onclick="Wexa.accessibility.switchColorScheme()"></button>

Reusing a named tab

A plain <a> normally navigates the current tab. Set data-named-target to a window name instead, and the click opens — or switches to, if it is already open — the tab carrying that name, leaving the current tab untouched. A page claims a name for its own tab by setting window.name on load; any later link pointing to that same name reuses it rather than opening a duplicate.

This differs from LinkController's data-target (see Links): that one opens a NEW tab under the given name every time none exists yet under that exact name at the moment of the click. data-named-target is for the reverse case — a link meant to rejoin a tab that already claimed its own identity independently, whether or not it was opened by this click.

<!-- The page that owns the tab claims its name once, on load -->
<script>window.name = 'app-main';</script>

<!-- Any link elsewhere reuses that tab instead of duplicating it -->
<a href="main.html" data-named-target="app-main">Back to Main</a>