Last reviewed: August 25, 2026
Preshift Concepts is built to conform to WCAG 2.2 Level AA. We chose 2.2 AA specifically because it carries forward the Level A and AA success criteria of 2.0 and 2.1 — with the single exception of 4.1.1 Parsing, which the W3C retired as obsolete — and adds further criteria on top, making it the highest common bar across the accessibility standards actually in force across every region we operate or may operate in: the ADA litigation benchmark in the US, AODA and the Accessible Canada Act in Canada, the European Accessibility Act in the EU, and the public-sector WCAG 2.2 AA requirement in the UK. Meeting it once genuinely covers all of them rather than requiring separate region-specific behavior.
This statement covers the surfaces Preshift Technology directly builds and controls: the guest WiFi splash and connection flow, the admin portal, and every transactional email this app sends (verification codes, rating requests, review links, admin account emails). It does not cover third-party sites we integrate with (Mailchimp, Toast, UniFi controller UIs) or content an operator embeds that lives outside our chrome.
Conformance is checked manually against the WCAG 2.2 AA success criteria on every new or changed UI surface, including the criteria 2.2 added on top of 2.1 (Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, Accessible Authentication) — not just the 2.0/2.1-era criteria most automated checklists default to. This is a standing engineering rule for every UI change in this codebase, not a one-time audit; each change is checked against the standard before it ships. We also run automated accessibility linting (eslint-plugin-jsx-a11y's recommended rule set) as a required, non-bypassable check on every build — a build with an accessibility-linting violation does not deploy. We have not commissioned an independent third-party accessibility audit — this is a self-assessment backed by automated linting, not an outside certification.
The guest splash page's welcome card can render over an operator-uploaded background photo at an operator-configurable opacity. Because both the photo and the opacity are set per location, it is possible for an operator to choose a combination that fails WCAG's 4.5:1 text-contrast requirement even though our own card styling is AA-compliant on its own. The admin branding editor now samples the actual rendered combination (photo, opacity, and text color together) and warns the operator in real time when it's likely to fail — but this is advisory, not an enforced block, so an operator can still save a combination the warning flagged. Our own application chrome — navigation, forms, buttons, admin UI — is held to AA; content an operator layers on top of it (a background photo plus opacity) is warned about, not guaranteed.
If you encounter an accessibility barrier using this product, contact the operator of the location or network you connected to, or reach Preshift Technology directly through preshifttechnology.com.