member & patient portals.
Login, dashboard, secure messaging, scheduling, prescription refill, lab results, billing.
Patient portals. Clinical workflows. Telehealth. Member services. Accessibility under Section 508 and HIPAA and ADA, together. Real disabled testers across the actual patient journey — not just compliance scanning.
An inaccessible patient portal isn't a usability problem. It's a person who can't refill a prescription. It's a deaf patient who can't book a follow-up after an ER visit. It's a screen-reader user locked out of their own lab results.
We test healthcare digital products with disabled people who use those products in real life — not in a lab, not on a sample task, but on the actual journey a patient or provider takes. The findings travel up the org chart faster when leadership hears the gap in a tester's own voice.
Six common surfaces. Each tested with the combined methodology — automated baseline, manual review, lived-experience testing.
Login, dashboard, secure messaging, scheduling, prescription refill, lab results, billing.
EHR integration touchpoints, clinical documentation, decision support, alerts and notifications.
Visit join, video, captions, post-visit summary, follow-up booking. Real assistive-tech testing across all platforms.
Online booking, pre-visit forms, insurance verification, accessibility-friendly intake patterns.
Refill portals, dose reminders, pickup notifications, controlled-substance ID verification flows.
Self-check-in kiosks, waiting-room displays, queue status screens — the touchpoints where physical and digital access meet.
Healthcare accessibility sits at an unusual three-way intersection: federal accessibility law (Section 508), patient-information privacy (HIPAA), and civil-rights guarantees (ADA). Our audits address all three in a single engagement.
For any healthcare technology touched by federal funding — Medicare, Medicaid, federal health programs. WCAG 2.1 AA conformance, full stop.
Accessibility patterns and privacy patterns aren't separate. We test that screen-reader-accessible flows still preserve protected health information correctly — and vice versa.
Title III enforcement on healthcare digital products has been rising for a decade. We test against the standards courts are actually applying.
Healthcare digital products fail in specific, recurring ways. These are the failures most likely to lock a real patient out of real care — the ones a scanner won't catch and a healthy QA team won't notice.
Visual challenges with no functional audio alternative. Audio challenges with no functional visual alternative. Together: a verification step that locks out blind and deaf users while pretending to be accessible because "both options exist."
Appointment scheduling, prescription refill, secure messaging — all live in modals. When focus isn't trapped on open or returned on close, keyboard users get lost. They don't know which step they're on, or how to escape.
Custom date pickers without keyboard support are everywhere in patient booking flows. A screen-reader user can read every appointment slot but can't select one. They give up and call — except the IVR has the same problem.
A red border appears on a wrong-format insurance number. No aria-live, no programmatic association, no message read to the screen reader. The user knows something failed only because the submit button stays inert.
"We've called the number on file with a verification code. Please enter it below." For a deaf patient, that's not a verification step — it's a wall. The same step usually exists for blind users in the form of an inaccessible OTP screen.
Discharge instructions, lab reports, billing statements — distributed as PDF without tagged structure, reading order, or table semantics. A screen reader gets a wall of unstructured text. The patient gets a document they technically have access to, but can't actually read.
A typical web engagement runs 4–6 weeks. Healthcare runs longer because the surface area is wider, the stakeholders are more numerous, and the regulatory overlay (508 + HIPAA + ADA) requires more careful framing. A typical shape:
Identify in-scope surfaces (patient portal, clinical, telehealth, kiosk). Confirm regulatory framework. Map stakeholders: product owner, clinical lead, compliance officer, legal, accessibility champion if one exists.
Baseline scan across all surfaces. Expert WCAG 2.1 walkthrough. Findings catalogued by surface, severity, and regulatory exposure — so an executive can read down to the rows that matter for their own accountability.
Real disabled patients (or providers, for clinical workflows) on the real product, doing real tasks. Sessions recorded with permission. The findings that change a budget conversation come from this phase, not the audit.
Findings prioritized by patient impact, regulatory exposure, and remediation cost. Executive readout deck. Compliance-officer-friendly summary. Engineering-team-friendly issue list. Same content, three audiences.
Optional but recommended. Same testers who flagged the original issues return to validate fixes. No revolving-door QA. Same eyes, same standard, same accountability.
A short scoping call. Tell us about the surface (portal, EHR, telehealth, intake), the regulatory context, the disability categories you're worried about. We'll tell you what an engagement would look like.