Skip to content

Accessibility

Accessibility statement

How accessible the FastMonitor website is, how we tested it, what we fixed, what is still open, and how to tell us about a problem.

Version 1.1 · Last updated

1. Our aim

We want everyone to be able to use the FastMonitor website, including people who use a keyboard, a screen reader, zoom or reduced motion. We aim for the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA.

2. Where we are

The website partially meets WCAG 2.2 level AA. We audited it on 24 September 2026 and fixed the problems listed below. The issues we know are still open are listed under Known limitations, each with a plan.

3. What we tested and how

On 24 September 2026 we checked every public page (home, features, pricing, integrations, API, FAQs, docs, changelog, contact, early access, security, this page and the four legal pages), the blog and a blog post, and the sign-in and registration pages:

  • automated checks with axe-core 4.13 against the WCAG 2.2 A and AA rules and its best-practice rules, on a phone (390 by 844 pixels) and a desktop (1440 by 900) screen, with the cookie banner shown, after declining it, and with reduced motion;
  • the whole site with a keyboard only: the order of every Tab stop, whether each one is visible and not hidden under the header, the cookie banner or the footer, and whether focus is lost;
  • the animated product demos on the home and features pages with a virtual screen reader and the browser's accessibility tree: what is read, what is announced when a step changes, and whether the controls work without a mouse;
  • text and control contrast, zoom to 200% and 320-pixel widths, and the reduced-motion setting.

These checks ran in Chromium. We have not yet repeated them with NVDA, JAWS, VoiceOver or TalkBack on real devices; see Known limitations.

4. What we fixed

  • Keyboard focus is always visible: a dark two-pixel outline (white on dark areas), never hidden under the sticky header, the footer or the cookie banner. Every page starts with a “Skip to content” link.
  • The cookie banner comes first when you press Tab, and after you choose, focus goes back to where you were.
  • Text and controls meet the contrast minimums: small orange and grey text is darker, and buttons, arrows, step dots and form borders are at least 3:1.
  • Forms: the contact form uses a standard drop-down for the subject, each error is shown under its field and read with it, and focus moves to the first field that needs attention. The sign-in and registration errors are tied to their fields, the password toggle works with a keyboard, and the early-access email field has a visible label.
  • The sign-in and registration pages have a way back to the site, their own page titles, and a signed-in visitor is taken to the dashboard instead of a missing page.
  • The animated demos: a screen reader can read every step of each story as a list, a step you pick is announced, and the automatic steps are not. A “Pause animations” button next to each animated section stops every moving picture and the scrolling testimonials. The status page animation no longer moves when you ask for reduced motion.
  • The “Try it here” routing canvas can be used without dragging: a list lets you remove and add links with the keyboard, every node and link has a name, and focus stays put when you run it.
  • Headings follow the page structure, the menu on phones is a named navigation area that closes with Escape, and tables and code examples that scroll sideways can be scrolled with the keyboard.

5. Known limitations

  • We have not yet tested with NVDA, JAWS, VoiceOver or TalkBack on real devices. Our screen-reader checks used a virtual screen reader in Chromium. We plan a manual pass with NVDA on Windows and VoiceOver on macOS and iOS, and will update this statement with what it finds.
  • On phones, the “Route by” buttons in the routing demo come before the demo when you press Tab, although they are shown after it. We plan to reorder them.
  • The small text inside the product pictures (for example times and labels in the mock screens) is decorative and low in contrast. The captions next to each picture carry the information.
  • The FAQ answers are each marked as a separate region, which makes the list of page regions long for screen-reader users.
  • The sign-in page links both to our Privacy Policy and to Google's (for reCAPTCHA) with the same words.

6. The monitoring dashboard

The monitoring dashboard (the app you use after signing in) was audited in the same week against the same standard, and its fixes shipped on 25 September 2026: the layout reflows on phones, every dialog keeps and returns keyboard focus, errors and confirmations are announced, every control has a name, colours meet the AA contrast ratio, and each page has its own title. Still open there: a warning before a session expires, and the Create buttons on the check and job forms, which stay disabled until the form is valid instead of pointing at the first problem. The full audit report, for the website and the dashboard, is available on request.

7. Feedback and contact

If something on the site is hard to use, or you need information in another format, email support@fastmonitor.app or use the contact form (choose “Support”). A person reads every message. You can also ask us for the full audit report.

8. About this statement

This statement was prepared on 25 September 2026, after the audit of 24 September 2026 and the fixes above. We review it when the website changes significantly, and at least once a year.