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.

Accessibility is not just a checkbox for us. Here is what we have put into practice:

• Lighthouse 100/100 accessibility scores — All public-facing pages are tested with Google Lighthouse, and we maintain perfect accessibility scores across the board
• Automated WCAG scanning — We run automated accessibility scans as part of our automated test suite to catch regressions before they reach production
• Semantic HTML throughout — Proper heading hierarchy, landmark regions, and ARIA labels are used consistently across every page
• Keyboard navigation support — Skip-to-content links, logical focus order, and keyboard-accessible interactive elements throughout the platform
• Color contrast compliance — All text meets WCAG AA minimum contrast ratios: 4.5:1 for body text and 3:1 for large text
• Responsive design — The platform works on mobile, tablet, and desktop, adapting layout and interaction patterns for each
• Dark mode with maintained contrast — Our dark mode theme preserves proper contrast ratios so readability is never sacrificed for aesthetics
• All application dashboards remediated for WCAG 2.1 AA compliance — Comprehensive accessibility remediation completed across all application dashboards (April 2026)
• Automated axe-core scanning verifies 0 violations — Every test run scans all application dashboards with axe-core, confirming zero WCAG 2.1 AA violations across the entire application

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

Keyboard Navigation

Every interactive element — buttons, links, form fields, modals, and menus — is reachable and fully operable using only a keyboard. You can tab through the interface, activate controls with Enter or Space, and navigate without ever touching a mouse.

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 always use text or icons alongside color. All text meets WCAG AA contrast minimums, in both light and dark modes.

Focus Indicators

Visible focus outlines appear on all interactive elements when navigating with a keyboard. You can always see where you are on the page, which is critical for users who rely on keyboard navigation.

Form Accessibility

All form inputs are labeled with associated <label> elements or appropriate ARIA attributes. Error messages are programmatically linked to their fields so screen readers announce them clearly.

Responsive Text

Content remains readable at 200% zoom without requiring horizontal scrolling. Layouts reflow gracefully, ensuring users who need larger text can access everything without losing context.

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 — Modals, tabs, dropdown menus, and navigation components all use appropriate ARIA roles and states
• Loading states announced — When content is loading, assistive technology is notified so users know something is happening
• Accessible data tables — Tables include proper headers with scope attributes so screen readers can associate data cells with their column and row labels
• Toast notifications — Status messages and alerts are delivered through ARIA live regions, making them accessible to screen reader users without interrupting their workflow

The Customer Portal — where your end customers view jobs, approve quotes, and pay invoices — follows the same accessibility standards as the rest of the platform.

• Logical tab ordering — Focus moves through the portal in a predictable, intuitive sequence
• Focus management — When modals open or pages transition, focus is moved to the appropriate element so keyboard and screen reader users are not lost
• Status indicators use text and color — Job statuses, invoice states, and approval badges use descriptive text alongside color coding
• Mobile-friendly touch targets — All interactive elements meet a minimum touch target size of 44×44 pixels, making the portal easy to use on phones and tablets

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 support — The app works with VoiceOver on iOS and TalkBack on Android. Buttons, fields, and controls are labeled so screen reader users can move through the app and act on what they need to do.
• Adjustable text size — Text follows your device’s text-size setting, so if you’ve made text larger system-wide, the app honors that choice.
• Reduced motion — When you turn on Reduce Motion in your device settings, the app holds back nonessential animation and presents content calmly instead.
• Light and dark appearance — The app follows your device’s light or dark setting automatically, keeping text readable with proper contrast either way.
• More than color — Status, priority, and other states are shown with text and icons, never by color on its own.
• Comfortable touch targets — Interactive controls are sized and spaced to be easy to tap, including for people with limited dexterity.

We keep testing the apps with these settings as we add features, and we welcome a note if something doesn’t work the way it should — 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 integration in automated test suite — Comprehensive automated accessibility tests powered by axe-core run on every test execution, scanning every dashboard for WCAG 2.1 AA violations
• Multi-category accessibility scanning — Every page is scanned across multiple accessibility categories including color contrast, heading structure, interactive element labels, ARIA compliance, keyboard accessibility, and form labels
• Automated keyboard accessibility scanning — Focus traps, tab order, and scrollable region keyboard access are verified automatically across all interactive components
• 100% dashboard coverage — Every dashboard is scanned automatically on every test run, ensuring no accessibility regression goes undetected
• Lighthouse audits — All public-facing pages are regularly audited with Google Lighthouse to maintain our 100/100 accessibility scores
• Manual keyboard navigation review — We periodically walk through the entire platform using only a keyboard to catch issues automated tools might miss
• Regular accessibility audits — We conduct periodic reviews of new features and updated interfaces to ensure they meet our accessibility standards before release

The following table summarizes our conformance with WCAG 2.1 Level A and Level AA success criteria. This is intended as a high-level reference — if you need a formal VPAT document for procurement, please contact us.

We want to be upfront about areas where we are still improving:

• Third-party embedded content — Some components, such as payment forms provided by our payment processor, follow their own accessibility standards. We select vendors with strong accessibility commitments, but we cannot fully control third-party implementations
• Complex data visualizations — Certain charts and graphs in dashboards may not be fully accessible to screen readers. Where possible, we provide accompanying data tables as an accessible alternative
• PDF exports — Exported PDF documents may have limited accessibility. We are actively working on tagged PDF support to improve this experience

We take these limitations seriously and are working to address them. If you encounter a barrier, please let us know — it helps us prioritize what to fix next.

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/