Replyleafaccessibility

Accessibility statement

The complete round trip must work beyond a pointing device.

The creator app, local Reader, and generated recipient package are designed for keyboard use, reflow, reduced motion, high contrast, and assistive-technology navigation.

Additional device verification remains in progress

Built-in provisions

  • Semantic landmarks, headings, lists, tables, forms, fieldsets, labels, and dialogs.
  • Visible keyboard focus and a skip link.
  • No essential drag-only action; reorder and region alternatives use buttons or form fields.
  • Minimum 44 by 44 CSS-pixel primary touch targets.
  • Status is communicated with text and symbols, not color alone.
  • Non-chatty live regions for processing, saving, filtering, and validation.
  • Dialog focus containment and return targets.
  • Ordered textual lists for visual annotations.
  • Normalized coordinate entry for keyboard-created rectangles.
  • Reduced-motion and forced-colors styles.
  • Responsive layouts intended to reflow at 320 CSS pixels and 200% zoom without page-level horizontal scrolling.

Release test target

Every release candidate must run automated accessibility checks across primary, empty, modal, error, viewer, and generated-package states. Manual checks include a keyboard-only creator-to-recipient round trip, focus order, 200% zoom, 320-pixel reflow, 400% primary-flow smoke testing, forced colors, reduced motion, VoiceOver, and NVDA.

Automated testing is not certification.

Passing an automated scan does not prove that every user, browser, assistive technology, or user-supplied package will have an equivalent experience.

Creator-supplied content matters

The app cannot invent useful descriptions for uploaded work. Creators should provide clear titles and descriptions, avoid instructions that rely only on color or position, keep filenames meaningful, and select a built-in theme with appropriate contrast. The product generates printable contact-sheet HTML, not a PDF. A PDF created with the browser's Print command is not claimed to be tagged-accessible; use the HTML summary or CSV as alternatives.

Known limits

  • Visual comparison and image annotation are inherently visual; textual descriptions and coordinate forms reduce but do not eliminate that dependency.
  • Browser and operating-system file pickers have platform-specific accessibility behavior.
  • User-supplied logos and preview imagery may have unsuitable contrast or missing descriptive context.
  • Very large visual projects can create cognitive and navigation load even when controls are operable.

Report an accessibility barrier

Email socialreminderinfo@gmail.com with the page, browser, operating system, assistive technology, expected result, and what happened. Do not attach confidential project files without prior agreement.