One of my favorite aspects of the holiday season is the variety of sweets and treats my family enjoys during the festivities. When I discovered that my mother was planning to make her delicious peanut butter bars for Christmas but did not have the key ingredient, I immediately turned to the internet in search of the needed item: peanut butter baking chips. I fortunately found them at a local grocery retailer that offers product delivery directly from the store. I placed an order before the chips went out of stock because supply seems low this year.
In the remainder of this blog, I will bring the reader through the order process, pointing out both good and bad accessibility. The experience was very good, one of my best recently.
I will use an iPhone running Voiceover in this example to change things up. Voiceover is a touch-based screen reader exclusive to Apple products that combines swipe gestures and double taps for control and input. I already had the grocery store’s app installed on my phone. I figured that this is a task that many people probably perform on mobile devices due to convenience and ease of delivery notification management.
Upon launching the grocery store app, I immediately located the search field at the top of the screen via direct touch. After inputting my search criteria, I was brought to the product results page. I began moving through the list in search of the peanut butter chips. I noticed that the screen reader spoke each product listing as one web element instead of a series of separate web elements that must be navigated through individually.
For example, the first search result option was read aloud as “Hershey’s Milk Chocolate Candy Melts, $3.98, In Stock, Available For Pick-up Or Delivery.” The item name, price, and availability were spoken as one self-contained entry.
In most other cases, I must move through and hear each characteristic of the product listing separately. This accessible design choice significantly improved the speed and efficiency of my browsing experience.
Once I found the peanut butter chips, I proceeded to the item details page. I set my screen reader’s navigation rotor to filter by button and began to swipe around. I encountered two unlabeled buttons. I tried using direct touch again but had the same problem. Unlabeled buttons are an unacceptable accessibility defect that can cause users to abandon their browsing session. Fortunately, I was somewhat familiar with this particular app, so I assumed that the first button I was looking for was “Add To Cart.”
My guess proved correct, affirmed by spoken feedback that one item had been added to the cart. While this lack of button labels is a significant issue, it was, luckily, the most severe accessibility challenge that I encountered during the entire process.
Luckily, the actual cart button was labeled correctly. I entered the cart, increased my order quantity, and proceeded to the checkout, all with relative ease. The next step was to confirm my delivery address, payment card, and contact details. The data was already present because I was signed in to the app with a user account. I did not have to change any of the information. However, had I needed to, all options were clearly announced as easily-selectable check-boxes.
The next step is the one that I was worried about the most: scheduling a delivery day and time. This process has traditionally been incredibly problematic for screen reader users like myself. However, I was in for a pleasant surprise.
The first step of the delivery scheduling process prompted me to choose a date. One thing that I noticed is that the app only displayed days with available delivery times. This was incredibly refreshing because many sites rely on visually grayed-out text to signify a lack of availability. This method rarely works for screen reader users.
Each date was shown as an easily selectable text-based radio button. I made my choice and found the continue button at the bottom of the screen using direct touch. The next page asked me to choose a preferred delivery window. Again, each three-hour time slot was a radio button that responded adequately to a double-tap activation gesture. The next screen asked me to review and confirm my purchase. I was glad my date and time selection had been held and appropriately reflected on the order review screen.
Everything on this page seemed to be recognized and read aloud by the screen reader. I found the “Place Order” button by swiping and double-tapping to activate it. My purchase was complete.
I encountered one small accessibility problem on the “Order Confirmed” page. The screen reader could not speak the order number for some strange reason. However, I could always reference it from the purchase email or my account. This being said it is still a defect that must be addressed.
Overall, the accessibility experience was solid. While there were still a few issues, most of the process was intuitive and straightforward. I was especially impressed by the delivery scheduling interface, which usually lacks accessibility and usability. As I wait for my order to be processed and delivered, I can almost taste those warm, chewy peanut butter bars.
Editor's Note: This is a post from our contributor, Michael Taylor. This post reflects his opinions and experiences. Read more blogs from Michael about his experiences online as a blind person who relies on a screen reader.