With the new year upon us, many people are beginning to implement their 2024 resolutions. For many, health will be the priority this year, whether making better eating choices, catching up on missed doctor appointments, or purchasing a gym membership. I must schedule a few doctor visits that I kept delaying because of the holiday season. In this post, I will narrate my way through the scheduling process for one particular provider, describing both positive and negative accessibility points. As usual, I will be exclusively covering screen reader accessibility.
A Menu Mishap
Upon launch of the healthcare provider's website, I found a homepage filled with many advertisements and unlabeled images. I began moving through the page in search of the appointment scheduling options. Reaching the bottom without seeing them, I started looking for a navigation menu to house the scheduling tools. Setting my screen reader to navigate by button only, I quickly found one labeled "Site Menu" and activated it.
The site brought me to a list of options, including:
"Schedule An Office Visit,"
"View And Print Test Results," and
"Contact The Billing Department." I quickly navigated to the scheduling choice and selected it. Then, I began to encounter a bizarre issue.
My screen reader spoke the phrase "Webpage Loaded," indicating that the appointment booking page had opened after I clicked the corresponding link in the navigation menu. On that page, my screen reader even announced a text element about holiday and weekend office closures.
However, when I began to move down the page using manual navigation, my screen reader only found the seven options in the navigation menu list. I performed a read-all screen command and began to hear the contents of the appointment scheduling page. Attempting to navigate down the page again, I encountered the same issue.
My screen reader's cursor was stuck halfway between the navigation menu and the visit scheduling page, reading content from one while moving through the other. I have not encountered a problem quite like this. As a last resort, I refreshed the page. Refreshing the page did not work.
I then got the idea to select one of the other menu options. The same happened when the page "Contact The Billing Department" opened. I got stuck in the navigation menu. For some reason, I activated the browser back system command. The site took me back to the previous page, the appointment scheduling screen.
I tried navigation again and realized with relief that my screen reader's focus cursor had finally reached the correct spot. This frustrating accessibility flaw could potentially stop a user in their tracks.
The first thing to do in the appointment scheduling process was to enter my name, contact information, and date of birth to confirm prior registration in the system. Though all text fields were labeled, the labels were incredibly odd.
Here is an example from the "First Name" text field:
"First Given Name, This Is Where You Should Enter Your First Given Name, No Altered Names."
I couldn't help laughing to myself as I heard these labels. While I appreciated that they were there, they needed to be shorter and more clunky, slowing me down. However, I completed the form and continued to the next page, which I assumed would allow me to choose an appointment date and time.
At this point, I was unimpressed with the site's overall accessibility. So far, I have completed all of the steps in the process, but I still need to complete it. However, I would realize that I had not seen anything yet. I continued to the next page, believing it would select a day and time for my appointment. That is when another accessibility challenge happened.
The very second the next page loaded, my screen reader started speaking the word "Frame" repeatedly with almost no pause in between. The usual command that pauses speech did Nothing. I tried refreshing the page but with no results. Navigation was impossible because my screen reader's vocabulary seemed to be reduced to one word. Nothing I did worked, not disabling and reenabling the screen reader.
Finally, I quit the browser to stop my screen reader from repetitively shouting "Frame" at me. Hoping this was a one-time glitch, I rebooted my machine and restarted the process. However, I was not surprised when the same problem occurred in the same place. It was a defect with the site's accessibility that I had never encountered before. At this point, I abandoned my mission. I will have to make a phone appointment this time.
Why Accessibility Testing is Imperative
If the site owners used an accessibility testing program, many flaws could be found and fixed. The site owners would likely need manual or user testing and automated testing to identify some of the issues. You can't rely on AI to understand or necessarily tell you what the long labels are odd for a user to hear instead of helpful, for example. As frustrated as I was, I could not help chuckling to myself occasionally due to the sheer weirdness of some of these flaws.
Unfortunately, it doesn't seem like accessibility is a priority for this website, which is a disappointing revelation for a healthcare site. While I pride myself on being a problem solver, I couldn't get the site to work at the end of the day despite much time and trial and error. The result of a site with this many flaws is that it is unusable for patients like me.