Accessibility
Datum is built to meet WCAG 2.1 Level AA. This page says what it meets today, what it does not yet meet, and how to tell us when we have it wrong.
Evaluated 23 September 2026 against the web application at app.datumpdm.io. Method: axe-core over 24 screens — every view, all eight workflow stages, sign-in and the phone field route — plus a keyboard-only pass, a screen-reader pass with Narrator on Windows 11, and a scripted reflow measurement that narrows the window to 1280, 640 and 320 pixels on every one of those screens.
What conforms
Every form control is named by a real label, and choice groups are announced as groups with their selected option. Pages carry landmarks, a single heading that names the view, and a skip link; the browser tab names the view or the open escalation.
Everything you can do with a mouse you can do from the keyboard. Dialogs take focus, trap it while they are open, close on Escape and hand focus back to the control that opened them.
Every text colour has been measured against the surface it is painted on, including tints and faded panels. The automated run reports no contrast failures on any screen. Colour is never the only carrier of meaning: severity, stage, priority and overdue state are each written out in words.
When an action is blocked, the form says what is still needed, by field name, in the order the fields appear. When a write succeeds or fails, a live region says so without moving your focus, and the outcome is written to the escalation record either way.
Zooming to 200% works. At that magnification the twelve navigation tabs fold into a Menu button and the account controls drop the words they can spare, keeping every control. Every view, every stage of an escalation, sign-in and the field view then fit without scrolling sideways. We measured it rather than assuming it.
What does not yet
- At phone widths the desk interface still falls short. Down to about 480 pixels it is fine. At 320 two things break: an open escalation needs 326 pixels and so scrolls sideways by eleven, and the account controls in the header need about 300 of the 320, which pushes the Menu button off the screen so you cannot reach the views with a pointer. The keyboard still reaches them, and the field link below is the path built for a phone.
- Input borders are faint. The resting border on a text box is below the 3:1 required for a control boundary. The label and the fill still identify the control, and the focus ring meets the requirement.
- Text spacing is untested. We have not verified the product against the four text-spacing metrics with a user stylesheet.
- Confirmation messages time out. They dismiss themselves after four to eight seconds. They pause while hovered or focused and can be dismissed by hand, and the same information stays on the record, but the duration cannot be extended.
- Only one screen reader has been used. Narrator on Windows. JAWS, NVDA and VoiceOver have not been part of an evaluation.
The field link
The stages done at the machine — verify the sensor, record the work, take the post-repair reading — open on a phone through a field link, a per-escalation address of the form /field?esc=… copied from the record. That view reflows with no sideways scrolling down to 320 pixels, uses 16-pixel text so a phone does not zoom on focus, gives every control a 44-pixel target and the primary action 56, and opens the camera for a photo. It is the accessible path on a small screen while the desk layout is what it is.
Report a problem
If something here is wrong, or something in the product blocks you, please write to devinluu@321reliability.com. Tell us the screen, what you were trying to do and what happened. We answer accessibility mail on the same channel as support.
The full report
The complete Accessibility Conformance Report — VPAT 2.5, WCAG edition, covering WCAG 2.0 and 2.1 Level A and AA and the Revised Section 508 standards — is kept with the source at docs/accessibility/VPAT.md. Ask by email and we will send the current one as a document.