Accessibility Statement

We aim for WCAG 2.1 Level AA as the standard we build toward. We do not claim full conformance: not every screen has been audited.

What we do commit to: treating an accessibility barrier as a defect rather than a feature request, and fixing it on that basis.

You can also use Report a problem inside the app — the (i) button in the web portal, or Settings → Help on mobile. Every role can send one, and it works even if your account is locked out.

These work today:

• Keyboard operation. Interactive controls are real buttons, links and form fields rather than clickable decorations, so they are reachable and operable by keyboard.
• “Skip to main content”. The first thing the Tab key reaches on every page is a link that jumps past the navigation and puts the keyboard focus into the page content itself.
• Visible focus. A high-contrast focus ring is applied globally to buttons, links, inputs, selects and text areas.
• Colour contrast meets AA. Every page listed below, in both light and dark mode, is checked against the WCAG AA contrast thresholds by an automated audit in a real browser — 4.5:1 for body text, 3:1 for large text. It currently passes with no exceptions.
• Dark mode is available, and is a purpose-built palette rather than an inverted filter, and it is contrast-checked the same way as light mode.
• Links in text are not marked by colour alone. Where a link sits inside a paragraph — as they do throughout these legal documents — it is underlined, so it is still visible if you do not perceive the colour difference.
• Reduced motion. The app has exactly one looping animation — the loading shimmer — and it is switched off when your system asks for reduced motion.
• Semantic structure. Pages use real headings, lists, labelled form fields and landmark elements; the page language is declared.
• Form errors are announced. Validation messages are tied to their field and marked as alerts, so a screen reader reads the problem instead of leaving you on a form that silently refuses to submit.
• Hit targets. Controls are sized for use with a thumb, in a backyard, on a phone.

We test in these ways:

• An automated accessibility check runs on every build and blocks the release if it fails. It covers every page of the app you can reach without signing in — this page and the other legal documents, the sign-in, signup, forgotten-password and reset-password screens, and the unsubscribe page reached from a service report — using the industry-standard axe rules for WCAG 2.0/2.1 A and AA.
• A broader automated check runs against a real browser before release and covers every page and every distinct state on a maintained list, in both light and dark mode — the signed-in application (dashboard, customers, pools, individual visits, routes, schedules, reports, exceptions, billing and all of team management), the archived and former-client views, the Stripe connection page, every signed-out page, and the four pages of our website at poolhandhq.com (home, pricing, FAQ and “About this website”). New pages and states are added to that list as they are built. This is the check that measures colour contrast.
• An interaction audit visits every page in the portal and fails if any interactive element gives no visible response to hover or focus — the class of problem where a control is technically reachable but reads as inert.
• Manual keyboard testing during development.

Automated tools catch only some accessibility problems. They cannot tell whether a page makes sense read aloud, which is why the reporting channel above matters most.

What does not work yet, and what to do in the meantime:

• The technician mobile app has not been fully tested with a screen reader. If VoiceOver or TalkBack does not work for you there, tell us.
• Colour contrast is checked before release, not on every build. The build-blocking check cannot measure it; the browser audit does.
• Automated checks cover the pages on our list. A rarely used dialog, or a state that only appears when something fails, may not be on it. Tell us if one gets in your way.
• Charts and trend graphs are not yet fully described for screen readers. The same data is in the visit records and the CSV export.
• No third-party audit has been done, and no VPAT exists. If you need documentation for procurement, contact us and we will tell you where we stand.
• Brief hover and focus transitions are not turned off by reduced-motion settings; only the looping animation is. If they cause you difficulty, tell us and we will extend the setting to cover them.

Accessibility: accessibility@poolhandhq.com. General support: support@poolhandhq.com. See also the Terms of Service and Privacy Policy.