Dynamic reveal scrambles screen-reader linear order

What it is

A screen reader walks the accessibility tree in linear order. Conditional fields insert or delete nodes in the middle of that tree. The reading head may sit on a control that is already gone, or skip a newly inserted block, and the next Tab lands on something visually non-adjacent. Scrambled linear order means this spoken/focus story no longer matches the visual story. Sudden appearance for sighted users is spatial. For reader users the issues are insertion point, focus, and announcement. Whether values still submit, and whether rules are maintainable, are not the point here.

Why it happens

Readers walk two ways: browse mode along the document, focus mode along Tab. If a dynamic insert only changes visual layout and is not placed correctly in the tree, browse mode reads emptiness at the old spot, and focus mode follows the DOM to somewhere far away. A second layer: focus is still on the trigger at insert. The person presses Space on “Need an invoice,” focus stays on the checkbox, the new field appears below with no announcement. No live region, and the insert did not happen. A noisy live region interrupts the label currently being heard. Deleting the node that currently has focus makes the reader dump focus to the top of the document or a random neighbor, and context is lost. The repair is: insert the node after the trigger in the tree, announce what was added, and before delete move focus to a trigger that still exists.

Studying it

Walk a conditional form with at least one mainstream reader: listen after a check, then Tab. Compare no announcement, aria-live announcement, and moving focus into the new field after insert.

Independent variables: where in the tree the insert lands, whether it is announced, whether focus is moved before delete, browse versus focus mode. Dependent variables: whether the new field is heard, times focus lands on a deleted node, Tabs from trigger to the new field, whether people can say what just appeared.

Reader engines differ widely on live regions and focus fallback; test at least two (desktop and mobile). Smoothness of a visual animation is not a reading check.

Where it stops holding

Inserting a large block at once (ten enterprise fields after choosing company) would be noise if announced item by item; announce “a company section was added” and let people Tab in. Decorative reveal (an extra hint, no new input) can use a polite live region without moving focus. If a reader user is typing in a field, do not steal focus because another condition changed. Print and read-only archives have no reading-order problem.

Applying it

• Insert conditional nodes in the accessibility tree after the trigger control, not appended at the end of the form or into a distant container.
• After insert, announce briefly what was added. Do not force focus into the new field while the person is still on the trigger, unless the new field is the only item that must be answered at once.
• Before deleting the field that currently has focus, send focus back to the trigger, then remove the node.
• Verify with a reader: check the condition, hear the new block’s name, Tab once onto its first item—not the footer. Delete the conditional field that has focus; focus returns to the trigger, not the top of the document. Append the new field at the end of the DOM as a counterexample; the spoken story splits from the visual story.

Related

• Within the group: H1.14.1 Conditional reveal must be predictable; fields must not appear or vanish without warning · H1.14.2 When a filled field is hidden, say whether its data will still be submitted · H1.14.4 Too many nested branches make form logic hard to debug
• Adjacent: J5.12 Announcing dynamic content · J2.08 Reading order · H1.15 Accessible form labeling
• Search terms: aria-live · screen reader · focus restoration