Around this time every year, I get that Halloween itch for a night of spooks, scares, and hair-raising fun. My family and I settled on a haunted house tour as our annual Halloween activity this October. We chose a local pop-up that is known for some of the most terrifying frights.
All guests are required to purchase admission tickets for their chosen date prior to arrival at the haunted house. Wanting to go on a particular day toward the end of October, I promptly turned to the event’s mobile website to purchase tickets. The site is linked to a big online ticket retailer for the purchase process. Below is my step-by-step experience, including what worked well for accessibility and where teams can learn from it.
As always, mobile touch-based screen readers will be the primary area of focus here.
TL;DR
-
Header controls were labeled, and focus landed on the main content.
-
Quantity-first design filtered the time slots to what I needed.
-
Expandable date and time lists announced the state and updated correctly.
-
The payment dialog acted like a proper modal with clear actions.
-
Checkout fields were labeled and easy to review, and the email with QR codes was simple to use.
Direct Linking
The attraction’s site linked me directly to a major ticket retailer’s event page, so I did not need to work through the homepage.
Right away, I noticed good choices. The banner image that doubles as the Home link was labeled. The three icon buttons in the header were labeled. Most helpful, the focus landed on the main content on load, so I could start the task without crossing the header.
Terrific Tickets
I started with the number of tickets. At first, that felt unusual, but it turned out to be smart. I entered the quantity with the virtual keyboard, tapped Done, and moved on.
Dates appeared in a vertical list, which worked well for this event’s limited schedule. Each date is announced clearly, for example, “Saturday, October 25, 2025, Menu button, collapsed.” A double-tap expanded the date to show thirty-minute slots.
Here is where the quantity step helped. I only heard time slots that could fit my group, which removed noise. Each slot announced the time and its price. I chose our slot and moved forward without guesswork.
Proper Pop-Up
After I picked the time, my screen reader dinged to indicate a pop-up. I placed focus in the dialog with direct touch. The dialog asked me to pay now or cancel. Both buttons were labeled. The dialog behavior matched what I expect for accessible modals, so I tapped Pay Now.
Successful Checkout
Checkout stayed smooth. Name, email, and card fields were labeled. The keyboard worked as expected and I could review entries with the screen reader. The Complete Purchase button was easy to find.
The confirmation email arrived right away. The layout was simple, links were clear, and the QR codes for the tickets were easy to locate and use.
What Worked in This Mobile Ticketing Flow
-
Focus landed on the main content at page load.
-
Controls and icons used programmatic labels.
-
Date items announced collapsed or expanded state.
-
Time slots were filtered to the quantity I set.
-
The payment dialog managed focus and actions clearly.
-
Forms used proper labels and a logical order.
-
The email confirmation and QR codes were easy to navigate.
If your team wants to turn positive user feedback like this into lasting improvements, see how developer-led remediation works with UsableNet Assistive
FAQ: Mobile Ticket Purchase Accessibility
What made this purchase flow accessible on mobile?
Clear headings, labeled controls, focus that started in the main content, expandable lists that announced state, and a checkout with labeled fields and predictable navigation.
Why collect ticket quantity before showing dates and times?
It filters out time slots that cannot accommodate the group size, reducing noise for keyboard and screen-reader users.
How should expandable lists be announced?
Items should convey role and state, for example, “Menu button, collapsed,” and then update to “expanded” after activation.
What makes a pop-up accessible on mobile?
Move focus into the dialog, keep it there until a choice is made, and present clear buttons such as Cancel and Pay Now.
What are must-haves for an accessible checkout form?
Programmatic labels, logical order, error messages tied to the correct fields, and reliable virtual keyboard entry and review.
Do confirmation emails and QR codes affect accessibility?
Yes. Simple layout, descriptive links, and QR codes paired with readable ticket details help people complete the task.
How does this relate to WCAG 2.2 AA?
These behaviors align with criteria around labels and names, focus and navigation, input assistance, and robust semantics.
Conclusion: Mobile Ticketing Accessibility — What This Flow Got Right
This was one of the smoother mobile purchases I have made recently. The experience worked because the small details were handled well. Focus started where the task began. Buttons and lists said what they were and updated their state. The form fields were labeled and easy to review. Those choices turned a seasonal errand into a straightforward task.
If you are running ticketing, events, or checkout on mobile, this walkthrough provides a checklist to get started. If you want help translating these ideas into durable fixes, the team at UsableNet can point you to practical next steps.
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.
