J5.07.3mobile vs desktop screen reader设计研究
移动端与桌面端的交互模型不同
别名: 移动阅读器 · 桌面阅读器 · 轻扫与快捷键
概念解释
桌面上，阅读器用户用键盘在对象之间跳、用快捷键点名一类元素；手机上，同一家阅读器改成沿对象轻扫、用转子选类型、用触摸探索点下的那一个。两边都叫「屏幕阅读器」，交互模型不是同一套。桌面测过，不等于移动能用。
机制
输入硬件不同，命令就不同。桌面有一整排键：跳标题、跳地标、打开元素列表。移动端没有这些键，主移动方式是线性轻扫，类型过滤靠转子，位置瞄准靠手指点屏幕。于是同一棵树在两边被走成不同的路径：桌面可以「直接点名第三个标题」，移动常常要扫过中间那些对象，或先拧转子再扫。
失败模式跟着模型走。桌面上的跳过导航、焦点顺序、快捷键冲突，在移动上变成轻扫顺序、触摸探索命中、手势被应用抢走。引擎名字相同（都叫 VoiceOver）也不能把 macOS 的通过抄到 iOS 上——命令集、触控层、系统手势都不一样。
怎么研究
同一站点或同一 App 的对应页，桌面用键盘走主任务，移动用 VoiceOver 或 TalkBack 只用系统手势走同一任务。禁止在移动上接外接键盘来「顺便」复用桌面脚本。
自变量：设备类别（桌面 / 手机）、导航方式（快捷键 / 轻扫 / 触摸探索）。 因变量：到达目标的步数、是否必须改用另一种手势、被应用手势拦截的次数。
记录用户实际采用的命令，不要假设他们会在手机上寻找桌面快捷键的等价物。
边界
平板介于两者之间：有的人接键盘当桌面用，有的人当大号手机轻扫，两种模型都要能成立。纯桌面产品没有移动模型可测；反过来，只有移动端的产品，桌面阅读器的键盘脚本帮不上忙。外接键盘一旦接到手机上，模型会向桌面靠，这时测到的不再是默认移动模型。不要把两种模型的差别写成阅读器内部如何切模式——那是另一层机制；这里只问用户手上的命令是不是同一套。
怎么落地
- 主任务分别写两份脚本：桌面键盘、移动系统手势，不要共用一份「Tab 过去」。
- 移动上确认轻扫顺序可完成任务，转子里能找到标题或表单控件，触摸探索能点中可见目标。
- 验证：手机开阅读器、不接键盘，只许轻扫和转子走完结账或发帖。桌面上靠快捷键才成立、在轻扫里找不到的入口，移动模型还没被测到。