Skip to main content

Accessibility statement

Last updated: 2026-05-27

ScreenGuardian is built by one person, and accessibility is an ongoing commitment rather than a finished line. This page lists what we target, what we know is imperfect today, and how to tell us about a barrier you hit.

What we target

We aim for WCAG 2.1 Level AA on the public website (screenguardianapp.com) and a comparable level of keyboard, contrast, and screen-reader usability in the desktop application. The Web Content Accessibility Guidelines are the de-facto international standard for web accessibility; targeting AA means we cover the most common barriers for users with visual, motor, hearing, and cognitive differences.

Where we are today

  • Website — semantic HTML, visible focus indicators, ARIA labelling on interactive controls, and form inputs paired with native <label> elements. The home-page Three.js scene and all CSS animations respect prefers-reduced-motion: reduce: motion-sensitive users see a static composition instead of the camera bloom. We deliberately avoid carousels, auto-playing video, and attention-stealing animation on critical paths (account, download, billing).
  • Desktop app — built on Qt for Python, which exposes the platform-native accessibility APIs (NSAccessibility on macOS, UIAutomation on Windows). Interactive controls (toggles, sidebar buttons, chrome-row icons) carry explicit accessible names. Tab navigation reaches every control in visual order. Trend indicators use both colour and a distinct symbol (↑ / ↓ / •) so colour vision differences don't remove information. Cmd+, / Ctrl+, opens settings without needing a pointer.
  • Camera-based features — ScreenGuardian's core value depends on a webcam reading body landmarks. That makes the product itself less useful to people who cannot or prefer not to use a camera. We don't have a non-camera mode yet, and we don't want to claim one until it actually works.

Known limitations

  • Charts now carry an accessible name matching the visible title, plus a description slot for the spoken data summary; individual data-point announcements are still on the roadmap. Calibration overlay and picture-in-picture remain visual-only and are next on the screen-reader pass.
  • We have not formally tested with every assistive technology combination (VoiceOver + Safari, NVDA + Firefox, JAWS + Edge, etc.). Reports from real assistive-tech users are how we close those gaps fastest.
  • High-contrast / forced-colors mode on Windows is not yet a tested configuration. The app currently relies on its own light / dark themes, not the OS contrast pack.

Tell us if something is broken

Email [email protected] with the page or screen, the assistive technology you were using, and what went wrong. We read every message and reply within 5 working days.

This statement

We review and revise this statement at least once a year, and whenever a change to the product materially affects an accessibility commitment listed above. The Last updated date at the top of this page reflects the most recent revision. Statement prepared by Eric W, the developer of ScreenGuardian, with reference to WCAG 2.1 and the W3C accessibility-statement guidance.