a focused practice

healthcare accessibility.

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.

why healthcare is different

it isn't a UX issue.

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.

scope

what we test, in healthcare.

Six common surfaces. Each tested with the combined methodology — automated baseline, manual review, lived-experience testing.

01 · patient portals

member & patient portals.

Login, dashboard, secure messaging, scheduling, prescription refill, lab results, billing.

02 · clinical workflows

provider-side flows.

EHR integration touchpoints, clinical documentation, decision support, alerts and notifications.

03 · telehealth

telehealth platforms.

Visit join, video, captions, post-visit summary, follow-up booking. Real assistive-tech testing across all platforms.

04 · scheduling

scheduling & intake.

Online booking, pre-visit forms, insurance verification, accessibility-friendly intake patterns.

05 · pharmacy

pharmacy interfaces.

Refill portals, dose reminders, pickup notifications, controlled-substance ID verification flows.

06 · kiosks & check-in

physical-digital touchpoints.

Self-check-in kiosks, waiting-room displays, queue status screens — the touchpoints where physical and digital access meet.

three frameworks, one audit

Section 508. HIPAA. ADA.

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.

section 508

federal accessibility law.

For any healthcare technology touched by federal funding — Medicare, Medicaid, federal health programs. WCAG 2.1 AA conformance, full stop.

HIPAA intersect

privacy and accessibility, together.

Accessibility patterns and privacy patterns aren't separate. We test that screen-reader-accessible flows still preserve protected health information correctly — and vice versa.

ADA

civil-rights compliance.

Title III enforcement on healthcare digital products has been rising for a decade. We test against the standards courts are actually applying.

what we find

six patterns we see again and again.

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.

01 · captcha

captchas that break for screen readers.

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."

02 · modals

modal dialogs that lose focus.

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.

03 · date pickers

calendars that need a mouse.

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.

04 · silent errors

form errors that announce nothing.

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.

05 · voice-only verification

identity verification that requires hearing.

"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.

06 · untagged pdfs

lab results that aren't readable.

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.

None of these are hypothetical. Each is a pattern we've documented across multiple healthcare engagements. The fix is rarely complex — but you have to find it first, which is what lived-experience testing is for.
how an engagement runs

a healthcare audit takes longer.

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:

weeks 1–2

discovery & stakeholder map.

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.

weeks 3–4

automated + manual audit.

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.

weeks 5–6

lived-experience testing. the differentiator

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.

weeks 7–8

synthesis & executive readout.

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.

month 3+

remediation support & retest.

Optional but recommended. Same testers who flagged the original issues return to validate fixes. No revolving-door QA. Same eyes, same standard, same accountability.

next step

talk to us aboutyour healthcare product.

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.

healthcare accessibility checklist
patient portals · telehealth · clinical workflows · PDF