How can screen reader users notice new story content without hearing the whole page again?
Separate feedback after an action into three responsibilities: a status message announces that the result is ready, the main content preserves the complete story, and the focus strategy determines when to move. A responsibility checklist and a fictional example clarify what to announce, where to read, and when to navigate.
Separate the responsibilities: announce updates, preserve the story, and decide where to go
When an action adds a new passage, you can give a brief completion announcement, place the full result in a clearly titled content area, and let users decide when to go there to read. The announcement answers “Is the result of my last action ready?”, the main content answers “What exactly happened?”, and the focus strategy answers “Where do I interact next?” Giving each a distinct job helps prevent a single update from triggering a rereading of the entire page.
Status messages can be conveyed through roles or properties without receiving focus. See the explanation of status messages. This guidance does not require an entire story passage to be read automatically. The responsibility table, wording, and interaction sequence below are original instructional designs, not descriptions of a particular product’s implementation.
This article addresses only situations where the current page retains earlier story content and appends results after an action. The old lighthouse, its keeper, and the interaction flow in the example are entirely fictional. They are not a real user case, measured findings, or existing DramaFork features. The design goal is to define requirements that can be checked at handoff, not to promise particular screen reader behavior.
Use a responsibility checklist to guide each addition
When handing off a story node, complete the following table alongside it. Do not simply put “supports screen readers” in the requirements: that phrase does not explain what is responsible for reading the new content or when it should be read.
| Responsibility | What to specify | Entry for this example |
|---|---|---|
| Status message | Action name, completion status, and reading control | Copper box inspection complete; a new result is available to read |
| Content location | New content title, append location, and content to retain | Append “Result of inspecting the copper box” after the existing story; retain the earlier text |
| Reading control | Name, destination, and location | Provide “Read the result of inspecting the copper box” in the action area, pointing to the result heading |
| Focus strategy | Whether focus moves on update and where user-initiated navigation lands | Keep focus in place when the result arrives; move to the result heading after the control is activated |
| Follow-up actions | Location and relationship to the result | List actions based on the new clue at the end of the result |
The status message does not need to repeat what is inside the copper box. The main content, however, must be complete on its own: users must be able to find and understand the result even if they miss the announcement. The reading control’s name should identify its destination. “View” or “Here” is difficult to identify out of context.
Focus is the current interaction position; the screen reader’s reading position also needs to be checked separately. During acceptance checks, seeing that a button still has focus is not enough to conclude that users can continue listening from the same sentence. The responsibility table defines expectations. The actual relationship between mobile reading gestures, keyboard interaction, and content updates still needs to be confirmed in the implementation.
Walk through inspecting the copper box
In this fictional scene, a traveler stands at the entrance to an old lighthouse. The existing text reads: “The lighthouse keeper pushes the copper box to the edge of the table and gestures for you to inspect its underside.” After reading this, the user activates “Inspect the copper box.” The action has now been submitted, but its result is not yet ready. The interface should distinguish waiting from completion and must not immediately announce “New clue discovered.”
Once the result is ready, append the following after the existing text:
Result of inspecting the copper box
A damp duty roster lies under the box. On its back are the words “Go to the north gate before the bell rings.” The lighthouse keeper recognizes the handwriting on the paper but saves the explanation for after the meeting. You do not yet know who left this message.
Available actions: Ask about the handwriting on the duty roster; take the copper box to the north gate.
At the same time, the status message says only: “Copper box inspection complete; a new result is available to read.” It confirms that the action has finished without reading the duty roster’s contents in advance. The reading control uses the full name from the table. Only after users select it do they enter the main content at the new heading.
Suppose a user is rereading the keeper’s previous sentence while waiting. The arrival of the result should not suddenly take them to the north gate option. If a user is still near the original action, they can also find the reading control directly. Both paths lead to the same passage, with no need to store a separate, shortened version of the story for announcements.
Follow-up actions belong at the end of this passage so users can reach them in reading order after finishing the result. If “Return to the action area” is also offered, its destination should be defined in advance rather than simply returning users to the top of the page. A complete check must cover submission, waiting, receiving the announcement, entering the result, and choosing the next step, rather than merely confirming that “complete” was heard.
Distinguish alternatives by reading intent
“Stay in place and provide a reading control” suits situations where results are appended and users may continue reviewing earlier story content, but it need not be the only approach on every page. If the action itself is called “Open the next chapter,” users have already expressed an intention to enter a new chapter. The reading start position after the chapter transition can be designed separately. Do not apply that rule directly to an ordinary action such as “Ask the lighthouse keeper.”
You can also design a mode that users explicitly enable to “Read new content when the result arrives.” In that case, make clear that only the current result will be read, and provide ways to pause and reposition the reading location. This is an additional reading option. The presence of a status announcement does not imply consent to automatically hear an entire passage.
For a short result such as “The copper box has been put away,” the announcement may include the outcome, but the main content or a record that users can revisit should still preserve that change. If the addition includes suspense, dialogue, or information needed to decide what to do next, keep the announcement brief and leave the explanation to the main content. The dividing line is whether users need to read at their own pace, not a mechanical word-count cutoff.
If an action only changes an existing record without adding story content, say “The copper box record has been updated” and point to the updated location. Do not keep using the “new result” template, or users will search for a new passage that does not exist.
Use failure scenarios to check whether responsibilities have become mixed
The first failure is using the entire page’s story as the source text for an update announcement. One sentence is added about the underside of the box, yet even the lighthouse opening is read again. During checks, record the actual text range announced and require it to communicate only the status of this action. The reading control should continue to provide access to the full story.
The second failure is an announcement that says “complete” before a readable result exists in the main content. The completion announcement should depend on the result being ready and the reading control being available. If the request fails, explicitly state that no new story content was added this time, retain the original text, and provide a retry control. Retrying must not append the same result twice.
The third failure is moving focus as soon as the result appears while also announcing a summary. Users lose their original position and may hear two similar pieces of content in succession. Check announcements and navigation separately against the responsibility table: the former follows changes in status; the latter is triggered by an explicit reading action.
The fourth failure occurs during consecutive actions. “Updated” does not identify which action it refers to. Results can use recognizable action names. If the same action can be submitted multiple times, distinguish the individual results and make clear which remain unread. Do not rely solely on the visually latest item to convey these relationships.
Finally, check these scenarios with a screen reader on the actual target devices. Record whether content is read repeatedly, whether users lose their position, whether the reading control reaches the beginning of the addition, and whether users can find the main content again after missing an announcement. This is a test procedure, not a report of passed tests. Pop-ups, full-page navigation, and timed choices need their own interaction rules; this checklist for appended results cannot cover every situation.
