--- title: "Accessibility in AI-First Products: Designing for Everyone" description: "Voice input as accessibility, screen reader chat compatibility, cognitive load adaptation, and motor accessibility — AI products can be more accessible by design." canonical: https://nowah.xyz/blog/accessibility-ai-first-products lastModified: "2026-08-07T07:53:32.188Z" --- # Accessibility in AI-First Products: Designing for Everyone Voice input as accessibility, screen reader chat compatibility, cognitive load adaptation, and motor accessibility — AI products can be more accessible by design. I have a confession. When we started building Nowah, accessibility was not the first word on our [product roadmap](/blog/building-ai-product-roadmap). We were focused on making AI travel booking work at all. Could the agent search flights in real time? Could it handle multi-[city itineraries](/blog/launching-multi-city-itineraries-complex-planning)? Could it actually complete a booking end-to-end? But something interesting happened as we built out the conversational interface. People with disabilities started telling us our app was easier to use than any travel platform they had tried. Not because we had done extensive accessibility work. Because the interaction model itself was inherently [more accessible](/blog/ai-luxury-travel-more-accessible) than the form-and-filter paradigm that dominates travel. That was a wake-up moment. AI-first products have a genuine opportunity to be more accessible by default, not as an afterthought, but as a direct consequence of how they work. We have not fully realized that opportunity yet, but we are further along than I expected, and the path forward is clearer than it has ever been. ## How legacy travel apps fail at accessibility ![Illustration for this section](https://pics.nowah.xyz/website-media/product-047-img-1.webp) Try booking a flight on a major OTA using a screen reader. Actually, do not do that to yourself. I will describe the experience. You land on a homepage with a search form. There are dropdown menus for origin and destination with autocomplete that may or may not announce results properly. There is a date picker that is almost certainly a custom calendar widget, which means the screen reader interaction is unpredictable at best and broken at worst. There are passenger selectors with plus and minus buttons that sometimes lack proper labels. There are radio buttons for trip type that may or may not have visible focus states. You fill all of that out and hit search. Now you get a results page with 200+ flights displayed as cards with dense information hierarchies. Each card has a departure time, arrival time, airline, duration, number of stops, layover details, price, and a "Select" button. Try navigating that with a keyboard while a screen reader reads each element sequentially. It takes an eternity. Then there are the filters. A sidebar with 15 different filter categories, each with multiple checkboxes, sliders, or radio buttons. Airline filters alone might have 20 checkboxes. Time filters use custom range sliders that screen readers often cannot operate at all. The problem is structural. OTA interfaces were designed for sighted mouse users who can visually scan a dense grid of information and quickly compare options. That design pattern inherently creates barriers for users who navigate differently. The numbers are hard to pin down precisely, but the WHO estimates that roughly 16% of the world population lives with some form of disability. About 2.2 billion people have a vision impairment. Over 1.5 billion have hearing loss. Motor impairments affect hundreds of millions more. These are not edge cases. This is a massive segment of travelers who are poorly served by the current booking paradigm. ## Voice input is an accessibility breakthrough, not just a convenience feature When most product teams talk about voice input, they frame it as a convenience. Hands-free booking while you pack. Faster than typing while on the go. Those are real benefits, but they miss the bigger story. Voice input fundamentally changes who can use your product. For someone with limited hand or arm mobility, a traditional travel search form is a gauntlet of precise click targets and keyboard inputs. Small dropdown triggers. Tiny calendar cells. Filter checkboxes that require precise cursor placement. Each interaction is a physical challenge. Voice eliminates all of that. "Find me flights from Chicago to Miami next Friday, one passenger, economy" communicates the same information as filling out six form fields, but without requiring any fine motor control at all. The user speaks naturally, the AI parses the intent, and the search happens. This is not a small improvement. It is a category shift in who can independently book travel. Someone with arthritis, with a repetitive strain injury, with cerebral palsy, with temporary hand injuries can use voice-first AI booking with the same ease as anyone else. And voice keeps working throughout the entire flow, not just the initial search. "Select the second option." "Add a checked bag." "Book it." The user can complete the entire booking process without touching the screen at all if they choose. We built voice into Nowah as a primary input mode, not an add-on. The AI understands spoken travel queries just as well as typed ones. We think every AI travel product should treat voice this way. It is not a nice-to-have. For millions of people, it is the difference between independent booking and needing someone else to book for them. ## Screen reader compatibility for chat interfaces Chat interfaces present their own accessibility challenges, but they are qualitatively different from form-based challenges, and in many ways easier to solve well. A conversation is a linear, sequential experience. Messages appear one after another. There is a natural reading order. A screen reader user can follow the conversation the same way a sighted user does: top to bottom, message by message. Compare this to a grid of 200 flight results where the user has to construct a mental model of a two-dimensional layout. That said, chat UX introduces new problems that traditional web accessibility has not fully addressed. [Streaming responses](/blog/streaming-ai-responses-real-time-chat) are one of them. When the AI agent responds, the text appears progressively, word by word. For a sighted user, this creates a nice sense of watching the agent think. For a screen reader user, it can be disorienting if not handled carefully. Does the reader announce each word as it appears? That would be maddening. Does it wait for the full response? Then the user sits in silence wondering if anything is happening. The right approach is somewhere in between. We signal that the agent is working with a brief announcement, then read the completed response once it finishes. If the response takes a while, periodic status updates keep the user informed without overwhelming them. Rich cards are the other challenge. When the AI presents flight options, they appear as interactive cards with structured data: departure time, arrival time, airline, price, duration. These cards need to be fully navigable by keyboard and properly structured for screen readers. Each card should announce as a cohesive unit with clear labels for every data point. The "select" action needs to be keyboard-accessible with clear focus indication. This is not trivial to implement, but it is fundamentally simpler than making a 200-result grid with filter sidebars accessible. Three cards with clear structure is a much smaller surface area than the entire interface of a traditional OTA. ## Cognitive accessibility: AI adapts to the user This is where AI-first products have an advantage that traditional interfaces literally cannot match. Cognitive accessibility refers to making products usable for people with cognitive, learning, or neurological disabilities. This includes conditions like ADHD, dyslexia, autism spectrum, intellectual disabilities, and brain injuries. But it also covers temporary cognitive impairment from fatigue, stress, medication, or simply being overwhelmed. Traditional interfaces are static. The complexity of a Kayak results page is the same whether you are a power user or someone who finds dense information displays overwhelming. The filters, the sorting options, the comparison features, the price graphs are all there whether you want them or not. There is no way for the interface to adapt. An AI agent can adapt. Naturally. If a user asks a simple question, the agent gives a simple answer. If a user asks a complex, multi-part question, the agent responds in kind. The complexity of the interaction matches the user's input, not a predetermined interface layout. We have been experimenting with going further. The agent can detect when a user seems uncertain or overwhelmed based on their messages. Short, one-word responses. Repeated questions. Requests to simplify. When the agent detects these patterns, it adjusts. Shorter responses. Fewer options. More direct recommendations. Clearer action prompts. This is not a separate "accessibility mode" that users have to find and enable. It is the default behavior of a well-designed AI agent. Adapt to the user in front of you. Think about what this means at scale. A user with ADHD who benefits from concise, action-oriented responses gets exactly that. A detail-oriented planner who wants comprehensive comparisons gets that instead. The same product serves both users well because the AI modulates the experience in real time. No traditional interface can do this. A dropdown menu has the same number of options for everyone. A results page has the same density for everyone. Only an AI-native interface can dynamically adjust cognitive load based on individual user needs. ## Motor accessibility beyond voice Voice input gets the most attention in motor accessibility discussions, but AI-first products offer other advantages too. Reduced interaction count is a big one. Booking a flight on a traditional OTA requires dozens of discrete interactions. Clicks, taps, scrolls, form field entries, filter selections, card expansions, button presses. Each one requires motor action. A conversational AI booking might require five to ten interactions total: a few messages, a card selection, and a booking confirmation. That is a 70-80% reduction in required motor actions. Target size is another factor. Chat interfaces have large, easy-to-hit tap targets. The message input field spans the full width of the screen. Card selections are large, clearly delineated areas. Compare this to the tiny filter checkboxes and small calendar cells on traditional booking sites. Gesture simplification matters too. Traditional travel apps often rely on complex gestures. Pinch to zoom on maps. Horizontal swipe to compare options. Drag to set price range sliders. AI chat interactions need basically two gestures: tap and type (or tap and speak). Everything else the AI handles. For users with motor impairments, every eliminated interaction is a reduction in fatigue and frustration. The cumulative effect of needing 80% fewer physical interactions to accomplish the same task is meaningful. ## How Nowah approaches accessibility today I want to be honest about where we are. We have made progress, and we have gaps. What works well today: Voice input is a first-class input mode. You can conduct an entire booking conversation by voice. The speech-to-text processing is good, and the AI handles the natural language that results from spoken input without problems. The chat interface is keyboard navigable. You can tab through messages, cards, and actions. Screen readers can follow conversation flow. We use proper ARIA labels for interactive elements within the chat. Our dark theme with high contrast (pure black background, white text, green accent) meets WCAG AA contrast ratios. This is one of those cases where an aesthetic choice happened to align with accessibility requirements. The three-option presentation reduces cognitive load compared to overwhelming results pages. We did not design this for cognitive accessibility specifically, but it has that effect. What needs improvement: Streaming response handling for screen readers is an active area of work. We are not yet where we want to be on announcing response completion and providing interim status. Rich card accessibility could be more granular. We want each data point within a flight or hotel card to be individually navigable with clear labels. We do not yet have explicit cognitive adaptation. The AI naturally adjusts to user input complexity, but we have not built deliberate detection of overwhelm or confusion signals. Alternative input methods beyond voice and text are not yet supported. Switch control compatibility, eye tracking integration, and other assistive technology protocols are on the roadmap but not shipped. ## Legacy OTAs have an accessibility debt they cannot easily repay Here is the uncomfortable truth for established travel platforms: their accessibility problems are structural, not cosmetic. You cannot easily make a grid of 200 flight results accessible. The [information architecture](/blog/five-tabs-ai-first-information-architecture) itself is the problem. Adding ARIA labels and keyboard navigation to a fundamentally visual-comparison interface is like putting subtitles on a painting. You can do it, but the medium was not designed for that consumption model. Filters are another structural issue. A sidebar with 15 filter categories, each with multiple options, is inherently complex. You can make each individual filter accessible, but the cognitive load of navigating 15 categories with 5-20 options each remains overwhelming. Date pickers are notorious. Custom calendar widgets are one of the most common accessibility failures on the web. Most OTAs use custom implementations that partially work with screen readers but break in edge cases. And the OTA cannot easily switch to a simpler date input because their entire search paradigm depends on visual date selection. AI-first products can sidestep all of these structural issues. Not because the product team is smarter about accessibility, but because the interaction model does not require complex visual layouts, dense information grids, or custom input widgets. The conversation handles it. ## Accessibility as product quality The standard framing of accessibility is that it is the right thing to do. And it is. But I want to make a stronger claim: accessibility is a [product quality](/blog/measuring-ai-product-quality) signal. The curb cut effect is well documented. Features designed for wheelchair users, curb cuts in sidewalks, ended up benefiting everyone: parents with strollers, delivery workers with carts, travelers with luggage. Accessibility improvements routinely improve the experience for all users. Voice input designed for motor accessibility is used by everyone who finds speaking faster than typing. Cognitive simplification designed for users with learning disabilities benefits anyone who is tired, distracted, or in a hurry. High contrast designed for vision impairment is better for everyone using their phone in bright sunlight. When we reduced the number of interactions required to book a flight, we did it because fewer interactions is better for users with motor impairments. It is also just better. Period. Fewer steps, less friction, faster booking. The accessibility improvement and the product improvement are the same thing. This is why I push back when people frame accessibility as a separate workstream or a compliance checklist. In an AI-first product, accessibility is product design. Build for the widest range of users, and you build a better product for all users. ## The opportunity ahead AI-first products have a real chance to lead on accessibility in a way that previous software generations did not. Not because AI product teams are more virtuous, but because the interaction model inherently reduces many of the barriers that traditional interfaces create. Voice-first input reduces motor barriers. Conversational interfaces simplify cognitive load. Adaptive AI adjusts to individual user needs. Streamlined flows reduce interaction count. These are not accessibility features bolted on after launch. They are consequences of building around conversation instead of configuration. The travel industry specifically should care about this. Travel is for everyone. It should not require fine motor precision, perfect vision, and the cognitive stamina to navigate a 200-result grid with 15 filter categories. An AI agent that asks "where do you want to go?" and takes care of the rest is not just a better product. It is a more equitable product. We have work to do at Nowah. Screen reader support needs to be better. Cognitive adaptation needs to be more deliberate. Alternative input methods need to be supported. But the foundation is right. An AI-first architecture gives us a structural advantage on accessibility that form-based products will always struggle to match. The best travel app is one that works for everyone. AI gives us a real shot at building that. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).