Accessibility statement

The Cablefolio app

Accessibility statement

Cablefolio is meant to be usable by everyone who works with it — on a phone on site, on a desktop in the office, with a keyboard, a screen reader, a larger text size, or a preference for less motion. This page says what it aims for, how that is checked, where it still falls short, and how to tell the team about a barrier.

The target

The target is the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA, for the whole app: the staff pages, the client portal, shared reports, and one-time links. That includes:

• every task possible from a keyboard, with focus always visible and never trapped except inside an open dialog, which Escape closes;
• pages built from headings, landmarks, and labelled controls, with a "Skip to content" link first in the app and the portal;
• text contrast of at least 4.5 to 1, and 3 to 1 for the edges of controls, in both the light and the dark theme;
• touch targets at least 44 pixels square on a touch screen;
• layouts that reflow from a phone's width to a wide monitor, and to 200% zoom, without scrolling sideways;
• movement kept to a minimum when the device asks for reduced motion.

How it is checked

• Automated checks in a real browser. The end-to-end journeys drive the app on a Pixel 7, an iPhone 14, and a desktop Chrome window, and almost every one of them runs axe-core over the pages it visits and fails on any violation. The four that do not are the sign-in, offline-sync, smoke, and tree-drag journeys.
• Lighthouse. Every change pushed to the app's repository runs Lighthouse against the sign-in page, and its accessibility score must be at least 95 for the change to pass.
• Keyboard paths built in. The command palette (Ctrl+K or Cmd+K) reaches any page or record, ? lists every shortcut, the client tree follows the WAI-ARIA tree pattern with the arrow keys, and dialogs keep focus inside until they close.
• Reduced motion. When the device asks for reduced motion, the app's transitions and animations are cut to an instant.
• By hand. Both colour themes, very narrow and very wide screens, and a keyboard and screen-reader pass are reviewed by hand when the interface changes. None of these, and not 200% zoom either, is part of the automated checks.

Known gaps

These are the places the app does not yet meet the target, with the way around each where there is one.

• Arranging the topology map. Moving a device to a place of your own on the topology map is done by dragging. Every device on the map can still be reached and opened from the keyboard, and the automatic layout needs no dragging.
• Drawing on a floor plan. Drawing rooms, walls, lines, arrows, and clouds on a plan takes a pointer or a finger. A shape already drawn can be selected from the keyboard.
• Marking up a photo. Drawing arrows, boxes, and text on a photo before it is filed takes a pointer or a finger. The photo can be filed without markings and described in its caption instead.
• Moving a device in the client tree. Dragging a device onto another room or rack takes a pointer; from the keyboard, use Move item on the device's page, which shows the same check of what the move would break.
• Drawings in the report. The report is built from headings, lists, and tables, but its rack and floor-plan drawings are each one named picture ("Rack elevation: Rack A") rather than something a screen reader can step through.

The customer sign-off is not a gap: where drawing a signature is not possible, the signer's typed name is the signature.

Report a barrier

If something in Cablefolio is hard or impossible to use with the way you work, tell the team that gave you access — through a service request in the portal if you have a portal account, or however you normally reach them. Say which page you were on, what you were trying to do, and what you use (browser, device, and any assistive technology). A barrier is treated as a defect, like any other.