Bridging health disparities is no longer only the work of community programs and public health departments. As scheduling, results, messaging and visits move online, the design of patient-facing software decides who can use care easily and who gets left with a phone queue or nothing at all.
This guide is for health system digital leaders, compliance teams and the product teams building patient apps and portals. It covers how digital tools can widen gaps, what Section 1557 requires for language access, what the Section 504 web accessibility rule requires and when, how to collect and use social needs data, and how to measure whether a product is closing gaps rather than opening them.
What does bridging health disparities mean for digital health?
Building accessible, multilingual patient tools?
Agnotic engineers WCAG-conformant, multilingual healthcare products with health literacy and assistive technology support built in.
Bridging health disparities in digital health means designing patient technology so people with limited English, disabilities, low health literacy or unstable access to devices can use it as well as anyone else. It combines legal duties under Sections 1557 and 504 with product choices and social needs data.
Digital tools can narrow gaps: a translated reminder or a video visit can reach someone who could not travel to a clinic. They can also widen them, when the easiest route to care requires a smartphone, fluent English and good eyesight. Which outcome happens depends largely on decisions made during design and build.
How can digital tools widen health disparities?
Digital tools widen disparities when they become the main route to care but are not usable by everyone. Patients who cannot use them get slower appointments, later results and fewer reminders, even though the organization believes it has improved access.
- English-only content: Portals and apps with no translated content, or translations that stop after the login page.
- Inaccessible design: Forms that screen readers cannot read, low-contrast text and controls that need fine motor skills.
- Health literacy gaps: Results and instructions written for clinicians rather than patients.
- Device and data limits: Apps that need recent phones or large downloads, and video visits that fail on weak connections.
- Digital-only offers: Earlier appointment slots or programs available only to people who book online.
These effects are easy to miss because the people affected rarely show up in product analytics. A patient who gives up on a form in another language leaves no feedback; they simply call, arrive without paperwork or do not come at all. Teams need to look for the patients who are missing from their data, not only at those who appear in it.
What does Section 1557 require for language access?
Section 1557 of the Affordable Care Act requires covered health programs to take reasonable steps to provide meaningful access to each person with limited English proficiency who is eligible to be served or likely to be affected. Under 45 CFR 92.201, language assistance must be free, accurate and timely, and must protect the person's privacy and independence.
- Qualified interpreters: Oral interpretation must come from qualified interpreters.
- Qualified translators: Written translation must come from qualified translators.
- No family by default: Programs may not require patients to bring their own interpreter, and may rely on an accompanying adult only in emergencies or when the patient asks and the adult agrees.
- Minors: A minor child may interpret only in an emergency involving an imminent threat to safety or welfare when no qualified interpreter is available.
For software teams, this means language access is a product requirement, not a content task at the end. Language preference must be captured, stored and respected across messages, forms, results and video visits, and the interpreter request must be one tap away.
Video visits need specific design work. The platform should let a remote interpreter join the call as a third participant, show the interpreter's role to the clinician, and work for the common languages in the organization's service area. Scheduling should book the interpreter at the same time as the visit, not leave staff to arrange one on the day.
Can machine translation be used in patient tools?
Machine translation can be used, but 45 CFR 92.201 requires that when a covered entity uses it for critical content, the translation must be reviewed by a qualified human translator. Critical content includes material where accuracy is essential to the patient's care or rights.
In practice, teams use machine translation to draft content and to help with low-risk text, then route discharge instructions, consent forms, medication directions and notices of rights through human review. The content system should record which strings were reviewed, by whom and when, so a change to the English source triggers a new review.
Real-time translation of free-text messages between patients and clinicians needs particular care. A safe pattern is to flag machine-translated messages clearly, offer an interpreter for anything clinical, and avoid relying on automated translation for instructions the patient must follow exactly.
What does the Section 504 web accessibility rule require?
The Section 504 rule from HHS requires recipients of HHS funding to make their web content and mobile apps conform to WCAG 2.1 Level AA. Under 45 CFR 84.84, recipients with 15 or more employees must comply by May 11, 2027, and those with fewer than 15 employees by May 10, 2028.
The rule covers content a recipient provides or makes available, including through contractors, so third-party patient portals, scheduling widgets and telehealth apps fall within scope. Health systems should ask vendors for conformance evidence now, because contracts signed today will still be running when the deadlines arrive.
- Perceivable: Text alternatives for images, captions for video and sufficient color contrast.
- Operable: Full keyboard access, enough time to complete forms and no content that traps focus.
- Understandable: Clear labels, predictable navigation and helpful error messages.
- Compatible: Markup that assistive technologies such as screen readers can interpret reliably.
Automated scanners catch only part of what WCAG covers. Missing labels and contrast failures are easy to detect, but whether a screen reader user can actually complete an appointment booking, or whether error messages make sense, needs manual testing with assistive technology and, ideally, with disabled users themselves.
Build accessibility into the definition of done. A feature is not finished until it passes automated checks in the pipeline, a keyboard-only walkthrough and a screen reader pass on the main flows. Retrofitting an entire portal a few months before the deadline costs far more than checking each feature as it ships.
How should social needs data be collected and used?
Social needs data, such as food insecurity, housing instability, transportation barriers and utility needs, should be collected with standard screening questions, stored as coded data, and connected to referrals and follow-up. Screening without a response plan frustrates patients and staff.
- Standard screening: Use validated question sets so results can be compared across clinics and over time.
- Coded storage: Store answers and identified needs as structured data, not only in notes.
- Referral links: Connect identified needs to community resources with closed-loop tracking.
- Patient control: Explain why questions are asked and let patients decline without penalty.
- Privacy limits: Restrict who can see sensitive answers and how they are shared with partners.
Used well, this data also improves digital design. A clinic that knows many patients lack reliable data plans can offer text-based check-in and audio-only visits rather than assuming everyone has video. Transportation needs can trigger ride scheduling or a telehealth offer at booking.
What does an equity-ready patient product include?
An equity-ready patient product supports several languages end to end, meets WCAG 2.1 AA, uses plain language, works on older devices and slow connections, and always offers a non-digital route. These qualities help every user, not only those facing barriers.
- Language preference: Captured once, applied to every message, form and notification.
- Plain language: Patient-facing text written at an accessible reading level and tested with real patients.
- Light builds: Pages and apps that load on older phones and limited data plans.
- Proxy access: Safe ways for caregivers to help, with the patient's consent.
- Human fallback: A phone or in-person option for every digital task, with the same priority.
How do you know a product is closing gaps?
You know a product is closing gaps by splitting its usage and outcome measures by language, age, disability status and other demographics the organization collects. Overall adoption can rise while gaps widen, so averages alone hide the problem.
Compare portal activation, online booking, message response times and no-show rates across groups, and track how they change after each release. If Spanish-speaking patients activate the portal at half the rate of English speakers, that is a design problem to fix, not a fact to report.
This depends on good demographic and language data in the first place. Many records have blank or default values for preferred language, which makes gaps invisible. Improving how registration captures these fields, and explaining to patients why they are asked, is often the first equity project a digital team should take on.
Where digital equity efforts fall short
- Translation at the end: Content translated after launch, leaving features in English only for months.
- Audit once: An accessibility audit before launch, then no testing as new features ship.
- Vendor blind spots: Third-party widgets that are inaccessible but treated as someone else's problem.
- Screening without action: Social needs collected with no referral pathway.
- No stratified metrics: Success measured only as overall adoption.
Assign an owner. Equity work spread across compliance, marketing, IT and clinical teams tends to fall between them, while a named product owner with a small set of measures and a regular review with patient advisors can keep it moving release after release.
How Agnotic can help
Equity has to be engineered into patient tools rather than added later. Agnotic Technologies builds accessible, multilingual healthcare products that meet WCAG 2.1 AA, with language preference carried through every workflow, plain-language content and automated accessibility checks in the build pipeline.
Agnotic also builds translation workflows that route critical content to human review, social needs screening with structured data and referral tracking, and dashboards that split adoption and outcomes by language and demographic group.
Build patient tools everyone can use
Explore accessibility and inclusive care engineering, or read more practical guides from our engineers.
Related reading on Agnotic
Continue with inclusive technology, telehealth barriers, patient portals and engagement tools.
