Building for everyone who needs us
SRS is committed to making our websites accessible to people with disabilities. This Statement explains the standard we align with, where we currently fall short, how to report a barrier, and how we’re working to improve.
SRS Web Solutions believes that healthcare technology should be usable by everyone—including people who use assistive technologies such as screen readers, keyboard-only navigation, screen magnifiers, voice input, or other accessibility tools.
We’re publishing this Statement to be honest about where we are: we align with WCAG 2.2 Level AA as our target standard, we have not completed a formal third-party audit, and we know we have work to do. The sections below describe what we currently meet, what we don’t, and how to tell us when we’re falling short.
Our Commitment
SRS Web Solutions, Inc. (“SRS”) is committed to making our websites and digital experiences accessible to people with disabilities. We believe that accessibility is a continuous practice rather than a finish line, and we treat barriers we encounter or that are reported to us as defects to be fixed.
This Statement reflects our current accessibility posture as of the “Last Updated” date. We will revise it as our practices change.
Standards We Align With
SRS aligns its website-design and content practices with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, published by the World Wide Web Consortium (W3C). WCAG 2.2 AA is widely referenced by U.S. regulators (including the Department of Justice and HHS) as the de facto benchmark for digital accessibility, and it is the standard most commonly required by enterprise customers and government contractors.
We use WCAG 2.2 AA as a design and review target. We have not engaged a third-party auditor to certify conformance, and we are intentionally careful about how we describe our posture. Specifically, we describe our work as aligning with WCAG 2.2 AA rather than claiming full conformance, because:
- WCAG conformance is a snapshot at a moment in time, and websites change continuously;
- We have not completed a formal third-party audit, and we will update this Statement when we do; and
- Honest disclosure of our actual posture is more useful to users with disabilities than aspirational claims.
For more information about WCAG 2.2 AA, see the W3C’s published guidance at w3.org/WAI/standards-guidelines/wcag.
Scope
This Statement applies to the public, marketing-facing portions of:
- srswebsolutions.com
- mconsent.net
- caretap.net
- any other public marketing site that SRS owns and that links to this Statement
3.1 Out of scope
This Statement does not cover:
- Customer-facing applications (the mConsent practice software, the Caretap operations platform, mPayr payment workflows, and the Zaha AI receptionist). Accessibility for these products is described separately in our product accessibility documentation, which is provided to customers on request and is summarized in Section 9.
- Patient-facing intake and consent flows hosted at securehealthform.com and similar end-user surfaces. Those interfaces have their own accessibility considerations and are tested in conjunction with our customer practices.
- Third-party content embedded in our websites (for example, embedded video players, calendar booking widgets, third-party form processors, and live-chat widgets). See Section 7.
- Customer-authored content displayed on our customers’ own customer-branded surfaces.
Conformance Posture
The status block below summarizes our current accessibility posture. We will update it when our practices change or when we complete a formal audit.
“Aligned with” is not the same as “fully conformant.” We choose this language deliberately. If you encounter a barrier on our websites, that does not reflect a gap between our description and reality — it reflects work still to be done. Please tell us about it using the mechanism in Section 8.
Known Limitations
We disclose known limitations honestly so that visitors with disabilities know what to expect. The list below is not exhaustive and will evolve as we identify and remediate issues.
PDF documents and white papers
Some PDF documents on our Websites—particularly older white papers, case studies, and downloadable datasheets—may not be fully tagged for screen-reader navigation. If you need an accessible alternative version of any document, contact us using the mechanism in Section 8 and we will provide one.
Embedded video
Marketing videos embedded on our Websites may not always include accurate captions, transcripts, or audio descriptions. We are working toward captioning all video content and providing transcripts on request.
Third-party widgets
Our Websites use third-party widgets for forms, scheduling, and chat (described in our Sub-Processor List). These widgets are produced by their respective vendors and may not always meet WCAG 2.2 AA. Where a third-party widget creates a barrier, we will work with the vendor to remediate or, where necessary, provide an alternative way to complete the same task.
Color contrast in some components
Some marketing components, particularly hover states and lower-emphasis decorative elements, may not yet meet the WCAG 2.2 AA contrast threshold of 4.5:1 for normal text or 3:1 for large text and graphical elements. We review contrast as part of new template development and remediate identified issues.
Older content and legacy templates
Pages that pre-date our current design system may not benefit from the accessibility patterns we have built into newer templates (such as consistent landmark structure, skip-to-content links, focus indicators, and keyboard-friendly interactive elements). We migrate older content progressively as we update or replace those pages.
Cookie banner and consent flows
The cookie consent banner is operated by a third-party consent-management platform (Termly). Its visual design and keyboard interaction are governed by that vendor’s implementation. If you encounter an accessibility barrier with the banner, contact us and we will work with Termly to remediate.
Accessibility Features
We design our Websites with the following accessibility patterns and practices, recognizing that no single design choice covers every disability or assistive technology:
- Semantic HTML structure — use of headings, landmarks, lists, and ARIA roles where appropriate to support screen-reader navigation.
- Keyboard navigation — interactive elements (links, buttons, form fields) are reachable using the Tab key, with visible focus indicators.
- Skip-to-content links on long pages, allowing keyboard users to bypass repeated navigation.
- Descriptive link text rather than “click here” or “read more,” so the destination of each link is clear out of context.
- Alternative text for informative images, with decorative images marked accordingly so screen readers do not announce them unnecessarily.
- Form labels and error handling programmatically associated with the corresponding fields, so assistive technologies can convey them.
- Resizable text — pages remain usable at 200% zoom in modern browsers.
- Color and contrast — primary text and interactive elements are designed to meet the WCAG 2.2 AA contrast threshold.
- Reduced motion — we respect the
prefers-reduced-motionsystem preference where animations are present. - Responsive layout — pages adapt to phone, tablet, and desktop viewports without content reflow that breaks legibility.
Third-Party Content
Our Websites include content and functionality provided by third parties listed in our Sub-Processor List. SRS does not control the underlying source code of third-party widgets, embedded video players, or external sites that we link to. The accessibility of that content is governed by the third party’s own practices.
We make reasonable efforts to:
- select third-party vendors who publish their own accessibility commitments;
- configure their products in the most accessible mode available;
- provide alternative ways to accomplish key tasks (such as contacting us by phone or email) when a third-party widget creates a barrier; and
- raise vendor-side issues with the third party when reported.
Reporting an Accessibility Barrier
If something on our Websites isn’t accessible to you, please tell us.
We treat accessibility reports as defects. Reaching out doesn’t put your inquiry into a queue or trigger a generic auto-response — it goes to a person on our team who will work with you.
8.1 How to report
Please use any of the following channels:
- Email: accessibility@srswebsolutions.com
- Phone: 877-203-6767
- Postal mail: SRS Web Solutions, Inc., Attn: Accessibility, 6885 139th LN NW, Suite 100, Ramsey, MN 55303
8.2 Information that helps us respond
To help us reproduce and fix the issue, please include (where possible):
- the URL of the page where you encountered the barrier;
- a brief description of what you were trying to do and what didn’t work;
- the assistive technology, browser, and operating system you were using; and
- your preferred way for us to follow up with you.
You don’t have to provide all of this—tell us as much as you’re comfortable sharing.
8.3 Our response commitment
We will:
- Acknowledge your report within 5 business days;
- Investigate the barrier and provide a response on next steps;
- Remediate issues that are within our control on a priority basis, with timelines that depend on complexity; and
- Provide an alternative way to access the content or complete the task while we work on a fix, where one is reasonably available.
8.4 Alternative formats and reasonable accommodation
If you need information from our Websites in an alternative format—large print, accessible PDF, plain-text email, or a phone conversation walking you through specific content—contact us at accessibility@srswebsolutions.com and we will provide it.
Customer Product Accessibility
The accessibility posture of our customer-facing products (mConsent, Caretap, mPayr, and Zaha AI) is described separately from this website Accessibility Statement. Healthcare and home care customers—and the procurement and security teams that evaluate our products—may request the following:
- Voluntary Product Accessibility Template (VPAT) / ACR. A standard accessibility conformance report describing how the product conforms to WCAG 2.1 / 2.2 and Section 508 success criteria, available on request to qualified customers and prospects.
- Patient-facing form accessibility documentation. Specific guidance for the patient intake, consent, and check-in flows that practices deploy to their patients.
- Caregiver-facing app accessibility documentation. For Caretap, specific guidance covering the caregiver mobile experience and EVV workflows.
- Patient and caregiver alternative-format support. For end users (patients, caregivers) who cannot complete an intake or visit verification because of an accessibility barrier, alternative paths supported by the practice or agency.
To request product accessibility documentation, contact accessibility@srswebsolutions.com with the product name and your role (customer, prospect, or end user) and we will respond within 5 business days.
Updates to This Statement
We will update this Statement when our accessibility practices change— for example, when we complete a third-party audit, change our target standard, or materially update the Known Limitations section. The “Last Updated” date at the top of this Statement reflects the most recent revision.
Prior versions are available on request from accessibility@srswebsolutions.com.
Contact
For accessibility reports, accommodation requests, or product accessibility documentation, please contact us using any of the channels below.
Mailing Address
SRS Web Solutions, Inc.
Attn: Accessibility
6885 139th LN NW, Suite 100
Ramsey, MN 55303
United States