1. Our Commitment
Accessibility is not only a legal obligation under Title III of the Americans with Disabilities Act and Section 508 of the Rehabilitation Act; it is a correctness property of the product. The hosted card-update page in particular is used by our customers’ customers, who did not choose this software and cannot work around it. If that page is not usable with a screen reader, a payment simply fails.
2. Conformance Standard
We target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, published by the W3C. WCAG 2.1 AA is the standard U.S. courts and the Department of Justice most commonly reference in ADA web-accessibility matters, and it is the technical basis of Section 508.
3. Conformance Status
WCAG defines three levels of conformance claim. Ours is partially conformant: most of the product meets WCAG 2.1 AA, but some content does not yet fully conform. We state this per surface rather than as a single blanket claim, because a blanket claim would be less useful and less true.
| Surface | Status | Notes |
|---|---|---|
| Marketing site and legal pages | Partially conformant | Semantic landmarks, keyboard navigable, AA contrast in body text. |
| Hosted card-update page (/pay) | Partially conformant | Highest-priority surface. Card fields are rendered by Stripe Elements — see Section 7. |
| Dashboard | Partially conformant | Core flows are keyboard operable; see the known limitations in Section 6. |
| Charts and analytics | Not fully conformant | Data is also available as CSV and PDF export, which is the accessible equivalent. |
| Drag-and-drop campaign builder | Not fully conformant | See Section 6 — a keyboard-accessible alternative is the current priority. |
4. Measures Taken
- Accessibility is considered during design and review, not audited at the end;
- Interactive components are built on an accessible primitive library that ships correct ARIA semantics and focus management;
- Colour contrast is checked against AA thresholds for body text and interface elements;
- Pages use semantic HTML — real headings, lists, landmarks, and form labels;
- Text alternatives are provided for meaningful images; decorative images are hidden from assistive technology.
5. Accessibility Features
- Keyboard navigation for all primary flows, with a visible focus indicator;
- Screen reader support through semantic markup and ARIA labelling on custom controls;
- Zoom and reflow to 200% without loss of content or functionality;
- Form errors announced in text and associated with their field, never signalled by colour alone;
- Responsive layout that works at small viewport sizes and with increased system font size;
- No autoplay media and no content that flashes more than three times per second.
6. Known Limitations
We would rather list these than imply they do not exist. If one blocks you, tell us and we will provide the outcome another way while we fix it.
- Drag-and-drop campaign builder. Reordering retry steps and email sequences currently requires a pointer. Contact support and we will configure a sequence on your behalf. A keyboard-operable alternative is our highest-priority accessibility work item.
- Analytics charts. Trend charts convey information visually. The same data is available through CSV and PDF export, which screen readers handle well.
- Complex data tables. Some dashboard tables scroll horizontally on small viewports, which can make row-header association harder to follow.
- PDF exports. Generated PDFs are not fully tagged for accessibility. Request the same data as CSV.
7. Third-Party Content
Parts of the interface are rendered by third parties whose markup we cannot modify — most significantly the Stripe Elements card fields on the card-update page. We rely on Stripe’s own accessibility work there and report issues to Stripe when we find them. If a Stripe-rendered component blocks you from completing a payment update, contact us and we will arrange an alternative route for that payment.
8. Accessible Recovery Emails
Recovery emails sent through the Service use semantic HTML with a plain-text alternative part, descriptive link text rather than “click here”, and sufficient contrast in the default templates.
If you customise a template, you are responsible for the accessibility of what you send. Keep the plain-text alternative, do not convey meaning by colour alone, and avoid putting essential information only inside an image — many recipients block remote images by default in any case.
9. Feedback & Accommodations
If you encounter a barrier, tell us. Include the page or feature, what you were trying to do, and the assistive technology and browser you were using — that triple is usually enough for us to reproduce it.
Payment Recovery System — Accessibility
Email: accessibility@paymentrecoverysystem.com
We acknowledge within 2 business days and give a substantive response, including a remediation plan or a workaround, within 5 business days.
If a barrier prevents you from completing a task, we will complete it with you directly at no charge while the underlying issue is fixed.
10. Formal Complaints
If our response does not resolve your concern, you may escalate to legal@paymentrecoverysystem.com. You also retain the right to file a complaint with the U.S. Department of Justice Civil Rights Division, or with the equivalent authority in your jurisdiction. Contacting us first is not a precondition to doing so.
This statement was last reviewed on July 28, 2026 and is reviewed at least annually, and after any significant interface change.