选项不靠悬停解释：让触屏玩家在提交前看清代价
把影响选择的已知代价、可用条件和限制常驻在选项旁，把补充解释放进可点开的细节，再按需提供确认摘要。用一份信息分层表，区分查看、选中和提交，避免手机玩家为了读说明而误做决定。
先给答案：关键代价必须在提交之前可读
如果选项的资源消耗、时间占用或已知限制只在鼠标悬停时出现，触屏版本就缺少完整的决策入口。修订时先把足以改变选择的已知代价写在选项旁。补充解释可以点开，按需设置的确认摘要用于核对当前决定，不能承担第一次披露重要条件的任务。
判断信息是否该常驻，可以问：玩家知道这句话之后，会不会改选另一项？如果会，它就不应藏在折叠区或没有提示的手势里。例如“消耗唯一通行证”属于决策条件；通行证由谁签发、为何有效，只有在不影响当前选择时才可以留在细节中。
还要分清查看、选中、提交三个动作。点“查看代价”只展开文字；点选项可以标记候选；点明确的提交按钮才推进剧情。如果作品采用点选即提交，说明入口就应与提交区域清楚分开，不能让同一次点击既尝试读说明又完成选择。
本文使用虚构教学案例《雾港末班船》。人物、数值和交互均为说明问题而设，不是真实用户案例、实测结果，也不代表 DramaFork 已有产品功能。
用信息分层表决定每句话放在哪里
先列出每个选项的已知条件，再分配显示位置。不要先按字数删减，否则可能删掉决定性的限制。
| 信息层 | 放什么 | 可复用句式 |
|---|---|---|
| 常驻要点 | 必付代价、已知互斥限制，以及决定选项可用性或实际代价的条件 | 消耗什么；因此放弃什么；何时可选或代价会变 |
| 点开细节 | 不影响当前选择的原因与补充适用说明，以及非关键的未知背景 | 原因是什么；补充说明是什么；哪些背景尚未揭晓 |
| 确认前摘要（按需） | 所选行动及当前实际代价，复核已披露的关键条件 | 将执行什么；扣除多少；执行后剩余多少 |
审稿时再问：“删去后是否改变判断？”如果会，就把信息移回常驻层，包括会影响判断的不确定性。“适用条件”不能一概折叠：决定能否选择、需要付出多少的条件必须常驻，只有不影响选择的补充说明可以点开。细节不是重要内容的收纳箱，摘要也不能补救首次披露的遗漏。
三种方案可以组合，但工作不同。常驻要点便于横向比较，代价是占用页面高度；点开细节容纳较长解释，代价是增加查看步骤；确认摘要适合难以撤回或容易误触的提交，代价是打断节奏。
若只有两个简短选项，常驻条件加明确提交就可能足够。若四个选项各有多项条件，应先统一信息顺序，让玩家按同一维度比较，再增加补充细节入口。不要给每个普通对白都套上确认弹窗。
把末班船选择完整走一遍
案例中，林遥持有两枚船票和一份待送文件，距离开船还有一刻钟。她可以请船夫立即送件，也可以留在码头等同伴。教学设定规定：送件花掉全部船票，本晚不能再乘客船；等待不花船票，但会错过这班送件船。文件送达后的影响尚未揭晓。
原稿只显示“请船夫送件”和“等同伴回来”，代价藏在悬停说明里。第一轮改稿先写成：
- 请船夫送件：消耗两枚船票；本晚无法乘客船。旁设“查看送件条件”。
- 等同伴回来：不消耗船票；错过本班送件船。旁设“查看等待条件”。
展开送件条件后，显示：“船夫收取全部两枚船票作为报酬。交付后不能取回文件；收件人的回应未知。”这暴露了第一轮改稿的遗漏：不能取回文件会影响选择，不能只留在展开区。最终常驻文案应为：“请船夫送件：消耗两枚船票；本晚无法乘客船；文件交付后不可取回。”细节只补充不影响选择的交付解释。
玩家读完后收起细节，选中送件，再进入本案例采用的摘要：“交出文件并消耗两枚船票，剩余零枚；本晚无法乘客船，文件不可取回。”操作分别写成“返回选择”和“确认送件”，避免只写含义模糊的“确定”。
这次教学走查的关键产物是被找出的遗漏条件。摘要核对已经披露的信息，不能到最后一步才突然增加损失。返回时保留候选状态，玩家便能重新比较。
防止说明入口变成另一个障碍
第一种失败是把悬停换成长按，却不提供可见入口。玩家仍然不知道哪里有说明，也可能把长按理解为其他操作。长按可以作为补充方式；关键条件应直接可读，补充说明则需要明确的文字入口。
第二种失败是说明图标太难点，或紧贴立即提交区域。问题既包括“能不能打开”，也包括“尝试查看时会不会选错”。W3C 的说明列出最小目标尺寸的要求与例外。这不等于所有按钮都必须使用同一尺寸，也不能据此宣称页面获得认证。检查应同时观察说明入口与提交区域的位置及操作结果。
第三种失败是详情浮层挡住其他选项，关闭后页面又跳回顶部。需要逐项比较时，可采用原位展开，并让入口变为“收起条件”；若详情很长，可以单独呈现，但返回后应回到原选项位置。
第四种失败是只用颜色、图标或省略号表达损失。“船票图标减二”旁应有“消耗两枚船票”的文字；窄屏换行不能截掉“不可取回”。文字放大后的检查应覆盖完整条件和提交按钮，而不只是标题有没有溢出。
用一张交付检查单守住信息边界
将下面的检查单复制到每个关键选择节点，由编辑填写文案，再交给界面实现者核对：
| 检查项 | 通过时应能看到什么 |
|---|---|
| 首次进入 | 无需展开即可读到各项关键代价、可用条件和限制 |
| 查看条件 | 展开与收起均不推进剧情，折叠内容不藏关键条件 |
| 比较选项 | 相同类型的信息顺序一致 |
| 返回修改 | 候选和阅读位置仍可辨认 |
| 最终提交 | 提交动作明确，已展示的关键条件符合当前状态；采用摘要时，摘要也须与当前选择、资源状态一致 |
这份检查单只覆盖决策信息的呈现，不能代替完整的可访问性评估。摘要是可选措施，提交前核对实际条件则不依赖是否设置摘要。若资源在阅读期间变化，应先呈现新代价并让玩家重新决定；采用摘要时还要同步更新，不能沿用过期内容。
剧情未知与界面遗漏也要分开。案例可以保留收件人的回应，但不能隐去角色已经知道的票价。低剧透意味着保留尚未揭晓的后果，不意味着遮住眼前交易条件。若某项后果仅是角色推测，就写“可能”，不要在摘要里升级成保证。
限时选择还需要决定阅读是否计时，并在界面上说明。若阅读仍计时，应精简常驻文案但保留全部关键条件，减少必须展开的内容；单靠详情按钮并没有解决阅读负担。最终交付标准是：玩家不用发现隐藏手势，也能在行动之前知道自己正在交换什么。
