Accessibility.

Last updated: May 18, 2026

This site is built to be usable by everyone, on any input device, on any connection. It targets WCAG 2.2 Level AA conformance. The sections below document what's in place and why each technique matters.

Document structure

Semantic HTML

Pages use real <header>, <nav>, <main>, <article>, <section>, and <footer> landmarks instead of stacks of generic <div>s.

Why: Screen readers expose landmarks as a rotor or shortcut menu. A blind user can jump straight to the booking form or skip the navigation in one keystroke. Generic divs offer none of that.

Heading hierarchy

Each page has exactly one <h1>, followed by <h2> for sections and <h3> for sub-sections. Heading levels are never skipped to control visual size. Sizing is handled with utility classes (.text-display, .text-title, .text-subtitle).

Why: Screen readers announce heading level, and many users navigate page-to-page by jumping heading-to-heading. A page whose H2 jumps to H4 sounds broken; a page with three H1s sounds disoriented.

Language

Every page declares <html lang="en-CA"> in the document head.

Why: Screen readers switch pronunciation engines based on this attribute. Without it, an English page read by a default Spanish voice is unintelligible.

Keyboard & input

Skip link

The first focusable element on every page is a "Skip to content" link. It's visually hidden until focused, then slides into view as a pill in the top-left.

Why: Keyboard users would otherwise tab through the entire site navigation on every page load. Skip links cut that to one Tab + Enter.

Visible focus

All focusable elements show a 2px outline in --color-accent with a 3px outline-offset. The offset matters: it keeps the outline visible even when an element has the same colour as the outline itself.

Why: Browsers' default focus rings are often invisible on dark themes. Sighted keyboard users (RSI, motor impairment, power users) need to see where they are at all times. Removing the focus ring entirely (common in modern designs) is a WCAG 2.4.7 failure.

Mobile menu focus management

Opening the hamburger menu sets aria-expanded="true" on the trigger and locks body scroll. Pressing Escape closes the menu and returns focus to the trigger button. Resizing past the mobile breakpoint auto-closes and unlocks scroll so a desktop user never lands in a stuck state.

Why: A menu that opens but won't close, or that traps focus behind a hidden overlay, is unusable with keyboard or screen reader.

Custom date picker

The contact form's event-date picker is built as a real role="dialog" with day cells exposed as role="gridcell". Each cell carries a full aria-label ("Monday, May 18, 2026") and the selected day carries aria-selected="true". The dialog closes on outside click, on Escape, or on selection.

Why: The native <input type="date"> has inconsistent screen-reader support across browsers and operating systems. A custom picker built on standard ARIA patterns is more predictable.

Visual design

Colour contrast

Body text (#b3b3b6 on #000000) hits a contrast ratio of 8.7:1, well above WCAG AA's 4.5:1 requirement for body text. Primary ink (#f5f5f5) hits 18.7:1. The most muted text used anywhere on the site (#85858a for eyebrow labels) is 5.3:1, still passing AA. No text falls below the threshold.

Why: Low-contrast type is one of the most reported accessibility issues: for low-vision users, for anyone reading outdoors, and for older eyes. WCAG AA is a floor, not a ceiling; this site aims past it.

Resizable text

Type sizes use rem and clamp(), never fixed pixels. Setting the browser's default font size to "Very Large" scales the entire interface up to 200% without breaking layout or causing horizontal scroll.

Why: Users with low vision often set their browser's base font size up rather than using zoom. A site built in fixed pixels ignores that preference entirely.

Forced-colors / high-contrast mode

Buttons and ghost outlines declare explicit borders inside a @media (forced-colors: active) block so they remain visible when Windows High Contrast mode overrides the palette.

Why: Forced-colors strips most styling. Without explicit borders, a ghost button becomes invisible because its only visible affordance is its border colour.

Media & motion

Alt text on every image

Photographs carry descriptive alt text. Not just "photo of Grayson" but "Grayson seated at the centre of a Whitecaps fan zone, juggling a ball while kids in blue kits watch." Purely decorative images (grain overlay, brand mark) are marked aria-hidden="true" so screen readers skip them entirely instead of announcing meaningless filenames.

Why: Empty alt text on a meaningful photo gives a screen-reader user nothing. Descriptive alt text gives them the same atmosphere a sighted visitor gets.

Reduced motion

The site honours prefers-reduced-motion: reduce. When set, all animation and transition durations drop to ~0ms, so hover and focus changes apply instantly without bounce or fade.

Why: Motion can trigger vestibular disorders, migraines, and nausea. The OS-level preference is the user's accessibility setting. Sites that ignore it can make people physically ill.

No autoplay video

The site does not autoplay video or audio. The "Latest reel" link opens YouTube in a new tab, where the user controls playback.

Why: Unexpected sound is disorienting for screen-reader users (it competes with the synthesised voice) and disruptive for anyone in a quiet environment.

Forms

Explicit labels and autocomplete

Every form control has a real <label> tied via for/id. Required fields are flagged with both a visible * and the required attribute. Common fields carry the right autocomplete tokens (name, email, organization) so password managers and assistive tech can fill them automatically.

Why: Placeholder-only "labels" disappear the moment a user types and are unreadable for screen-reader users navigating field-by-field. autocomplete is also a WCAG 2.2 Success Criterion (1.3.5).

Live region for status

The contact form's status message uses aria-live="polite" and role="status". When the server responds, the success or error message is announced by screen readers without stealing focus.

Why: Without a live region, a screen-reader user who submits a form has no idea whether it worked. They tab away, hear nothing, and assume the site is broken.

No JS, still functional

The contact form submits via a standard POST to a server endpoint and falls back to a redirect-with-status flow if JavaScript is disabled or fails. No client-side framework is required to send a message.

Why: JavaScript can be blocked by corporate networks, disabled by privacy-conscious users, or just fail to load over a slow connection. Core conversion paths (book, contact) shouldn't depend on it.

How it's tested

Before each significant release the site is checked with:

Keyboard-only navigation across the home, contact, booking, and World Cup pages, plus mobile-menu open/close.
axe DevTools and Lighthouse accessibility audits with a target of zero serious or critical violations.
Manual screen-reader checks on the primary booking and contact paths (NVDA on Windows, VoiceOver on macOS).
Forced-colors and prefers-reduced-motion simulation via browser dev tools.
Text-zoom to 200% with the browser font-size set to "Very Large," verifying no content is clipped or unreachable.

Known limitations

Action photography. Alt text describes each photograph in detail, but cannot fully replace the kinetic feeling of a live freestyle performance. Reels on YouTube are the closest dynamic substitute.
Third-party social pages. Linked Instagram, YouTube, and TikTok pages have their own accessibility properties outside this site's control. They open in new tabs so the user can return without losing context.

Report a barrier

If anything on this site doesn't work for you, send a message through the contact form with the page URL, the browser and assistive technology you're using, and a brief description of what went wrong. Replies arrive within seven business days; fixes are prioritised by severity.