Accessibility for Everyone

We believe that great software should work for everyone — not just some people. Accessibility is not an afterthought at FSM Navigator®; it is woven into our design process, our development workflow, and our testing pipeline.

Field service work happens in all kinds of conditions. Technicians using the platform might be working with assistive technology, operating in bright sunlight on a mobile device, or navigating the interface with keyboard-only input. We design for all of these scenarios.

Our target standard is WCAG 2.1 Level AA conformance. That means we actively design, build, and test against the Web Content Accessibility Guidelines to make sure our platform is perceivable, operable, understandable, and robust for users with a wide range of abilities.

In September 2026 we audited the whole product against WCAG 2.1 Level A and AA, then fixed what we found. Here is what that work covered:

• A full audit of web and mobile — Automated axe-core scans of every public page and every business dashboard in both light and dark mode, keyboard checks, a 320 px reflow check, and a code review of the iOS and Android app
• Keyboard access — Customer lists, skill categories and the logo cropper now work without a mouse, and dialogs keep focus inside while open and return it when they close
• Contrast — Low-contrast text and form borders found in the KPI dashboard, several dialogs, dark mode and the mobile app were fixed
• Timing and motion — Sessions warn you with a countdown before they end, notifications pause while you read them, and looping animations stop on their own and respect reduced motion
• Labels and names — Form fields declare their purpose for autofill, and accessible names now contain the visible label text
• A test for every fix — Each fix has an automated test that failed before the change and passes after it, so the same problem can’t quietly come back
• An honest status — Not everything is done. The conformance table and known limitations below show what is still open

Here is a closer look at the specific accessibility features built into FSM Navigator®:

Keyboard Navigation

Buttons, links, form fields, dialogs and menus can be reached and used with a keyboard. You can tab through the interface, activate controls with Enter or Space, and close dialogs with Escape. Dialogs keep focus inside while they are open and send it back to where you were when they close.

Screen Reader Support

We use ARIA labels, landmark regions, and semantic HTML to make sure screen readers can accurately convey the structure and content of every page. Dynamic content updates are announced via ARIA live regions so users are never left guessing.

Color & Contrast

No information is conveyed by color alone. Status indicators, error messages, and interactive states use text or icons alongside color. We measure text contrast against the WCAG AA minimums in both light and dark modes and fix what falls short.

Focus Indicators

A visible focus ring appears on interactive elements when you navigate with a keyboard on the web, so you can see where you are on the page.

Form Accessibility

Form inputs are labeled with associated <label> elements or appropriate ARIA attributes. Errors appear as text next to the field and are announced to screen readers.

Responsive Text

Pages fit a 320 px wide window without sideways scrolling, which is what you get at 400% zoom on a typical laptop screen. Browser zoom is never blocked.

Our web dashboards and application interfaces follow the same accessibility standards as our public-facing pages. Accessibility does not stop at the marketing site — it extends into the core product.

• ARIA roles on dynamic components — Dialogs, tabs and menus use ARIA roles and report their state, such as whether a menu is open
• Chart summaries — KPI charts carry a text summary of their data for screen readers
• Data tables — Tables use real header cells so screen readers can match each value to its column
• Toast notifications — Status messages and alerts are delivered through ARIA live regions. They pause while you hover over or focus them, and error messages stay on screen for at least 20 seconds
• Session warnings — Before a signed-in session ends, a dialog warns you and counts down so you can save your work. While a dashboard is open, the idle timer does not run out, and Remember me keeps you signed in for 7 days on the web (30 days in the mobile app)

The Customer Portal — where your end customers view jobs, approve quotes, and pay invoices — is built to the same standard as the rest of the platform.

• Page landmarks — Portal pages use header, navigation and main landmarks so screen reader users can jump straight to the content
• Menu state — The mobile menu button tells screen readers whether the menu is open
• Announced messages — Sign-in and profile messages are announced to screen readers
• Grouped choices — The urgency choice on a service request is a labelled group
• Status indicators use text and color — Statuses, invoice states and approval badges use descriptive text alongside color

The signed-in portal pages have been reviewed in code but not yet scanned page by page with our automated checker. See Known Limitations.

Our iOS and Android apps are built to work with the accessibility tools people already rely on. You shouldn’t have to choose between the device settings that work for you and the app you use every day — the two should work together.

• Screen reader labels — Buttons, fields and controls carry names and roles for VoiceOver on iOS and TalkBack on Android, and screen and section titles are announced as headings. We check this in code and with automated tests. A hands-on pass with VoiceOver and TalkBack on devices is still to come.
• Adjustable text size — Text follows your device’s text-size setting, and long notifications wrap instead of being cut off.
• Reduced motion — When you turn on Reduce Motion in your device settings, the app holds back nonessential animation.
• Light and dark appearance — The app follows your device’s light or dark setting. Error, placeholder, link and muted text use colors measured to meet contrast minimums in both.
• More than color — Status, priority, and other states are shown with text and icons, not by color on its own.
• Autofill — Sign-in and profile fields tell the phone what they are for, so password managers and autofill can complete them.
• Photo zoom without pinching — The photo viewer has zoom in, zoom out and reset buttons.
• Rotation — The app no longer forces portrait. We are confirming landscape on devices before this reaches the app stores.

