I've been booking flights with VoiceOver for about six years now. Most of that time, I assumed the experience was just slightly worse than the sighted version. After building Luma I went back and timed it: a typical round-trip booking on a major airline's website takes me 18 to 25 minutes with VoiceOver, versus 4 to 6 minutes for a sighted user clicking through the same flow. That's not "slightly worse." That's a tax.
This is a walkthrough of how I actually do it, what breaks, and what airlines could fix today without rebuilding anything.
Step 1: The home page is usually the easy part
Most major airlines have decent landing-page accessibility now. The search form's "From" and "To" fields are typically labeled, and VoiceOver reads "Origin, edit text" and "Destination, edit text" as you'd expect.
The first crack appears in the airport autocomplete. When you type "Frank" expecting Frankfurt, a dropdown of suggestions opens — but VoiceOver doesn't always announce it as a list, doesn't always tell you how many results there are, and on some sites the suggestions aren't keyboard-focusable at all. The fix on the user side is usually to type the full IATA code (FRA), which most search forms accept. Faster than wrestling with a broken combobox.
Step 2: Date pickers are where the time goes
Date pickers are the single biggest accessibility failure in flight search. A well-built one announces the selected date, lets you arrow through days, and reads "available" or "unavailable" for each. Most airline date pickers do none of that.
My workaround: I bypass the visual calendar entirely. Most date fields accept typed input — I tab into the field and type "10/15" for October 15. About 70% of airline sites accept this. The other 30% force you into the calendar widget, and that's where I lose five to ten minutes per booking.
If you find yourself stuck in a calendar widget, the trick that works most often is the VO + right arrow combo to move element by element rather than relying on the rotor. The rotor skips half the calendar's interactive elements on most sites.
Step 3: Results pages — sort first, filter second
Once you submit search, the results page is usually a long list of flight cards. The accessibility quality varies wildly: Lufthansa's is decent, United's has improved, and one major American carrier's results page reads each flight as a single 60-word string with no structure.
My rule: sort before you filter. Sorting by price or duration is almost always implemented as a simple dropdown that works with VoiceOver. Filters (number of stops, departure time windows) are usually multi-select checkboxes that may or may not announce their state. Sort first because if the cheapest acceptable option is on screen one, you don't need filters at all.
Step 4: The seat map is sometimes impossible
Seat selection is where some bookings just stop being doable independently. A typical seat map is a 2D grid rendered as a canvas or as an SVG without semantic labels. VoiceOver reads "image, image, image" or sometimes nothing at all.
The accessible alternative is almost always present but hidden: most airlines have an "auto-assign seat" or "skip seat selection" link somewhere on the page. It's often the last focusable element. If seat preference matters (aisle for an aisle dog, bulkhead for extra leg space), I call the airline. The phone agents can do in 30 seconds what the website can't do in 30 minutes.
Step 5: Payment is mostly fine
Once you reach payment, you're usually working with a third-party processor (Stripe, Adyen, Braintree) and those forms tend to have better accessibility than the airline's own pages. The one thing to watch for: Apple Pay and Google Pay buttons sometimes don't announce themselves as buttons, just as graphics. Tab past them if you don't need them.
What airlines could fix tomorrow
Honestly, most of the wins are small:
- Make every date field accept typed input. This is one form attribute.
- Add an aria-label to each seat in the seat map saying its row, letter, position type (aisle/window/middle), and price. The data already exists in the markup.
- Make the autocomplete dropdown a proper combobox with the appropriate ARIA roles. There's a published WAI pattern for this.
- Stop using "Search" as the only button label. "Search flights from Frankfurt to New York on October 15" with the values pulled from the form would be a small but huge improvement.
What we built differently in Luma
When we designed Luma's flight search we treated VoiceOver as the primary interface and the visual layout as the secondary one. Date pickers accept typed input. Results announce sort and filter state as it changes. Voice search lets you say "flights from Frankfurt to New York next Friday" and skip the form entirely.
It's not a substitute for airlines fixing their own sites — most bookings still complete on the airline's confirmation flow. But it cuts the worst part of the journey, which is finding the flight in the first place.