Fragments, Portals, and the DOM Order Trap

Screen readers and the keyboard follow the DOM order, the order elements appear in the document. CSS may move things visually, but reading order does not change.

A React Fragment groups children without adding a wrapper div. That keeps your DOM clean and avoids breaking lists or tables with stray elements.

An extra div inside a list or table can break the parent-child structure assistive tech expects. A Fragment avoids that invalid nesting entirely.

A Portal renders children into a different DOM node, often the document body. It is the standard way to mount modals above everything else.

Even though the markup lands elsewhere, a portal stays in your component tree. State and context flow normally, so logic is unaffected.

A portal at the end of body can appear after unrelated content. Tabbing may jump to a far-off spot, so focus management becomes essential for portals.

When a portal opens, the keyboard does not follow automatically. Explicitly move focus into the modal so the user is where the new content is.

While a portal modal is open, keep Tab inside it. On close, return focus to the element that opened it, since DOM proximity will not do this for you.

CSS flexbox order or grid placement can rearrange the screen. The tab order still follows the source, so avoid reordering interactive content with CSS.

Write your JSX so the source order matches the logical reading flow. Then both sighted and screen reader users encounter content in the same sensible sequence.

Press Tab through your app and watch where focus goes. If it jumps somewhere unexpected, your DOM order or a portal needs attention.

You mount a modal with a portal into document.body. What new responsibility does that create?

Use Fragments to avoid invalid wrappers, keep source order logical, and manage focus carefully whenever a portal renders content elsewhere. 🧩