Clear access to the brief.

The web experience targets the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as its accessibility objective. The target guides semantics, keyboard access, focus visibility, contrast, status announcements, and reduced-motion behavior; it does not mean every route or third-party surface has been certified.

STANDARD · W3C WCAG 2.2 ↗

• Unit and static checks. Vitest covers behavior and source-level contracts such as route rendering, metadata, link safety, and unavailable states.
• Build-time checks. TypeScript and ESLint run during review to catch invalid route code, unsafe markup patterns, and type regressions.
• Manual review. Public UI changes are checked with keyboard-only traversal, visible focus, native landmarks and names, reduced-motion settings, and narrow and wide viewport passes.

The repository has unit and static tests but no configured browser end-to-end suite and no automated screen-reader audit. Those gaps are limitations, not evidence of conformance.

The target is the responsive web experience in current evergreen desktop browsers and mobile browsers with JavaScript enabled. Layout review covers narrow and wide viewports; interaction review covers pointer and keyboard input. Semantic HTML, labelled controls, focus-visible styles, and reduced-motion media preferences are the baseline for assistive-technology use.

No version-by-version browser or screen-reader support matrix is maintained. Browser extensions, user styles, network failures, third-party embeds, and assistive-technology combinations can change the result, so reports should include the environment used.

• There is no automated browser E2E or screen-reader regression suite in this repository.
• Maps, charts, external embeds, and live data can have interaction or timing limits outside DDF's direct control.
• A failed or unavailable data source can change what is rendered; the product should say unavailable rather than imply a complete result.
• This page makes no unsupported WCAG conformance, certification, or third-party accessibility claim.

Send accessibility feedback to contact@dontdiefishing.com or use the contact page. Please include the route, task, expected result, actual barrier, browser and operating system, assistive technology if applicable, and a way to reproduce it without sharing private trip or account links.

We triage a report by user impact, reproduce it in the reported environment when possible, identify the smallest durable fix, add or update a focused test, and repeat the keyboard, focus, reduced-motion, and responsive checks. Remaining limitations stay documented until they are addressed; urgent access barriers take priority over visual polish.

If a route is blocked, use the contact email or page above. Do not rely on this planning aid for emergency communication or dispatch.