Accessibility Statement

Part 1. Accessibility Statement (public page)

Statement date: [EFFECTIVE DATE] | Last reviewed: [EFFECTIVE DATE] | Version: [VERSION]

1. Our commitment

WellPeps wants everyone to be able to use our website and our patient portal, including people with disabilities. Information about your health should not depend on how you see, hear, move, think or use technology. We are working to make our website easier to use for everyone.

2. The standard we aim for

We aim to meet the Web Content Accessibility Guidelines (WCAG) [2.1] Level AA. WCAG is the widely used standard for accessible websites. It is published by the World Wide Web Consortium (W3C).

3. Where we are today

We have not yet had an independent accessibility expert test our website, so we cannot say how well it meets WCAG [2.1] Level AA. We plan to have it tested by [AUDIT TARGET DATE]. When we do, we will update this statement with the results, including any problems we find and when we plan to fix them.

What we have built in. Our website includes:

• A “Skip to content” link at the top of each page.
• Pages that are marked as English and have a main content area, so that screen readers can identify them.
• Text names on icon-only buttons, such as the buttons that open and close the chat window.
• Support for the “reduce motion” setting on your device.
• Pop-up windows and the chat window that you can close with the Escape key.
• Form messages (such as errors and “thank you” notes) that are marked so screen readers can announce them.

4. Known limitations

Because we have not had an audit yet, this list is not complete. We know of these areas that may be hard to use:

• PDF guides. Our free Smart Patient Guides are PDF files. We have not tested them with screen readers, and some parts may not be accessible. If you need another format, such as plain text or large print, email [SUPPORT EMAIL]. We will reply within [2 business days] and send the guide in a format you can use within [5 business days].
• The WellPeps assistant. The chat window is a new feature. We have not yet tested it with screen readers or voice control.
• Our patient portal and checkout. See section 5.
• Other pages. We have not tested every page. Some images, forms, colors or layouts may be hard to use for some people.

5. Content from other companies

• Patient portal, intake forms and checkout. These run on a technology platform provided by an independent company and appear under our name at portal.wellpeps.com. We write our own forms and use our own branding, but we do not control how the platform is built. We will ask the provider about its accessibility and include the portal and checkout in our audit.
• Pharmacies, laboratories and payment services. They run their own websites and portals and have their own accessibility practices.
• Fonts. Our text fonts are served from our own site. If the fonts do not load, your browser uses a standard font and the page still works.

6. How to get help or give feedback

If you cannot use part of our website or portal, or you want information in another format, tell us:

• Email: [SUPPORT EMAIL]. Support hours are Monday to Friday, 9 a.m. to 6 p.m. Eastern time.
• Mail: WellPeps, a Wyoming corporation, [BUSINESS ADDRESS]
• Phone: [SUPPORT PHONE AND HOURS, ONLY IF LIVE]

Please tell us the page or address, what went wrong, the device, browser or assistive technology you use, and how you would like to get the information. We will reply within [2 business days] and work with you to find another way to get the information or service. We cannot promise a specific alternative until we understand what you need.

Please do not put health details in an email. Email is not a secure way to send them. For medical questions, use the patient portal at [PORTAL URL]. In an emergency, call 911.

7. If you are not satisfied

Ask for a second review by [COMPLIANCE OFFICER]. We will answer within [10 business days].

8. About this statement

We review this statement at least once a year, after any major change to our website, and after each accessibility audit.

Technical and drafting notes

Part 2. Internal appendix for whoever commissions the audit (remove before publishing)

A. Before you publish

1. Commission the audit below and book a date. Publish the “plan to have it tested by” sentence only with a real date.
2. Verify each “built in” item in section 3 on the live site. Delete any that fails.
3. Make [SUPPORT EMAIL] a monitored mailbox, assign an owner, and train support on the feedback log (section F).
4. Decide what alternative formats WellPeps can really deliver and by when.
5. Remove this Part 2 from the page you publish.

B. Audit scope

C. Audit method and deliverables

• Target: WCAG [2.1] Level AA, and report separately any WCAG 2.2 Level AA gaps.
• Methods: automated scans (for example axe, Lighthouse, WAVE); manual keyboard testing; screen readers (for example NVDA with Firefox or Chrome, JAWS with Chrome, VoiceOver with Safari on Mac and iPhone, TalkBack with Chrome on Android); zoom and magnifier; voice control; forced-colors and reduced-motion settings; testing by people with disabilities if the budget allows.
• Sampling: follow the WCAG evaluation method (WCAG-EM): define scope, explore, choose a representative sample, audit, report.
• Deliverables: a report with each issue’s WCAG criterion, severity, steps to reproduce and a recommended fix; an accessibility conformance report (VPAT) for the website and, if possible, the portal; a retest after fixes.
• Cadence: retest after fixes, re-audit once a year and after any major redesign.

