I have been shopping early Black Friday deals for the better part of a month. I recently made a purchase of some holiday decor from a fairly large online housewares retailer using my tablet. Unfortunately, I experienced some incredibly frustrating accessibility issues that almost caused me to abandon my purchase and move on.
The theme here is oddity. Some of the flaws I encountered were particularly bizarre. In the remainder of this post, I will walk through my journey on this site in detail. My commentary applies to mobile, touch-based screen readers and will be most helpful for teams who believe they have a mature website and want to uncover more complex accessibility issues.
Product Page Problems
The site in question is one that I occasionally use, so I was fairly familiar with the homepage and search system. However, not having used the site since earlier in the year, I was dismayed to find that an off-the-shelf accessibility widget with a so-called screen reader mode had been implemented. I ignored this and continued using the site as I usually do.
The issues began immediately. Once I located one of the items I wanted using manual swipe navigation, I activated the listing with a double tap and moved to the product details page. When the next screen loaded, the virtual keyboard automatically appeared, and the screen reader focus was placed in a text field.
At first, I did not know what had happened. After some brief exploration, I realized that I was in the quantity picker field. I did not understand why the quantity adjuster opened immediately when the page loaded. I dismissed the keyboard and field, then explored the item details and added the product to the cart.
I returned to the search results and activated the next item on my list. Again, the screen reader focused on the quantity text field as soon as the page loaded. This was clearly not a one-off problem. I hid the keyboard and explored the product listing details.
This time, before adding the item to the cart, I wanted to increase the quantity to four. I could not locate the quantity adjustment option. I tried manual swipes, filtered text field navigation, and direct touch, but could not find any hint of the quantity picker.
At this point, I was thoroughly confused. I knew that the system allowed for quantity adjustment on the product details screen. I had already seen that behavior from the initial focus on the quantity input. Out of curiosity, I asked a sighted person for help.
The quantity adjustment field was present and located directly above the “Add to Cart” button. As a test, the sighted user placed my finger on the exact spot on the screen where the text field appeared visually. The screen reader said nothing. It refused to recognize the quantity adjuster.
In other words, the quantity adjustment interface opened automatically on page load, but once dismissed, it was impossible to reopen it using screen reader commands. I have never experienced this sort of issue before. I am not entirely sure whether this was a bizarre accessibility bug or an intentional “screen reader feature” that someone believed would be helpful.
If it was meant as a feature, the implementation is terrible. Quantity selection is rarely the first thing that a shopper wants when they land on a product details page, unless they are making a specific routine or repeat purchase. Screen reader users should be able to control the page and return to the quantity field later when they are ready to add the product to the cart.
As an additional note, this issue was not present when using the site without a screen reader, as confirmed by the sighted user. It was clearly an accessibility issue that affected only screen reader users.
Now aware of this limitation, I continued with my original task but adjusted my approach. I planned to do all quantity adjustments in the cart before completing checkout. I also followed my regular online shopping habit of adding several interesting items to the cart so I could review them later and remove anything I did not want.
That plan quickly fell apart due to another strange accessibility issue.
Once I reached the cart, I started moving through the list of products I had added to identify items I wanted to remove. Under each listing was a button labeled “X Icon.” The labeling was far from ideal, but I was able to guess that this button was supposed to remove the related product from the cart.
I went through the list, deleting the items I did not want in my final purchase using this “X” button as I moved along. When I was finished, I returned to the top of the cart to make one last review using manual swipe navigation.
I immediately noticed a serious problem. Not only were some of the items I had deleted still in the cart, but many of the items I definitely wanted to purchase were also gone. I reviewed the cart twice to make sure I was not missing anything, but I had to conclude that something had gone very wrong.
There was clearly a calibration issue between the remove button and the corresponding product. At this point, I was incredibly frustrated. I had to repeat my shopping session and add only the specific items I knew I wanted to purchase, because I could not rely on the cart to handle changes later.
Wanting to understand what was happening fully, I again asked a sighted person for help. I placed focus on the “X” button under the first item in the cart and activated it to remove that specific item. Instead, the third item in the list was deleted.
On a hunch, I tried direct touch instead of manual swipe navigation. I had the same negative result.
At that point, I cleared the cart and started over. Once I added all the relevant products back into the cart, I moved on to the checkout process.
I had a strong feeling that the checkout process would not go well, and I was unfortunately correct.
The first stage of checkout involved entering a shipping address. All fields were labeled correctly, so I was able to input my shipping details easily using the virtual keyboard and screen reader text field navigation commands.
When I finished, I moved to the “Continue” button at the bottom of the screen. The screen reader announced it as “Dimmed,” which meant the button was not clickable. That usually indicates an error or an omission in the information the user has provided.
I reviewed my entries carefully, looking for a mistake. I could not find one. I erased the text and re-entered the information. Nothing changed.
Once again, I needed assistance from a sighted person. They saw the problem almost immediately. I had not completed the state portion of the address form. The state picker was the only drop-down menu in the entire form. All the other elements were text fields.
I had completely missed this item in the three or four reviews I had already done. The screen reader could not locate or recognize the state picker using manual swipes, text field navigation, or direct touch. There was no way to interact with this part of the form, which made completing the rest of the checkout process impossible on my own.
This experience was an utter disaster from an accessibility perspective. I wanted to complete this purchase and take advantage of the discounts, and with a sighted person’s help, I eventually did. However, the website was not accessible or usable in a way that allowed me to remain independent.
For me, one of the most important criteria for an accessible website is the ability for people with disabilities to use it independently. This site failed that basic test.
From a development and testing standpoint, the issues I encountered are not simple “minor bugs.” They are examples of how interactive controls and dynamic interfaces can break completely when used with a mobile screen reader. A team might believe its site is mature because basic labels and headings are in place. Still, if core journeys like product selection, cart management, and checkout cannot be completed independently, the experience is still not accessible.
Experiences like this one are exactly why relying on automated tools or generic widgets is not enough for accessibility. To understand how your mobile site actually works for blind customers, you need real testing with screen reader users on real devices and careful checks of core journeys, such as product selection, cart updates, and checkout.
A site might look mature because headings are present and forms are labeled, but if shoppers cannot manage their cart or complete a purchase without help, the experience is not accessible or independent. Holiday traffic only increases the impact when these journeys fail.
If you also want to see how problems like these are showing up in real lawsuits, you can pre-register for UsableNet’s Year-End Digital Accessibility Lawsuit Report. The report highlights which industries, website journeys, and mobile experiences are driving legal action, so your team can use real data to plan priorities for 2026 and make the next holiday season more accessible for everyone.
This is a guest post from our marketing contributor, Michael Taylor. It reflects his opinions and experiences. Read more about Michael and some other posts on his experience online here.