When I fill out healthcare intake forms as a new patient, the same accessibility issues come up almost every time: unlabeled fields, required-field markers my screen reader can't pick up, date inputs I can't move focus through, and mobile buttons that only register a direct touch. Any one of them can stop me from completing my own paperwork independently.
I've written before about appointment scheduling. I'm continuing that thread here, including the intake and onboarding forms. The issues below make the process especially difficult for me as a blind person who relies on a screen reader.
Web Form Navigation
Almost every online healthcare intake process I've been through involves extensive interaction with fillable web forms. The text fields themselves often don't have appropriate labels in the code, so my screen reader doesn't announce them correctly. That leaves me guessing about what information belongs in a given field.
When I'm filling these out, I'd like to speed things up by only completing the required fields. Usually, those fields are marked visually with something like an asterisk. But my screen reader often can't tell a required field apart from a regular one, so I end up completing every single field just to be safe.
I also rely on special text field navigation commands that let me jump quickly between fields and exit form mode with a single button press. On intake forms that aren't backed by solid accessible code, those commands don't work the way they should.
Date Entry
Healthcare intake forms ask me for many dates. My date of birth, dates of specific surgeries and hospitalizations, and start and end dates for medications. The interfaces for collecting all of that vary.
The most popular one I see is a split-input text field that asks for the date in the format two-digit month, two-digit day, and four-digit year. When I try to enter text in this kind of field, my screen reader focus often doesn't advance to the next section, even though the system accepts my numbers without any error. The result is that I only end up entering the two-digit month.
There's no way for me to move screen reader focus into the other two parts of the field. It sounds like I typed everything correctly at the time, but when I go back to review the date, only the month was actually recorded.
Another issue with this interface is the default display. For demonstration purposes, the system often shows the current date in the field, and I'm supposed to clear it before entering my own information. I often can't effectively erase those default numerals using the keyboard.
The expected behavior is that typing in the field will automatically clear the pre-existing text and replace it with what I enter. Instead, I end up with some random combination of the old numbers and the new ones, completely throwing off the two-two-four calibration. The resulting date is usually wrong because of this flaw.
Another common interface combines pop-up menus for year and month selection with a calendar grid for picking the specific day, invoked by a button or text field activation. The pop-up menus usually work fine for me.
The calendar grids are where things fall apart, and for two reasons. First, moving through the grid is clunky and tedious because of its graphical, visually driven nature. Second, there's rarely any verbal indication of which date I've selected after I make a choice, which makes verifying my entry or correcting a mistake impossible.
Mobile Mishaps
Like many people, I often find myself completing these intake forms on a mobile device. I've been running into a couple of specific issues lately, and both are pretty odd.
The first has to do with entering text using the virtual keyboard. As I type, my screen reader repeatedly announces that my entry is invalid, sometimes after every single character. Of course the data will be invalid until I'm done typing it, and the repeated alerts drastically slow me down. They can even cause random focus jumps out of the field I'm working on unless I specifically refocus on the virtual keyboard between selecting a letter and double-tapping.
Even stranger, the invalid entry announcements sometimes follow me to other parts of the form that have nothing to do with text input. I might be filling out a questionnaire using selectable buttons or check-boxes and suddenly get an invalid entry announcement that interrupts my flow. There's nothing going on at that point that could possibly be invalid.
The other mobile issue I've been running into is with answer buttons. A lot of the intake process asks me questions with pre-determined responses, most commonly yes or no. The answer options are usually represented by buttons, and modern forms often advance to the next question automatically when I activate one.
For whatever reason, the system sometimes only responds to direct touch activation of an answer button. If I use manual swipes to hear the question, move through the options, and double-tap to select, it's fifty-fifty whether the interface will actually register my choice.
If I use direct touch to locate and select the same option, it works with no problem. That means I have to keep changing up my navigation style for no real reason as I move through the form.
FAQ
What accessibility issues do blind patients face on healthcare intake forms?
The biggest ones I run into are unlabeled text fields, required fields my screen reader can't identify, date inputs I can't move focus through, and mobile buttons that only register a direct touch. Each one of those has stopped me cold at some point while trying to fill out my own paperwork.
Why are date pickers hard for screen reader users?
Most date fields split into month, day, and year sections, and my screen reader focus often won't move past the first section even though the form accepts my input without an error. I end up thinking I entered the full date when really only the month got recorded.
Can't a screen reader user just ask someone for help with intake forms?
It defeats the point of a patient portal. I want to manage my own healthcare information independently, especially for anything sensitive.
Are some healthcare patient portals more accessible than others?
Yes, some portals work well enough that my screen reader stays out of my way, and others are the ones I've been describing in this post. The frustrating part is I can't tell which kind I'm dealing with until I'm already inside the form.
What would make healthcare intake forms accessible for screen reader users?
Proper labels on every field, required-field indicators that announce through a screen reader, date inputs that let focus move between sections, and mobile buttons that respond to swipe-and-double-tap the same way they respond to direct touch. None of that is exotic.
Why This Matters for Patient Independence
I hope this helps illustrate the kinds of accessibility issues I'm running into on online healthcare intake forms. Our ability to take control of our own health independently depends on the digital side of healthcare actually working for us.
If any of this resonates, UsableNet is hosting a webinar on April 29 about where healthcare websites still break for blind patients. Joe DiNero from Helen Keller Services is one of the panelists, and he uses assistive technology every day, so you'll hear some of these same issues walked through from a screen reader user's perspective.
You can reserve your spot if you want to see it in practice.