D. Remediation checklist (for the development and content teams)

Criteria in brackets are WCAG success criteria; those marked “2.2” are new in WCAG 2.2 Level AA.

Perceivable

☐ Every informative image has useful alt text; decorative images have empty alt text (1.1.1).

☐ Video has captions and a transcript; audio has a transcript (1.2.1, 1.2.2).

☐ Headings, lists, tables and landmarks use real HTML, and the reading order matches the visual order (1.3.1, 1.3.2).

☐ Pages work in portrait and landscape (1.3.4). Form fields use the right autocomplete values (1.3.5).

☐ Color is never the only way to show meaning (1.4.1).

☐ Text contrast is at least 4.5 to 1, or 3 to 1 for large text (1.4.3). Controls and icons are at least 3 to 1 (1.4.11). Include text over gradients and photos, fine print, and placeholder and disabled text.

☐ Text resizes to 200%, and the page reflows at 320 CSS pixels wide without two-way scrolling (1.4.4, 1.4.10). Changing text spacing does not break the layout (1.4.12).

☐ No important text is an image (1.4.5). Content that appears on hover or focus can be dismissed and stays visible (1.4.13).

Operable

☐ Everything works with a keyboard alone, with no keyboard trap (2.1.1, 2.1.2). Single-key shortcuts can be turned off (2.1.4).

☐ A skip link works on every page (2.4.1). Each page has a clear title (2.4.2). Focus order makes sense (2.4.3). Link text makes sense out of context (2.4.4). Headings and labels describe their topic (2.4.6).

☐ Keyboard focus is always visible (2.4.7) and never hidden behind a sticky bar, banner or the chat button (2.4.11, 2.2).

☐ Moving, scrolling or auto-updating content that lasts more than 5 seconds can be paused (2.2.2). Animations respect reduced motion. Nothing flashes more than three times a second (2.3.1).

☐ Time limits, such as portal sessions or checkout, warn the person and can be extended (2.2.1).

☐ Touch targets are at least 24 by 24 CSS pixels (2.5.8, 2.2). Anything done by dragging has another way to do it (2.5.7, 2.2). Visible labels match the accessible names (2.5.3).

Understandable

☐ The page language, and any passage in another language, is marked (3.1.1, 3.1.2).

☐ Navigation and repeated parts are consistent (3.2.3, 3.2.4). Help is in the same place on every page (3.2.6, 2.2).

☐ Forms have visible labels and clear instructions (3.3.2). Errors are described in text and say how to fix them (3.3.1, 3.3.3). Payment, consent and e-signature steps can be reviewed or reversed (3.3.4).

☐ People are not asked to retype information already given in the same flow (3.3.7, 2.2). Sign-in works with password managers and paste and does not require solving a puzzle (3.3.8, 2.2). Avoid CAPTCHA; the hidden “honeypot” field is fine.

Robust

☐ Every control has a name, role and state that assistive technology can read: menus, accordions, dialogs, switches and the chat window (4.1.2).

☐ Status messages, such as form success or error, chat replies and loading, are announced without moving focus (4.1.3).

Documents, email and text

☐ PDFs are tagged, with a title, language, reading order, bookmarks, alt text for images, real text (not pictures of text) and accessible tables. Each guide also has an HTML or plain-text version.

☐ Emails use real text and headings, alt text on images, strong contrast, a plain-text part and descriptive link text.

☐ Texts avoid emoji or symbols that carry meaning and avoid abbreviations that screen readers read badly.

Process

☐ Add automated accessibility checks (for example axe) to the build and test pipeline and block releases with new serious issues.

☐ Write a “definition of done” for accessibility for every new page and component, and keep a list of known issues with owners and dates.

☐ Ask every vendor for its accessibility conformance report before signing, and add an accessibility clause to new vendor terms.

☐ Do not buy or install an “accessibility overlay” as a substitute for fixing the site.

☐ Train design, engineering, content and support staff, and name an owner ([COMPLIANCE OFFICER] or a delegate).

☐ Retest after fixes, re-audit every year and after major redesigns, and update the statement each time.

E. Candidate issues noticed while drafting (unverified, from reading the source; confirm in the audit)

F. Accessibility feedback log (template)