In this post, I will be continuing with my new accessibility narration series, in which I take the reader through a set of interactions I have with a website, documenting both positive and negative accessibility. The goal is to show how the topics I have discussed in the past affect real-world experiences. I recently learned that one of my favorite rock bands plays two concerts in my area in December.
Wishing to purchase tickets, I immediately went to the internet to hopefully complete this task. Unfortunately, my browsing session was ultimately unsuccessful. For reference, my narrative will exclusively apply to screen reader accessibility.
Strange Issues With The Cookie Pop-Up Dialogue
Only one site was selling tickets for this particular concert. A link from an email directed me to the correct page of the site, eliminating the need to search for the desired artist or concert. Immediately upon page launch, I was greeted with the infamous cookie notice that warns users about web cookies and allows us to accept or decline them. Locating and selecting the action buttons in this particular dialogue was surprisingly easy, which gave me hope for the accessibility of the rest of the site. However, I quickly realized that I had spoken too soon. Once I dismissed the cookie pop-up, I attempted to navigate around the page. I became aware of a strange but highly annoying problem.
Though the cookie window was no longer visible, my screen reader still recognized elements of the pop-up and spoke them along with the actual page text that was visible on screen. It was almost like the cookie dialogue persisted in a ghost form that was only recognized by screen readers. This bleed-through problem made navigation much slower than it should have been, leading to an overall clunky and inefficient experience.
Ease Customizing My Ticket Preferences
Once I figured out how to work with the cookie pop-up bleed-through flaw, I experienced some smooth sailing. The link from the email had taken me directly to the ticket selection page for my desired concert. First, I was prompted to choose a day of attendance. I was pleasantly surprised that the site used checkboxes instead of the traditionally inaccessible calendar grids for this task. This page also allowed me to choose my ticket quantity through an accessible drop-down list menu. After selecting the clearly labeled “Next” button, I was asked to choose the type of ticket I wanted.
Since only one ticket type was offered, I did not have to select anything on this screen. However, I noticed that well-labeled checkboxes were again used, which would have made it easy if multiple ticket types were offered. Selecting the “Next” button brought me to the ticket confirmation screen. This page displayed the date of attendance, the type and number of tickets I was purchasing, the price per ticket and total cost, and other helpful information like the time of the show and the address of the venue.
Moving around this screen was very accessible, with all text spoken aloud by my screen reader. I could even copy and paste the information into a word processor document for future reference.
Great Button Accessibility
At the bottom of the ticket confirmation screen was the “Add To Cart” button. It was easy to find using manual navigation and filtering by button only. Once I added my tickets to the cart, I shifted my screen reader’s focus back to the site's top navigation bar. All of the buttons along this bar were labeled correctly. These included “Navigation Menu,” “Account,” “Help and Support,” and “Shopping Cart.” Correctly labeled buttons drastically improve the accessibility of any digital experience. I moved the screen reader focus cursor to the “Shopping Cart” button. Until now, everything had worked reasonably well besides the strange and annoying cookie pop-up bleed-through issue. However, this was all about to change with the click of a button.
A Cart Catastrophe
Thinking I had almost completed my ticket purchase, I activated the “Shopping Cart” button on the site's top navigation bar. The next page loaded was an offer for ticket protection insurance if I had a last-minute cancelation of my plans. I decided I was uninterested and attempted to move to the next step. At this point, I realized there was no obvious way to decline coverage.
The page included a brief description of the insurance and a link to a terms and conditions document. There appeared to be nothing else on the screen. I sent my screen reader’s cursor to the top of the page and manually moved through using the tab key. Not once did I encounter a button, link, checkbox, or anything else that would allow me to move past this screen. I tried everything I could think of. I used manual navigation twice more but with the same results. I tried filtering by button and link, but nothing appeared in the screen reader rotor. I even tried exiting the site and starting the process from the beginning on a different device in hopes that the same ticket insurance offer screen would not appear the second time. This did not work either. I got stuck in the same spot.
At this point, I was forced to abandon my mission. I could not figure out a way to proceed. I decided to take a screen capture of the problematic page for future reference.
A sighted person later informed me that there were two small buttons at the bottom of the screen marked “Got It” and “Decline Coverage.” These buttons were not at all screen reader detectable, a major accessibility flaw that essentially broke the site’s core functionality, the ability to purchase digital tickets.
Reflecting on Challenges and Hoping for a More Inclusive Future
Unfortunately, experiences like these are somewhat typical for me and other blind internet users and are incredibly frustrating and discouraging. This is not the first time I had to abandon a browsing session due to a significant accessibility defect.
I hope that blockers like these will decrease in prevalence as digital accessibility becomes a bigger priority.
![Web Accessibility Statement: How to Write One [With Examples]](https://blog.usablenet.com/hubfs/188b2e520d5ec29abbb2f6.webp)
