Accessibility Statement

OffOn is a platform for open source enthusiasts. We want everyone to be able to read, browse, and contribute, regardless of disability, assistive technology, or device. This document explains what we support today, how we test, and how to tell us when we get it wrong.

Our Commitment

• Target: WCAG 2.2 Level AA (opens in new tab) across every page on offon.dev.
• Both color modes: light and dark mode must meet contrast and focus requirements. We do not ship a feature that only works in one mode.
• Keyboard first: every interactive element is reachable and operable from the keyboard alone.
• No motion traps: we honor prefers-reduced-motion and avoid auto-playing animation that the user did not request.

What We Support Today

• Skip-to-content link as the first focusable element on every page.
• Visible focus rings on all interactive elements, in both light and dark mode.
• Semantic landmarks: one <main id="main-content">, plus <nav>, <header>, <footer>, <section>, and <article> where appropriate.
• One <h1> per page with no skipped heading levels.
• Meaningful alt text on informational images, empty alt="" paired with aria-hidden="true" on decorative ones.
• Screen reader announcement of links that open in a new tab.
• Color contrast verified at 4.5:1 for body text and 3:1 for large text and UI controls in both modes.
• Tested with axe-core (opens in new tab) on every pull request preview, in both light and dark mode.
• Self-hosted fonts so users on restricted networks are not locked out.
• Google Analytics is opt-in only via the consent banner. No tracking runs until the user accepts.
• Page navigation is announced to screen readers via a polite live region on every client-side route change, so users do not have to manually explore to discover they have moved to a new page.
• The mobile navigation menu traps focus while open. Content behind the menu is hidden from assistive technology until the menu is dismissed, preventing screen reader users from navigating into obscured content by mistake.
• Interactive filter buttons announce the result count when a filter is applied, and announce when a filter is cleared, so screen reader users receive confirmation of both actions.
• Scrollable code blocks are keyboard-focusable with a descriptive label, so keyboard users can reach and scroll long code samples.
• prefers-contrast: more is respected: borders and muted elements increase in contrast when the user enables Increase Contrast in their OS settings.
• Windows High Contrast Mode is supported via a forced-colors: active media query that restores interactive component boundaries using system color keywords.

Supported Environments

• Modern evergreen browsers: Chrome, Edge, Firefox, Safari (current and previous major versions).
• Mobile web on iOS Safari and Android Chrome.
• Screen readers we test against during manual spot checks: VoiceOver on macOS and iOS, NVDA on Windows.
• The site is fully static and served from GitHub Pages, so it works without JavaScript for reading content. Some interactive features (theme toggle, consent banner, filtering) require JavaScript.

Known Limitations

• We do not currently provide captions or transcripts because the site does not host video or audio. If we add media, captions and transcripts will ship with it.
• The community discussion content is hosted on a separate Discourse instance and follows its own accessibility status.

If you find a barrier that is not listed here, please report it using the link below. We treat this list as evidence-based, not aspirational.

How We Test

Automated

• axe-core via Playwright on every pull request, configured in e2e/smoke.spec.ts. Runs in both dark and light mode against the production build. The PR preview workflow blocks on these scans.
• Vitest assertions on landmark roles, labels, and focus behavior for components and hooks.

Manual

For UI changes, contributors verify:

• Tab order matches the visual reading order.
• Focus is visible on every interactive element in both modes.
• The page works at 200% browser zoom and at 375px, 768px, and 1280px widths.
• Screen reader spot check on the changed flow (VoiceOver or NVDA).

Reporting an Accessibility Barrier

If something on offon.dev blocks you or is hard to use, open an accessibility issue (opens in new tab). The form prompts for the page, your assistive technology, and severity, which helps us reproduce and prioritize.

• Preferred: GitHub issue (link above). The fastest way to get a response with a fix timeline.
• Email: offondev@gmail.com if you cannot or prefer not to use GitHub.

We aim to acknowledge accessibility reports within five working days and to provide a workaround or fix timeline in the same response.

Severity We Use

For Contributors

If you are submitting a pull request, every UI change should pass the accessibility checklist in our pull request template. The full ruleset lives in ACCESSIBILITY.md (opens in new tab) and applies to every change.

Thank you for helping us make OffOn usable by everyone.

Have a question? Reach out to the team.

The accessibility audit that informed this statement used guidance from mgifford/ACCESSIBILITY.md (opens in new tab), a community resource for accessibility best practices, testing criteria, and issue severity frameworks. Thank you to Mike Gifford and all contributors for making that guidance openly available.