Rate My Server

Accessibility Statement — Rate My Server

Current as of the effective date below. This statement is pending final review by counsel; please contact us with any questions.

Operated by: Rate My Pro, LLC ("Rate My Pro," "we," "us") Applies to: the Rate My Server website (rate-myserver.com) and the Rate My Server mobile app. Standard we target: WCAG 2.2 Level AA. Effective date: July 2, 2026 · Last updated: July 2, 2026 Contact: accessibility@rate-myserver.com

1. Our commitment

Rate My Server exists to help hospitality professionals build a reputation everyone can see and share. "Everyone" includes people who use assistive technology, so we build toward WCAG 2.2 Level AA and treat accessibility as part of quality, not a later pass. A guest must be able to follow and endorse a Pro without a screen full of friction — that simplicity helps accessibility too.

2. What we've done so far

Design foundations (both surfaces)

  • No meaning by color alone. A Hospitality Score is never rendered red or "declining" — a new Pro reads as "New," and confidence is shown as a text label (New / Building / Established), not just a hue. Verified endorsements carry a text/aria label, not only a checkmark color.
  • Touch targets ≥ 44pt on interactive controls (buttons, chips, the follow/endorse actions).
  • Warm, high-contrast palette (deep green / gold / warm off-white) chosen for legibility; red is reserved for genuinely destructive actions.
  • Reduced motion respected. Animations (the landing promo reel, score count-up, step transitions) honor prefers-reduced-motion and fall back to a calm static state.

Web (rate-myserver.com)

  • Semantic HTML with landmark regions and labeled sections; aria-labels on the score chip, endorsement markers, dialogs (role="dialog", aria-modal), and navigation.
  • Visible keyboard focus (:focus-visible outlines) and fully keyboard-operable controls (native buttons, links, form inputs with associated labels).
  • Self-hosted fonts and a static-first landing to minimize layout shift (CLS) and load time.
  • Guest follow/endorse works in the browser with no app install and minimal input.
  • Minimum target size (WCAG 2.2 §2.5.8). Primary actions are ≥ 44pt; link-style controls clear the 24px minimum, verified site-wide.
  • Skip-to-content link (visually hidden until focused) on every page, so keyboard and screen-reader users can bypass the header.
  • Every web form input has a visible, associated <label> (including the "Report this profile" and recovery-email flows), with logical focus placement when a form opens.
  • Text and UI contrast independently verified against AA — all audited token pairs meet ≥ 4.5:1 for normal text (≥ 3:1 for large text / UI).

Mobile app (Flutter)

  • Semantics labels on key controls — the brand mark, score chip, QR/share, the profile avatar/photo, the followers milestone progress bar, back navigation, the photo-picker button, selected-venue confirmation, and the onboarding/sign-in Terms/Privacy links (announced with a "link" suffix) — plus MergeSemantics so a checkbox and its inline links read as one coherent control instead of fragmenting. Purely decorative elements (e.g. the welcome-screen pin, immediately followed by the same text as visible copy) carry an explicit empty label so they don't double-announce, and use ExcludeSemantics where appropriate.
  • Live regions for content that updates in place without a screen change: the followers hero count, and — on the Activity feed — only the top (most-recent) card, so a realtime update is announced once rather than re-announcing the whole feed on every unrelated rebuild.
  • Minimum 48dp tap targets on primary buttons (exceeds the 44pt/44px baseline) and system-driven color/typography theming.
  • Keyboard/focus wiring: explicit field-to-field sequencing (next → next → next → done, or send/done where a field submits) through the onboarding, sign-in, and workplace-change forms, so assistive-technology and hardware-keyboard users move through fields in a predictable, submit-ending order.
  • Step-by-step onboarding with per-step announcements and semantic progress indicators.
  • First automated accessibility test coverage: accessibility-guideline tests (tap-target size, verified as a genuine regression guard rather than relying on Flutter's implicit tap-target padding) and widget-level semantics tests assert the labels, live regions, and tap targets above, plus a direct WCAG contrast check on-screen — accessibility regressions here now fail our test suite instead of shipping silently.

3. Known limitations (we're honest about these)

  • The mobile app has had a code-level accessibility pass (semantic labels, live regions, tap targets, focus order, and our first automated accessibility tests — see §2) but not yet a full, dedicated on-device audit (a comprehensive screen-reader walkthrough with VoiceOver/TalkBack, dynamic-type scaling, and a real-device focus-order review). We do not yet claim full WCAG 2.2 AA conformance for the app.
  • The website targets AA but has not yet been independently audited end-to-end.
  • Some third-party or embedded content may not fully meet our target; we will address issues as we find them.
  • A formal VPAT / ACR is deferred until after the first external audit.

We will update this statement as we complete audits and close gaps.

4. Feedback & requesting help

If you hit an accessibility barrier — or need information in a different format — please tell us and we'll help and prioritize a fix:

We aim to acknowledge accessibility reports within 5 business days and to work with you on a resolution or reasonable alternative.

5. Related

Privacy Policy · Terms · Rate My Server home