Trust & transparency

Methodology

How this platform evaluates accessibility readiness before you publish.

Quick answer

Accessibility preflight means running structured checks on content or pages before you publish: automated rules where they apply, measured contrast where colors matter, optional AI only when you opt in, and explicit human-review prompts where automation cannot decide. Results are guidance—not legal certification.

Accessible Content Preflight helps you review social posts before publication. Results are guidance—not legal certification, platform approval, or a guarantee of compliance with ADA, WCAG, Section 508, or any law.

Check categories

  • Measured: Color contrast ratios use WCAG relative luminance math in your browser (Phase 3). These are numeric measurements against chosen thresholds.
  • Rule-based (automated): Caption and alt-text heuristics run locally in your browser (Phase 1)—for example repeated emojis, dense hashtags, or missing alt text when an image is present.
  • AI-assisted: Optional image review sends your image, caption, alt text, and platform to our server and then to OpenAI only when you explicitly request analysis (Phase 2). Output is validated structured data and should be verified by a human.
  • Preview (local): Screen Reader Experience Preview approximates reading order and listening noise in your browser; it is not an NVDA, JAWS, or VoiceOver emulator (Phase 4).
  • Platform guidance: Checklists and publishing tips are based on current platform help documentation and accessibility best practices (Phase 5). They do not connect to your social accounts.
  • Video transcription (AI-assisted): When you explicitly request it, prerecorded MP4/WebM video is uploaded to private temporary storage and sent to OpenAI for timestamped transcription (Phase 6).
  • Caption timing & formatting (deterministic): Caption cues, SRT, and WebVTT are built locally from model timestamps using readability heuristics—not legal WCAG pass/fail labels.
  • Caption quality (rule-based): Overlap, reading speed, line length, and similar checks are deterministic heuristics for human review.
  • Visual information (sampled-frame AI): Optional review sends a limited set of resized frames plus transcript context to OpenAI when you click Review—may miss unsampled events.
  • Non-speech audio: Meaningful sounds (music, alarms, applause) require human review; speech models may not capture them.
  • Human review: Context, brand voice, whether alt text is sufficient, transcript accuracy, caption timing, and final publishing in the native app always require human judgment.

Batch accessibility preflight (Phase 8)

The batch checker imports CSV (and optional ZIP images) locally, then runs the same deterministic Phase 1 engine, screen reader summary, and platform checklist logic per row. AI image review runs only for rows you select, through the existing Phase 2 API—one request per image, with concurrency and session limits.

Website accessibility scanner (Phase 9)

Public URLs are scanned on the server in isolated Chromium via Playwright. Automated rules come from axe-core (WCAG A/AA tags enabled in this product, plus optional best-practice rules). axe "incomplete" results and the manual checklist are treated as human review—not pass or fail. Optional AI explains fixes; it does not determine compliance.

Result intelligence (Strengthening S1)

  • Four evidence levels: automated rule detection, direct measurement, AI-assisted observation, and human evaluation. One method does not replace another.
  • Root causes: repeated findings may be grouped into likely shared patterns to help fix once across many pages—grouping is guidance, not guaranteed shared source code.
  • Priority vs impact: axe impact is preserved; remediation priority considers repetition and reach and is not a legal-risk rating.
  • WCAG coverage matrix: distinguishes automated, partial, and manual criteria. No automated violation detected is not the same as passing a criterion when human review is still required.

Result UX & Fix Lab (Strengthening S2)

  • Workflow tabs: Overview (Start Here priorities), Issues (grouped views), Fix plan with Fix Lab, Human review, and Report.
  • Explanation levels: Simple (default), developer, and standard WCAG detail—without replacing human judgment.
  • Verification: Mark fixes in the fix plan and rescan to compare snapshots; verification is never assumed from status alone.
  • Rendering: Playwright Chromium (JavaScript enabled, bounded lazy scroll).
  • Not checked automatically: Full keyboard traversal, logged-in experiences, caption accuracy, alt-text quality in context, every WCAG success criterion.

Accessibility Preflight Report (Phase 7)

The client-ready report aggregates results already produced in your browser session. Generating or exporting a report does not call OpenAI and does not upload draft content to our servers. Reports are not stored on our infrastructure; you control PDF, print, JSON, and text exports locally.

What runs where

Local preflight, contrast sampling, screen reader preview text, platform checklists, video preview, caption editing, report assembly, and export files run in your browser. Server processing is used for temporary video storage, transcription, optional visual frame review, optional AI image analysis, and website scanning—all only on explicit user action (AI fix guidance is separate from scanning).

What we do not check

Entire-website audits (crawl is capped), login-protected pages, PDF accessibility, live streaming captions, auto-publishing, and legal determinations are out of scope.

Platform guidance review date

Platform-specific capability notes were last reviewed October 2026. Platform UIs change; verify steps in the official app before you publish.