--- title: "Screen Readers and AI Chat: Making Conversations Accessible" description: "Rich AI messages with embedded cards, carousels, and action buttons need semantic labels that tell screen readers 'Book flight to Tokyo for $450' — not 'Button 3.'" canonical: https://nowah.xyz/blog/screen-readers-ai-chat-accessible lastModified: "2026-08-07T08:02:51.794Z" --- # Screen Readers and AI Chat: Making Conversations Accessible Rich AI messages with embedded cards, carousels, and action buttons need semantic labels that tell screen readers 'Book flight to Tokyo for $450' — not 'Button 3.' Turn on VoiceOver on your phone and navigate a [chat interface](/blog/adapting-chat-interface-mobile-desktop). If the interface was designed with accessibility as an afterthought, you will hear something like this: "Button. Image. Text. Button. Button. Image. Text. Button." No context. No meaning. No way to make a decision about booking a flight. The screen reader is reading the structural elements without understanding what they represent. A flight card that shows Delta Airlines, JFK to NRT, nonstop, 14 hours, $450, and a Select button becomes a meaningless sequence of generic element announcements. This is the screen reader problem in AI chat interfaces, and solving it requires deliberate semantic labeling at every level of the component hierarchy. ## The "Button 3" problem ![Illustration for this section](https://pics.nowah.xyz/website-media/design-038-img-1.webp) Screen readers traverse the DOM (or the accessibility tree, on native platforms) sequentially. They announce each element by its role and label. A button with no accessible label is announced as "Button." Two buttons in a row become "Button" followed by "Button." If there are three flight cards in a carousel, each with a Select button, the user hears "Button, Button, Button" — with no way to distinguish which flight each button selects. This is not a theoretical concern. Screen reader users exist across all demographics, and travel apps serve a global user base that includes people with visual impairments. A booking flow that is inaccessible to screen readers is a booking flow that excludes real users from spending real money on real trips. The solution is semantic labeling: attaching meaningful, context-rich labels to every interactive element. ## Semantic labeling for flight cards A flight card's Select button should not be labeled "Select" in isolation. It should be labeled with the full context of what the button selects: "Select Delta Airlines flight, New York JFK to Tokyo Narita, nonstop, 14 hours, $450, economy class." This label is verbose by visual standards but exactly right for screen reader navigation. The user hears the complete information needed to make a decision without needing to navigate through each individual element of the card. One announcement, one decision. The label is assembled programmatically from the flight card's data fields. Every card component knows its airline, route, stops, duration, price, and cabin class. The accessible label concatenates these into a human-readable summary. If any field is missing (which should not happen in production but must be handled), the label omits it gracefully rather than announcing "undefined" or empty strings. ## Card summarization ![Supporting diagram](https://pics.nowah.xyz/website-media/design-038-img-2.webp) Before the screen reader encounters individual flight cards, it should announce the set as a whole. "3 flight options" tells the user what to expect and provides navigational context. They know there are [three options](/blog/why-three-options-not-three-hundred) and can navigate through them sequentially. The carousel container carries this group label. It also communicates the current position: "Flight option 1 of 3" as the user navigates between cards. This positional awareness prevents the user from losing track of which option they are evaluating. Hotel card carousels follow the same pattern. "3 hotel options. Hotel option 1 of 3: Park Hyatt Tokyo, 5 stars, $280 per night, 0.3 km from Shibuya, Select button." The structure is consistent across card types, which helps screen reader users build a mental model of how the interface works. ## Streaming text accessibility [Streaming text](/blog/streaming-text-ai-thinks-out-loud) — where the AI's response appears token by token — creates a unique accessibility challenge. If the screen reader announces each token as it appears, the user hears a disjointed stream of individual words. If it waits until the stream is complete, the user misses the real-time nature of the conversation. We use ARIA live regions (on web) and equivalent native accessibility announcements to handle streaming. The approach is: announce the first sentence when it is complete, then announce subsequent sentences as they complete, then announce any embedded cards or actions when they appear. This gives the screen reader user a paced experience that matches the visual streaming without overwhelming them with token-level announcements. They hear the response building sentence by sentence, which preserves the conversational feel of the streaming interface. After the stream completes, the full message is available for re-reading through standard navigation. The user can move through the message element by element if they want to re-hear specific parts or navigate to embedded cards and action buttons. ## Action announcement Every action button in the chat — Select, Book, Show more, Change dates — includes a label that describes not just the action but the context. "Select" becomes "Select Delta flight to Tokyo for $450." "Show more" becomes "Show more flight options to Tokyo." "Book" becomes "Book Delta flight, JFK to NRT, April 5th, $450." The contextual labeling eliminates ambiguity. When the user encounters a button, they know exactly what tapping it will do. There is no need to navigate backward through the card to gather context and then navigate forward to the button. For buttons that trigger modals (like the review modal), the label also communicates the transition: "Select Delta flight to Tokyo, $450 — opens review details." The user knows that tapping the button will present new content, not navigate away from the current screen. ## Focus management When new content appears in the chat — a new AI message, a set of flight cards, a booking confirmation — the screen reader's focus needs to be managed deliberately. New messages receive an announcement via the live region but do not steal focus. This lets the user continue their current navigation if they are reviewing a previous message. They hear the announcement of new content and can navigate to it when ready. Cards and interactive elements that appear within a message do receive focus movement, but only after the message text is complete. The focus lands on the first card in a carousel, where the user hears the card summary and can navigate through the options. After a booking confirmation, focus moves to the confirmation message and the next-step action buttons. This ensures the user immediately hears "Booking confirmed" and can access the "View your trip" action. ## Testing with real screen readers Accessibility labels that look correct in code are not necessarily correct in practice. The way VoiceOver (iOS), TalkBack (Android), and screen reader extensions (web) interpret and announce labels can differ from what the developer expects. We test every interactive flow — search, compare, book, confirm — with actual screen readers on actual devices. The test is not "are the labels present" but "can a user who relies entirely on the screen reader complete a booking with confidence?" This means navigating through a full flight search conversation, evaluating three flight options by ear, selecting one, reviewing the booking details, completing payment, and hearing the confirmation — all without visual reference. Any step where the screen reader user would be confused, lost, or unable to proceed is a bug, not an edge case. Rich AI chat interfaces present the most complex accessibility challenge in modern interface design. Every card, every action, every streaming response must carry semantic meaning that survives the translation from visual to auditory. "Button 3" is a failure. "Select Delta flight to Tokyo for $450" is a success. The difference is deliberate, careful labeling of every element in the conversation. --- 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).