Some checks can only be done on a real phone, and those are listed under Known Limitations. If something doesn’t work the way it should, please let us know — see Feedback & Contact below.

Accessibility is not a one-time project — it is an ongoing commitment. We have built accessibility checks directly into our development and release process:

• axe-core in our automated tests — Our browser tests run axe-core against the pages and dialogs they open. A scanner only sees what a test opens, so we keep adding tests for dialogs, tabs and states that were not covered before
• Light and dark mode — Contrast checks run in both themes, because a color pair that passes in one can fail in the other
• Targeted regression tests — Keyboard access, focus handling in dialogs, reflow at 320 px, timing and motion, and label-in-name each have their own tests
• Mobile app tests — Automated tests check names, roles, states and color contrast for the iOS and Android app
• Periodic audits — We audit the full product against WCAG 2.1 AA and publish the result on this page. The most recent audit was completed in September 2026

FSM Navigator® partially conforms to WCAG 2.1 Level AA. Partially conforms means that some parts of the product do not yet fully meet the standard. We are not claiming full conformance, and the table below shows exactly where the gaps are.

This status covers the web app (public website, sign-in pages, business dashboards and the Customer Portal) and the iOS and Android app. It is based on our own evaluation, completed on September 24, 2026, followed by fixes that were each checked with an automated test. Internal platform administration screens and the help documentation site are not included. Mobile results describe the current app code. A fix reaches your phone with the first app update that includes it.

If you need a formal VPAT document for procurement, please contact us.

Summary by level

Every WCAG 2.1 Level A and AA criterion

Mobile app results follow the W3C guidance on applying WCAG to non-web software (WCAG2ICT). That is why a few criteria written for sets of web pages are marked Not Applicable for the app.

Sign-in code time limit (documented exception)

When your account uses an authenticator app, the step where you enter the code stays open for 5 minutes after you enter your password. We keep this window short on purpose, as a security measure, so a sign-in attempt can’t be left open indefinitely. It cannot be turned off or extended, which is why WCAG 2.2.1 Timing Adjustable is marked Partially Supports.

To make the limit easier to live with, the web sign-in screen and the mobile app both warn you about 60 seconds before the window closes, announce that warning to screen readers (VoiceOver and TalkBack in the app), and offer a Start over button that takes you back to sign in for a fresh code.

Here is what we know is not finished yet, and what we plan to do about each item:

• No hands-on screen reader pass yet — Our results come from automated scans in light and dark mode, keyboard checks, code review and automated tests. We have not yet worked through the product with NVDA, JAWS, VoiceOver or TalkBack. Next step: a full manual pass on web and on iOS and Android devices.
• Mobile checks that need a real device — Three items can only be confirmed on a phone: whether a few fixed-height fields and buttons clip at 200% text size, whether focus is visible when you use a hardware keyboard, and whether the options in three bottom-sheet pickers can be reached with VoiceOver and TalkBack. Next step: test each one on iOS and Android and fix what fails.
• Mobile rotation — The app no longer forces portrait, but the change has not been tested on devices yet. Next step: confirm landscape on phones and tablets with a new build before release.
• Customer Portal signed-in pages — These pages were reviewed in code, and the profile page is exercised by an automated test, but the signed-in portal has not been scanned page by page with our automated checker. Next step: add those pages to the scan.
• Third-party embedded content — Some components, such as payment forms provided by our payment processor, follow their own accessibility standards. We choose vendors with accessibility commitments, but we cannot fully control their implementations.
• PDF exports — Exported PDF documents may have limited accessibility. We are working on tagged PDF support.

If you run into a barrier, please tell us. Reports from people using the product are how we decide what to fix first.

Accessibility is an ongoing journey, and your feedback matters. If you encounter an accessibility barrier, have a suggestion, or just want to share your experience using FSM Navigator® with assistive technology, we want to hear from you.

We aim to respond to accessibility inquiries within 2 business days. When reporting an issue, it helps if you can tell us what page you were on, what browser and assistive technology you were using, and what you expected to happen.

Our accessibility work is guided by the following standards and resources:

• Web Content Accessibility Guidelines (WCAG) 2.1 — w3.org/TR/WCAG21/
• Section 508 of the Rehabilitation Act — section508.gov
• WAI-ARIA (Accessible Rich Internet Applications) — w3.org/TR/wai-aria/