itomsitoms

Accessibility Statement

Last updated: May 25, 2026

itoms is committed to making the platform usable by the widest possible audience, including people who rely on assistive technologies. This statement describes our current accessibility standard, the surfaces it applies to, the known gaps we are actively closing, and how to report an issue.

Our Standard

itoms targets Web Content Accessibility Guidelines (WCAG) 2.1, Level AAacross the entire platform. WCAG 2.1 AA is the standard cited by EU EAA-bound regulations, US Section 508 procurement, and most enterprise vendor reviews.

Surfaces Covered

  • Operator dashboard (app.ito.ms/admin) — where publishers create and manage content.
  • Embedded widget (widget.js + /embed) — the floating content panel that operators install on third-party host sites. Because a non-conformant widget breaks compliance for every site that embeds it, this surface receives the highest level of scrutiny.
  • Standalone microsites (/standalone/[slug]) — per-project public pages.
  • Sign-up, login, MFA, and transactional email.

Current Conformance Status

itoms is partially conformant with WCAG 2.1 Level AA. Parts of the platform fully meet the standard; others have known exceptions listed below. Conformance is measured continuously via automated tooling on every code change:

  • eslint-plugin-jsx-a11y on the recommended rule set runs on every pull request.
  • @axe-core/playwright end-to-end specs scan the four primary surfaces (admin, widget, standalone, auth) for serious and critical violations.
  • Lighthouse accessibility scores are recorded against each preview deployment.

Accessibility Features Already in Place

  • Keyboard navigation — every interactive control is reachable via Tab / Shift-Tab / Enter / Space / Esc / arrow keys. A “Skip to main content” link is the first focusable element on every primary surface.
  • Screen-reader semantics — landmarks (header,nav, main, footer) are present on every page; icon-only buttons carry aria-label; the embedded widget announces itself with the project name; the widget’s expand/collapse panel manages focus and returns it to the trigger on close.
  • Accessible form errors — validation messages userole=“alert”, inputs flip aria-invalid on error, and each error is linked back to its input viaaria-describedby.
  • Focus traps in dialogs — every modal and dropdown is built on Radix primitives, which provide focus traps, ESC handling, and scroll-lock by default.
  • Color contrast warnings — the color pickers operators use to brand their widgets and microsites display a live WCAG contrast ratio and warn when a combination fails AA (4.5:1 for text, 3:1 for large text and UI components).
  • Accessible email templates — transactional emails sethtml lang, mark layout tables asrole=“presentation”, and provide alt text on every meaningful image.

Known Limitations

We are transparent about gaps that have not yet been remediated:

  • No third-party audit yet. Conformance claims above are self-assessed from automated scans and manual keyboard / screen-reader spot checks. A formal third-party audit is on the roadmap but has not yet been commissioned.
  • Operator-customizable color combinations. Operators can save color combinations that do not meet AA contrast (they receive a warning, but we do not block them). When you encounter a widget or microsite with poor contrast, the operator who set it up is the fastest path to a fix.
  • User-generated content. itoms is a publishing platform; accessibility of titles, descriptions, alt text on uploaded images, and captions on uploaded videos depends on the operator. The platform encourages accessible authoring (alt-text fields, transcript editors) but cannot guarantee individual content meets WCAG.
  • Auto-playing video. Some operators may configure videos to autoplay inside the widget. Where this occurs, audio is muted by default per WCAG SC 1.4.2, but the visual motion may still affect users sensitive to motion.
  • Mobile screen readers. Primary testing has been on NVDA (Windows) and VoiceOver (macOS). Coverage on TalkBack (Android) and VoiceOver (iOS) is more limited.

Report an Accessibility Issue

If you encounter an accessibility barrier, please tell us. We treat accessibility reports with the same priority as security or data-loss issues.

Email accessibility@ito.ms with:

  • The URL or surface where you encountered the barrier.
  • What assistive technology you were using (screen reader + browser + OS).
  • What you expected to happen and what actually happened.

We aim to acknowledge accessibility reports within two business days.

Standards and References