Accessibility Statement

We are working toward conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, and we track the 2.2 additions as we go. We have not completed an independent third party audit, so we do not claim full conformance. Where this statement describes something as done, it means implemented and checked by our team, not certified.

• Semantic HTML with real headings, lists, and landmarks so screen readers can navigate structure rather than guessing at it.
• Keyboard access to interactive controls, with visible focus indicators rather than focus removed for aesthetics.
• ARIA roles and labels on custom controls, including progress indicators, radio groups in training assessments, and modal dialogs that announce themselves.
• Color is never the only signal. Status is carried by an icon and text as well as color, so it survives color blindness and direct sunlight.
• Contrast targets of 4.5:1 for body text and 3:1 for large text and interface components, with a light-first design because glare on a jobsite makes dark interfaces hard to read outdoors.
• Responsive layouts that reflow rather than shrink, so text and controls stay legible instead of being scaled down to fit.
• Text that respects browser zoom, and layouts that respect device safe areas.
• No hover-only interactions. Anything reachable by hovering is also reachable by tap or keyboard.

We would rather name these than let you discover them. We are working on each.

• Some administrative workspaces, including the Training Command Center, are dense multi-panel layouts. On a small phone we show a simplified view and recommend a tablet or desktop rather than compressing the full grid into an unusable screen. The simplified view carries the critical information, but it is not full parity.
• Map-based surfaces, including geofence drawing and live tracking, are inherently visual and are difficult to operate without sight. Where a map is the primary interface, we aim to provide the same information in text form, but that coverage is not complete.
• We have not completed a full manual audit with assistive technology across every surface. Our internal checklist is tracked in the codebase, and gaps are recorded rather than hidden.
• Some documents generated by the platform, including certain PDFs, are not yet fully tagged for screen reader use.
• Third party components, such as mapping and payment interfaces, are governed by their vendors' accessibility support and may not match the rest of the platform.

The platform is built for current versions of Chrome, Safari, Edge, and Firefox on desktop, and Chrome and Safari on mobile, used with the assistive technology built into those platforms. Older browsers may work but are not tested. If you rely on a specific tool or configuration, tell us and we will test against it.

If any part of Terra Logic Suite or OnSite prevents you from doing your work, please tell us. Describe what you were trying to do, the page or screen, and the device, browser, and assistive technology you were using. That detail is usually what lets us reproduce and fix it quickly.

Email appsupport@terrausa.com. We aim to respond within three business days. If a barrier is stopping you from completing safety or compliance work, say so in the subject line and we will treat it as urgent.

If we cannot resolve something quickly, we will tell you what we are doing instead, including any workaround, so you are never left waiting without an answer.

If the platform is not usable for you, a person can do it with you. Terra staff can complete onboarding, document upload, driver and equipment records, and dispatch acceptance on your behalf by phone. Ask your Terra representative, or write to appsupport@terrausa.com. Using that path will never disadvantage you.

If you are not satisfied with our response, write to legal@terrausa.com with the details and our earlier correspondence, and we will review it.

Terms of Service · Privacy Policy · Contact