Your Login Page Is Failing Your Sickest Patients

Picture this: An 78-year-old woman with arthritis tries to book an appointment through her hospital's patient portal. The login button is 30 pixels wide. She misses it three times. The password field blocks paste, so she cannot use her password manager. She has to type her 16-character password manually, one painful keystroke at a time. Then a CAPTCHA pops up asking her to identify traffic lights in blurry photos. She gives up. She calls the hospital instead, waits 40 minutes on hold, and takes up a phone line that someone else needed.

Now picture this: A man with early-stage dementia tries to access his medication list. He cannot remember his password. The "Forgot Password" flow sends a code to his email, but he cannot remember his email password either. He misses a dose because he could not check what time to take his medication.

These are not edge cases. These are your users. The digital health user base skews older than the general internet population. Age-related impairments — declining vision, reduced motor skills, cognitive changes — are not exceptions in healthcare. They are the norm. If your app does not work for these people, your app does not work.

Your Buttons Are Too Small

WCAG 2.5.8 requires a minimum target size of 24x24 CSS pixels. For general web apps, that is fine. For healthcare apps used by elderly patients with arthritis, Parkinson's, or reduced dexterity? It is not enough.

I recommend 44x44 pixels minimum for all interactive elements in patient-facing healthcare apps. 48x48 is even better. That is not my opinion — it is the original Apple Human Interface Guideline for touch targets, and it was designed for healthy adults with normal motor skills.

Think about who is using your app. People with tremors. People with swollen joints. People using their phone with one hand while holding a walker with the other. A 30-pixel button is not just inconvenient for them. It is exclusionary.

Stop Using Drag and Drop

This one drives me crazy. I still see healthcare apps that use drag-and-drop to reschedule appointments or reorder medication lists. The "press, hold, move, release" gesture is one of the hardest motor tasks you can ask of a user. For someone with Parkinson's or arthritis, it is essentially impossible.

WCAG 2.5.7 is clear about this: if an action requires dragging, you must provide a simple pointer alternative. Up/Down buttons. A "Move to" dropdown. A tap-to-select, tap-to-place flow. Anything that does not require holding and dragging.

The fix is easy. The failure to implement it is a choice. And in healthcare, it is a choice that locks out the patients who need the technology most.

Your Text Is Too Small and Too Faint

Presbyopia — age-related farsightedness — affects nearly everyone over 40. By 65, reading small text without magnification is difficult for most people. If your patient portal uses 14px body text with a contrast ratio of 3.5:1, you have made a design choice that excludes the majority of your user base.

Let People Scale Text

Your app must support text scaling up to 200% without breaking the layout. No horizontal scrolling. No overlapping elements. No content that disappears. This is a WCAG requirement, but more importantly, it is a basic respect issue. If a patient needs larger text to read their medication instructions, the app should not punish them with a broken layout.

Contrast Is Not Negotiable

Stick to WCAG AA standards: 4.5:1 contrast ratio for normal text. But for critical information — dosage instructions, allergy warnings, "High Blood Pressure" alerts — aim higher. Go for AAA at 7:1. When the information is about patient safety, you want it visible even to users with cataracts or low vision.

I have seen patient portals with light gray text on a white background. In a design review, someone probably said it looked "clean and modern." For a 72-year-old with early cataracts, it looks like a blank page.

Your Login Page Is a Cognitive Test

WCAG 2.2 introduced the "Accessible Authentication" criterion (3.3.8), and it is one of the most important additions for healthcare. Here is the core idea: logging in should not require a cognitive test.

Think about what a typical login requires: remember a username (or which email you used), remember a complex password (uppercase, lowercase, number, special character, exactly 12-16 characters), then prove you are human by identifying boats in grainy photos.

For someone with dementia, a traumatic brain injury, or age-related memory loss, this is an insurmountable barrier. They literally cannot remember the password. They literally cannot solve the CAPTCHA. Your security measures have locked the most vulnerable patients out of their own health information.

Support Password Managers Properly

This is the lowest-hanging fruit. Make sure your login fields use standard HTML attributes:

<input type="text" autocomplete="username" name="username">
<input type="password" autocomplete="current-password" name="password">

These attributes tell password managers: "This is a login form. Please offer to fill it." The password manager remembers the credentials so the patient does not have to. The cognitive burden drops to zero.

And for the love of all that is good: never block paste in password fields. Some developers do this thinking it improves security. It does not. What it does is force users to manually type complex passwords, which increases errors for everyone and makes login impossible for users who rely on password managers due to cognitive impairment.

Move to Passkeys

This is where I get opinionated. Passkeys (WebAuthn) are the future of healthcare authentication, and we should be moving there as fast as possible.

A passkey uses device biometrics — FaceID, TouchID, a fingerprint sensor. The patient authenticates with a glance or a touch. No password to remember. No CAPTCHA to solve. No codes to transcribe from a text message.

For a patient with dementia, the difference between "type your 14-character password and solve this puzzle" and "look at your phone" is the difference between accessing their health data and not. That is not a marginal improvement. That is a transformation.

Fix Your CAPTCHA

If you absolutely need bot protection (and you might not — rate limiting and honeypot fields handle most cases), do not use image recognition CAPTCHAs. They are a cognitive test. They discriminate against users with cognitive impairments, visual impairments, and anyone over 70 with declining pattern recognition.

Use alternatives: a simple "I am human" checkbox (like reCAPTCHA v3, which scores behavior invisibly), or fall back to two-factor authentication for suspicious logins. These approaches provide security without requiring the user to pass a cognitive test.

Focus Indicators: The Invisible Cursor

For users navigating by keyboard — which includes screen reader users, people with motor disabilities who use switch devices, and many elderly users who find mice difficult — the focus indicator is their cursor. It tells them where they are on the page.

Most browsers have default focus indicators that are barely visible. Chrome's thin blue outline disappears against many backgrounds. That is not good enough for healthcare.

Make Focus Obvious

Customize your focus styles. Make them thick, high-contrast, and unmistakable:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Three pixels wide. High-contrast blue. Two pixels of offset so it does not crowd the element. When a user tabs through your form, they should always know exactly which field is active. If they have to squint or guess, you have failed.

Do Not Hide the Focus Behind Sticky Elements

WCAG 2.4.11 says the focused element must not be obscured by other content. This sounds obvious, but I see it violated constantly. A user tabs through a form. The focused input scrolls behind the sticky header. Or a cookie banner covers it. Or a chat widget sits on top of it.

The user is now interacting with something they cannot see. In a medical form — where accuracy matters — this is dangerous. Test your keyboard navigation. Tab through every form on your site. Watch for moments where the focused element disappears behind a fixed element. Fix every single one.