Accessibility Statement

Our commitment

Accessibility is not a checklist at the end of a release — it is a requirement that ships with every feature. Every new product flow goes through accessibility review before general availability, and every merchant-facing surface is expected to be operable with a keyboard, usable at 200% zoom, and intelligible to a screen reader. We measure ourselves against the Web Content Accessibility Guidelines 2.2 at Level AA, and we publish our gaps rather than hiding them.

Scope of this statement

This statement applies to:

• Marketing site — paymullet.com and all public marketing pages
• Merchant Dashboard — dashboard.paymullet.com
• Hosted checkout and hosted fields — checkout.paymullet.com, and the iframe components embedded in your checkout
• Documentation — docs.paymullet.com
• Certified terminals — Clover, Valor, and EPOS devices provisioned through PayMullet. Terminal firmware accessibility (voice-guided PIN entry, tactile keypads) is provided by the hardware manufacturer; we certify that the models we ship include the listed accessibility features.

Third-party content embedded in our site (e.g., a community forum hosted by a partner) is outside this statement's direct scope; we link to partners whose accessibility meets or exceeds our own.

Standards we follow

WCAG 2.2, Level AA

The authoritative reference. We also meet most Level AAA criteria where feasible.

Section 508 (Revised, 2018)

Aligns with WCAG 2.0 AA; we exceed by targeting 2.2.

EN 301 549 v3.2.1

European harmonized standard, relevant for European Accessibility Act (EAA) obligations.

PCI-certified terminal accessibility

Devices we ship support tactile keypad, audio output (3.5mm jack or Bluetooth for headphones), and voice-guided PIN entry per Visa/Mastercard accessibility rules.

What we've built for accessibility

Keyboard operation

• Every interactive element is reachable by Tab and operable with Enter / Space
• Visible focus indicators that meet WCAG 2.4.11 (non-obscured focus)
• Skip-to-main-content link on every page
• No keyboard traps in modals, drawers, or multi-step flows — focus is restored to the invoking element on close
• Escape closes modals, drawers, and confirmation dialogs

Screen readers

• Semantic HTML first — landmark regions (header, nav, main, aside, footer) on every page
• Buttons are <button>, links are <a href> — no div-clickers
• Form controls have associated labels; error messages are programmatically linked via aria-describedby
• Live regions announce async events ("Payment processed", "Chargeback dispute submitted")
• Tested regularly with NVDA (Firefox, Chrome on Windows), JAWS (Chrome on Windows), VoiceOver (Safari on macOS and iOS), and TalkBack (Chrome on Android)

Vision, color, and contrast

• Color contrast meets WCAG AA: 4.5:1 for normal text, 3:1 for large text and UI components
• Information never encoded by color alone — status chips pair color with an icon and text label
• Dark-mode variant maintains the same contrast ratios
• Page content reflows at 200% zoom without horizontal scrolling (1280px design width)
• No fixed pixel font sizes; the UI respects the user's browser font-size preference

Motion and cognition

• prefers-reduced-motion is honored — we collapse transitions to near-instant state changes
• No autoplaying video with audio; no flashing content above the photosensitivity threshold
• Clear, plain language in the Dashboard — we avoid payments jargon without explanation
• Session timeouts show a warning with at least 20 seconds to extend, per WCAG 2.2.1

Forms and error handling

• Errors announced to screen readers immediately on submit, with focus moved to the first invalid field
• Error messages are specific and actionable ("Routing number must be 9 digits" not "Invalid")
• Confirmation patterns for destructive actions (refunds, terminal deactivation)
• Authentication code fields accept paste and do not break with autofill

Known gaps

Transparency first. We publish the gaps we know about:

How we test

• Automated: axe-core runs on every pull request against a library of critical flows; any new violation blocks merge
• Design review: Color-contrast and focus-state checks on every Figma handoff
• Manual review: Every new feature is audited with keyboard-only and screen-reader before GA
• Third-party audit: Independent WCAG 2.2 AA audit annually (most recent: February 2026)
• Usability testing with disabled users: At least twice a year via a specialist research partner

Feedback and remediation

If you encounter a barrier on any PayMullet surface, please tell us. We treat accessibility reports as priority bugs.

Please include: the URL or surface where the issue occurred, your assistive technology and browser (if any), a brief description of what went wrong and what you expected, and screenshots if helpful.

Formal complaints

If you are not satisfied with our response, you may escalate through:

• Our legal@paymullet.com team for a formal written review
• The U.S. Department of Justice's ADA information line
• Your state's disability-rights office
• (EU) Your national accessibility-monitoring body under the European Accessibility Act

Accessibility in our hiring and culture

Accessibility is owned by a cross-functional council (product, engineering, design, legal, support). Every engineer has at least one accessibility-focused objective annually. Candidate interviews offer accommodation on request; our careers site meets the same WCAG 2.2 AA target.