Making X Threads Accessible With a Screen Reader

X is technically navigable with a screen reader, but a reply thread is not. The platform's own posts, buttons, and menus are labeled well enough for VoiceOver, TalkBack, or NVDA to announce them, but the reply structure itself — nesting, nested-of-nesting, nested-of-that — was designed to be looked at, not listened to, and it shows the moment a thread goes more than a few replies deep.

What actually works well

Give X credit where it's earned. The core reading experience — a single post, its author, its text — announces cleanly. Alt text on images works when a poster bothers to write it, and X's own controls (like, reply, repost) carry accessible labels rather than icon-only silence. If you're reading one post in isolation, a screen reader handles it about as well as any social feed does.

The trouble starts specifically with reply threads, because a thread is not one post — it is a tree, and trees are a visual shape that does not translate cleanly into a linear stream of speech.

Where it breaks down: nesting

A screen reader reads top to bottom, one item at a time. A reply thread branches: a reply to the original post, a reply to that reply, a reply to that, sometimes three or four levels deep with sibling branches running in parallel. Visually, indentation and connecting lines show you which reply answers which. Read aloud, none of that survives — you hear a flat sequence of posts with no announced relationship between them, so you're left guessing whether the reply you just heard is answering the one before it or branching off from something four posts back.

This is the same structural problem sighted readers hit when following a branching conversation, just harder without the visual indentation to lean on. A sighted reader can at least glance at the layout and re-orient. A screen reader user has to hold the branch structure in memory, built entirely from context clues in what each reply actually says.

Where it breaks down: lazy loading

X loads replies in batches as you scroll, whether or not you're using a screen reader. For a sighted reader, this is mildly annoying — the same friction covered in why some replies feel hidden or collapsed. For a screen reader user, it's worse: there's no visual "loading" spinner to notice out of the corner of your eye, so a thread can simply run out of content mid-scroll with no clear signal that more exists below, or that you've actually reached the end.

Where it breaks down: images and alt text

Alt text on X is optional, and most posters skip it. A screen reader announces an untagged image as little more than "image" or "photo," with no way to know if it's a screenshot of the actual point being discussed or an unrelated reaction picture. On threads where the real content lives in a screenshot — a chart, a quoted text block, a comparison image — a screen reader user can lose the substance of half the conversation without any indication that they're missing something.

A more linear way to read

None of this is about X breaking accessibility rules; it's about a tree-shaped conversation being read through a tool built for linear text. The most reliable fix available today is reducing how much of that tree structure a screen reader has to narrate in the first place — reading the original post fully, then treating replies as a flatter list sorted by newest or best rather than trying to trace nested branches by ear.

SkimFast helps here in a specific way: it opens a thread's replies in a single popover as one continuous, sorted list rather than a nested tree spread across a scrolling page. That doesn't add screen-reader-specific features SkimFast doesn't have, but it does remove a layer of structural complexity — there's less nesting to narrate and less lazy-loading silence to sit through, because the whole reply set loads together instead of arriving in batches as you scroll.

A repeatable routine

1. Read the original post completely before touching any replies — it's the one piece of the thread with no nesting ambiguity.
2. Default to newest or best sort over trying to trace reply-to-reply branches; a flatter order is easier to hold in memory than a tree.
3. Treat an abrupt-feeling end to a thread as probably more content, not actually finished — scroll and re-check rather than assuming you've heard it all.
4. On threads that lean on screenshots for their actual point, expect gaps where alt text is missing, and don't assume silence means nothing was there.

X's reply threads were built for eyes first, and a screen reader is doing real work compensating for a shape it was never designed to describe. Flattening that shape — reading replies as one ordered list instead of a nested tree — is the most dependable accessibility fix available right now, and it's exactly what SkimFast does by default.