如何讓螢幕閱讀器使用者知道劇情有更新，不必重聽整頁？

行動後新增劇情，可先簡短通知完成，完整結果放在標題明確的正文區，由使用者決定何時前往閱讀。通知回答「操作有結果了嗎」，正文回答「具體發生什麼事」，焦點策略回答「接著在哪裡操作」。各司其職，才能避免更新造成整頁重讀。

狀態訊息可透過角色或屬性呈現，無須取得焦點。參見狀態訊息說明。這不代表必須自動朗讀整段劇情。以下職責表、措辭與互動順序是原創教學設計，並非特定產品的實作描述。

本文僅處理「本頁保留舊劇情，行動後附加結果」的情境。舊燈塔、守塔人及流程皆為虛構，並非真實使用者案例、實測成果或 DramaFork 現有功能。目的是先訂出可檢查的交付要求，不保證特定報讀表現。

交付劇情節點時，一併填寫下表。只寫「支援螢幕閱讀器」，無法說明新增內容由誰讀、何時讀。

通知不必複述盒內物品；正文須獨立完整，漏聽通知也能找到並理解結果。入口名稱須指出目標；「查看」「這裡」脫離上下文便難辨識。

焦點是目前操作位置，螢幕閱讀器的閱讀位置須另行檢查。驗收不能因按鈕仍有焦點，就斷言能從原句續聽。表格規定預期；實作仍須確認行動裝置閱讀手勢、鍵盤操作與內容更新的實際關係。

虛構場景中，旅人站在舊燈塔門口，原文是：「守塔人把銅盒推到桌邊，示意你檢查盒底。」使用者讀完，執行「檢查銅盒」。操作已送出，結果尚未就緒，介面須區分等待與完成，不能立刻通知「發現新線索」。

結果就緒後，在舊文後新增：

檢查銅盒的結果

盒底壓著一張潮濕的值班表，背面寫著「鐘響前去北門」。守塔人認出紙上的筆跡，卻留待見面後解釋。你還不知道是誰留下這句話。

可選行動：詢問值班表的筆跡；帶著銅盒前往北門。

同時，狀態訊息只寫：「檢查銅盒已完成；有新增結果，可前往閱讀。」確認操作結束，不提前朗讀值班表的內容。入口採表中完整名稱，使用者選取後才從新增標題進入正文。

若等待時正在重讀守塔人上一句話，結果出現不應突然帶往北門選項。若仍在原操作附近，也能直接找到入口。兩條路徑通往同一正文，不必另存通知用的縮短劇情。

後續行動放在段末，讀完可依序找到。若提供「返回操作區」，須先確定目的地，不能籠統回頁首。完整檢查涵蓋送出、等待、收到通知、進入結果、選擇下一步，不只確認聽見「已完成」。

「留在原位、提供入口」適合可能繼續查看舊劇情的附加情境，不必成為所有頁面的唯一方案。若操作名為「開啟下一章」，使用者已表達進入新章意圖，可另訂切換後的閱讀起點；不能直接套用到一般的「詢問守塔人」。

也可設計由使用者主動開啟的「結果就緒後朗讀新增內容」模式，明定只讀本次結果，並提供暫停、重新定位方法。這是額外閱讀選項，不能因有狀態通知，就推定使用者同意自動聽完整段落。

「銅盒已收起」等短結果，通知可含行動結論，但正文或可回查紀錄仍須保留變化。若含懸念、對話或下一步判斷所需資訊，通知宜簡短，正文負責解釋。分界在於是否需要自行掌握閱讀節奏，不能只按字數機械截斷。

若只修改既有紀錄、未新增劇情，應說「銅盒紀錄已更新」並指向更新處。沿用「新增結果」會讓人尋找不存在的新文。

第一種失敗：拿整頁劇情作更新通知的內容來源。盒底只多一句，卻連燈塔開場也重讀。檢查須記錄實際通知的文字範圍，要求只表達本次操作狀態；完整故事仍由正文入口提供。

第二種：通知「已完成」，正文卻無可讀結果。須等結果就緒、入口可用才提示完成。請求失敗時，明說本次未新增劇情，保留原文並提供重試入口；重試不得重複附加同一結果。

第三種：結果出現便移動焦點，又播報摘要，讓人失去原位置，還可能連聽兩份相似內容。依表分別檢查通知與跳轉：前者隨狀態改變，後者由明確閱讀動作觸發。

第四種發生在連續行動：「已更新」無法辨明哪次操作。結果可用可辨識的行動名稱；若同一行動可多次送出，還須區分各次結果及未讀項目，不能僅靠視覺上最新一筆表達關係。

最後，在實際目標裝置上以螢幕閱讀器檢查上述情境，記錄是否重讀、遺失位置、入口是否到達新增開頭，以及漏聽通知後能否找回正文。這是檢查腳本，並非通過測試的報告。彈出視窗、整頁導覽、限時選擇須另訂互動規則，不能用這張附加結果清單概括所有情況。