[Accessibility] AI对话页面消息浏览存在严重无障碍问题，视障用户无法有效使用

[baich110]

背景

我是一名视障用户，完全依赖 TalkBack（Android 屏幕阅读器）使用 Operit。在 AI 对话页面浏览消息时，遇到了严重的无障碍问题，导致几乎无法有效阅读对话内容。连最基本的消息浏览都无法正常完成，更谈不上使用其他操作功能。

经过对源码的分析，我将问题整理如下。

---

具体问题

1. 消息容器缺少语义分组 - 一条消息被拆成碎片（最严重）

相关文件： AiMessageComposable.kt、UserMessageComposable.kt

AiMessageComposable 和 UserMessageComposable 的最外层 Column 均未设置 semantics(mergeDescendants = true)。

TalkBack 下的表现： 一条 AI 消息内的 "Response" 标题、正文文本、工具调用块、工具结果块被拆成多个独立节点逐个朗读。用户听到的是一堆碎片化的内容，完全无法感知"这是一条完整的 AI 回复"。

建议修复： 在每个消息 Composable 的根容器上添加 Modifier.semantics(mergeDescendants = true)，并设置包含发送者角色和内容摘要的 contentDescription，例如 "AI回复：{内容前N字}" / "用户消息：{内容前N字}"。

---

2. 代码块等特殊内容被合成一个超长焦点，无法辨识结构（非常严重）

相关文件： StreamMarkdownRenderer、AiMessageComposable.kt

AI 回复中的 Markdown 代码块、表格等特殊内容，在 StreamMarkdownRenderer 渲染后，TalkBack 将其当作一个巨大的纯文本节点朗读。用户无法知道：

• 这是一个代码块还是普通文本
• 代码块从哪里开始、到哪里结束
• 代码的语言是什么

整段内容被"粘"在一起，TalkBack 一直读下去，极其冗长且无法快速跳过。

TalkBack 下的表现： 遇到一段 AI 回复包含代码块时，TalkBack 会把正文+代码+正文全部连在一起读，没有任何结构标记，体验极其痛苦。

建议修复：

• 为代码块添加 semantics { contentDescription = "代码块（语言：Kotlin）" } 或类似的结构化标签
• 代码块应作为独立的无障碍节点，与前后文本分开
• 考虑使用 heading() 为代码块标题添加语义，让用户可以通过 TalkBack 的标题导航快速跳过

---

3. 工具调用/结果与正文混在同一无障碍树

相关文件： CustomXmlRenderer.kt、AiMessageComposable.kt

AI 消息通过 StreamMarkdownRenderer 渲染，其中的 <tool>、<tool_result>、<think> 等 XML 块虽然各自有 contentDescription（如"工具调用块"），但它们和正文文本是平级节点。TalkBack 读起来就是"正文…工具调用块…正文…工具结果块…"，无法区分哪些是 AI 的回复、哪些是工具执行过程。

更严重的是，当一个 think 块折叠后，其中的工具调用和结果会通过 AnimatedVisibility(visible = false) 隐藏，TalkBack 完全读不到工具名称和执行结果，只剩一句"N个工具"的标题。

建议修复： 工具调用和结果应作为独立的无障碍区域，与 AI 正文明确区分。可以通过 semantics(mergeDescendants = true) 将每个工具调用+其结果合并为一个节点，并设置描述如 "工具调用：{工具名}，执行{成功/失败}"。

---

4. "Response" / "Prompt" 标题没有 heading 语义

相关文件： AiMessageComposable.kt、UserMessageComposable.kt

消息标题（"Response"、"Prompt"）只是普通 Text，没有 Modifier.semantics { heading() }。TalkBack 不把它们当作标题，视障用户无法使用 TalkBack 的标题导航功能在消息之间快速跳转。

建议修复： 为消息标题添加 heading() 语义，让用户可以通过 TalkBack 的"按标题导航"功能快速在消息之间跳转。

---

5. 流式响应缺少 liveRegion，TalkBack 不播报更新

相关文件： AiMessageComposable.kt、ChatArea.kt

AI 正在流式输出时，内容动态更新但未设置 liveRegion。TalkBack 不会主动播报新内容，用户不知道消息正在更新，也不知道何时更新完成。

建议修复： 对正在流式输出的消息设置 Modifier.semantics { liveRegion = LiveRegionMode.Polite }，让 TalkBack 在内容更新时播报。

---

6. 消息操作对 TalkBack 用户完全不可达

相关文件： ChatArea.kt（MessageItem 函数）

连基本的消息浏览都无法正常完成，MessageItem 的 combinedClickable 提供的长按菜单（复制/删除/重新生成/回滚等）更是无从谈起。长按手势对 TalkBack 用户而言不直观，且没有提供无障碍自定义操作（CustomAccessibilityAction）。

建议修复： 在消息浏览体验修复的基础上，为消息项添加 customActions，让 TalkBack 用户可以通过双击激活菜单中的操作，如复制、删除、重新生成等。

---

总体建议：基于 Compose Semantics API 重新构建消息列表的无障碍结构

当前的消息渲染架构将所有内容（正文、代码块、工具调用、工具结果、思考过程）都通过 StreamMarkdownRenderer 作为一个扁平的 Markdown 流来渲染。这种方式在视觉上表现良好，但在无障碍语义树上产生了一个无结构的扁平节点列表——有些该分开的内容粘在一起（代码块），有些不该分开的内容却被拆碎（消息标题与正文）。

建议从架构层面，直接利用 Compose 的 Semantics API 重新构建消息列表的无障碍结构：

1. 每条消息作为一个语义单元：使用 semantics(mergeDescendants = true) 将一条消息的所有内容（标题+正文+工具调用+工具结果）合并为一个 TalkBack 可朗读的节点，并附带角色标签（"AI回复"/"用户消息"）和内容摘要。

2. 消息内的结构化内容作为子语义节点：代码块、工具调用、工具结果等应在合并的语义节点内部拥有各自的 contentDescription，让用户可以在消息内部按结构导航。

3. 消息标题使用 heading() 语义：让 TalkBack 用户可以通过标题导航在消息之间快速跳转。

4. 流式消息使用 liveRegion：让 TalkBack 在消息更新时自动播报。

5. 消息操作使用 customActions：让 TalkBack 用户可以无障碍地访问复制、删除、重新生成等功能。

Compose 框架本身提供了完整的无障碍 API（semantics、mergeDescendants、heading()、liveRegion、customActions、contentDescription、stateDescription 等），只要在消息列表的 Composable 层面正确使用这些 API，就可以从根本上解决上述所有问题，而不需要在 Markdown 渲染器内部做复杂的无障碍处理。

---

影响范围

• 受影响用户群体： 所有依赖 TalkBack 的视障用户
• 严重程度： 高 - 基本无法有效使用 AI 对话功能
• 当前仓库中无任何无障碍相关 Issue，这是首个

环境

• 设备：Android 手机
• 屏幕阅读器：TalkBack
• Operit 版本：最新版

---

希望维护者能够重视无障碍体验，让视障用户也能顺畅使用 Operit。感谢！

[baich110]

参考资料补充

为了帮助维护者更好地理解和修复上述无障碍问题，以下整理了一些高质量的外部参考资料：

---

1. Google 官方 Jetpack Compose 无障碍指南（强烈推荐）

链接： https://developer.android.com/codelabs/jetpack-compose-accessibility

这是 Google 官方的 Codelab，专门讲解如何在 Jetpack Compose 中实现无障碍功能，与本 Issue 的所有问题直接相关。关键内容摘录：

mergeDescendants - 合并语义（解决"消息碎片化"问题）

使用 mergeDescendants = true 参数，让 TalkBack 将所有子元素视为单个可聚焦实体，按顺序朗读其内容描述。

这正是 Issue 中问题 1（消息容器缺少语义分组）的解决方案。

heading() 语义（解决"无法按标题导航"问题）

Text(
    modifier = Modifier.padding(4.dp)
        .semantics { heading() },
    text = annotatedString,
    style = textStyle.merge(paragraphStyle)
)

为标题添加 heading() 后，TalkBack 用户可以通过"按标题导航"功能在消息之间快速跳转。

customActions - 自定义无障碍操作（解决"操作不可达"问题）

Row(
    Modifier
        .clickable(
            onClickLabel = stringResource(R.string.action_read_article)
        ) {
            navigateToArticle(post.id)
        }
        .semantics {
            customActions = listOf(
                CustomAccessibilityAction(
                    label = showFewerLabel,
                    action = { openDialog = true; true }
                )
            )
        }
)

使用 customActions 将长按菜单中的操作暴露给 TalkBack 用户，无需长按手势即可访问。

clearAndSetSemantics - 清除冗余焦点

IconButton(
    modifier = Modifier.clearAndSetSemantics { },
    onClick = { openDialog = true }
)

将子元素的语义清除并合并到父元素，减少 TalkBack 的滑动次数。

---

2. ChatGPT 屏幕阅读器审计报告

链接： https://dev.to/wiscer/chatgpt-manual-screen-reader-audit-1d1f

这是一份对 ChatGPT 网页端的手动屏幕阅读器审计报告，其中的发现与 Operit 的无障碍问题有高度相似性：

• 流式响应不可读：审计报告指出 ChatGPT 的流式响应生成完成后，屏幕阅读器用户无法直接阅读完整回复，需要切换到浏览模式。建议通过 aria-live 或等效机制暴露完整响应。（对应 Issue 问题 5：缺少 liveRegion）

• 命令面板选项不朗读：使用 / 打开命令面板时，屏幕阅读器不会朗读当前聚焦的选项。（对应 Issue 问题 1：语义分组缺失）

• 问题分级标准：审计报告使用了 Blocker/Critical、Barrier/High、Barrier/Medium、Friction/Low 四级分类，Operit 的消息浏览问题属于 Blocker/Critical 级别——任务对屏幕阅读器用户完全不可能完成。

---

3. OpenAI 社区：TalkBack 无障碍问题反馈

链接： https://community.openai.com/t/talkback-accessibility-broken/1384918

OpenAI 社区中也有视障用户反馈 TalkBack 在 ChatGPT 应用中的无障碍问题，说明 AI 对话应用的无障碍是一个行业性问题，不是 Operit 独有的。但 Operit 作为使用 Compose 构建的原生 Android 应用，有天然优势可以通过 Compose Semantics API 系统性地解决这些问题。

---

总结

Operit 使用的 Jetpack Compose 框架本身已经提供了完整的无障碍 API，Google 官方也有详尽的指南。核心修复只需要在消息列表的 Composable 层面正确使用以下 API：

API	解决的问题
semantics(mergeDescendants = true)	消息碎片化 - 一条消息合并为一个焦点
heading()	消息标题导航 - TalkBack 可按标题跳转
liveRegion = LiveRegionMode.Polite	流式响应 - TalkBack 自动播报更新
customActions	消息操作 - 替代长按手势
contentDescription	代码块/工具调用 - 结构化标签
clearAndSetSemantics	减少冗余焦点 - 精简朗读

希望这些参考资料对修复有所帮助！

[baich110]

补充参考资料：国内AI助手无障碍现状对比及行业标准

一、国内AI助手无障碍横评：豆包断崖式领先

经过对国内视障社区（点明圈 dmq.dmrjkj.com、天坦读屏论坛 bbs.tatans.cn）的调研，国内主流AI助手的视障用户无障碍体验排名如下：

产品	视频通话	中文视觉理解	无障碍标签适配	视障用户可用性
豆包（字节跳动）	✅ 实时视频+语音	✅ 强（中文第一梯队）	✅ 标签全、语音清晰	✅ 实用性强
Kimi（月之暗面）	❌	❌	❌ 标签缺失	❌ 无法用于盲人
通义千问（阿里）	❌	❌	❌ 支持弱	❌ 无实用场景
文心一言（百度）	❌	❌	❌ 支持弱	❌ 无实用场景
DeepSeek（深度求索）	❌	❌	⚠️ 大量未加标签控件	⚠️ 安卓勉强可用，iOS不可用

关键发现：

• 豆包从11.8版本后基本无使用障碍，视障用户半年实测评价："无障碍做得顶好"
• 其他大模型"无障碍做得稀烂，满屏图片和图形按钮，摸不着头脑"（视障用户原话）
• DeepSeek 有视障用户专门写了评测《DeepSeek很火，但盲人不好用》，核心问题：登录验证码无法独立完成、大量未加标签控件、读屏无法获取消息正文
• 豆包是唯一一个让盲人"真正用起来"的国内AI助手，核心原因：按钮标签全覆盖、读屏适配、语音交互全链路打通

参考来源：点明圈视障用户实测帖 https://dmq.dmrjkj.com/social/newforum/topic/?id=739856

---

二、IT之家：国内资讯类App无障碍标杆

IT之家是国内资讯类应用中无障碍体验最好的产品之一。其特别之处在于：主动邀请视障用户深度参与产品迭代。

2019年国际盲人节，IT之家邀请视障用户"mr佳佳"撰写了技术文章《改善视障用户的网页体验就这么简单》，公开分享了IT之家做过的无障碍优化：

1. HTML lang属性 - 解决屏幕阅读器读不出中文的问题
2. WAI-ARIA路标导航 - 为页面区域添加语义标记（navigation、main、search等）
3. 图片alt描述 - iOS版文章界面图片全部添加无障碍替代文本
4. 合并焦点 - 资讯列表项合并为单个焦点，避免焦点过于分散
5. TAB键支持 - 自定义可点击控件添加tabindex
6. 持续修复 - 7.23版本修复无障碍模式语音朗读语速语调问题，7.21版本改进表情功能无障碍操作

视障用户原话："在国内资讯类应用中，IT之家的无障碍体验可能是最好的了。"

参考来源：IT之家 https://www.ithome.com/0/452/512.htm

---

三、国家团体标准：移动应用无障碍评测规范

中国已有正式的无障碍团体标准：

《移动应用内容可访问性信息无障碍技术服务评测规范指引》（T/TAF）

• 发布机构：电信终端产业协会（TAF）
• 起草单位：中国信通院、腾讯、字节跳动、阿里巴巴、百度、蚂蚁集团、小米、vivo、深圳信息无障碍研究会
• 核心要求涵盖四大维度：
  • 可感知性：非文本内容必须有替代文本、验证码必须提供多感官替代方案
  • 可操作性：所有非装饰性组件必须可被辅助工具正常访问和聚焦
  • 可理解性：内容呈现不应单独依赖感官特性（如颜色）
  • 兼容性：与辅助技术兼容

参考来源：http://www.taf.org.cn/upload/notice/2022-0125-153232-3150517.pdf

---

四、对 Operit 的启示

1. 行业趋势：国内头部厂商（字节、腾讯、阿里、百度）已联合制定无障碍标准，豆包已实现视障用户可用级别，AI助手无障碍正在从"可选项"变为"必选项"
2. 用户参与：IT之家和豆包的成功经验都证明——请视障用户深度参与产品迭代是无障碍做好的关键
3. 技术路径明确：国家标准已给出清晰的技术要求（可感知性/可操作性/可理解性/兼容性），本 Issue 提出的 Compose Semantics 方案与之完全对应
4. Operit 的机会：目前开源AI助手领域无障碍几乎空白，Operit 若率先做好，将成为开源AI应用的无障碍标杆

希望这些行业背景信息能帮助维护者评估无障碍优化的优先级和方向。

[baich110]

补充参考资料：GitHub 官方开源无障碍规则与倡议

一、GitHub 开源指南：无障碍最佳实践

GitHub 官方开源指南（opensource.guide）发布了**《Accessibility Best Practices for Your Project》**，为所有开源项目提供无障碍实践指南。这是 GitHub 官方对开源社区的无障碍要求和建议。

来源：https://opensource.guide/accessibility-best-practices-for-your-project/

1. 项目层面要求

GitHub 建议每个开源项目：

• 创建 ACCESSIBILITY.md 文件，声明项目的无障碍承诺，设定可衡量的目标（如 WCAG AA）
• 创建无障碍 Issue 模板（.github/ISSUE_TEMPLATE/accessibility.yml），包含：
  • 预期行为 vs 实际行为
  • 复现步骤（含可选录屏）
  • 使用的工具（OS、浏览器、辅助技术及版本）
  • 严重程度分级：
    • Critical：阻止用户完成核心任务（如"无法结账"）
    • High：严重困难但存在变通方法
    • Medium：令人烦恼或体验不一致
    • Low：对可用性影响较小的轻微问题
• 创建 PR 无障碍检查清单（.github/pull_request_template.md），包含：
  • 键盘导航端到端可用
  • 焦点状态可见且逻辑合理
  • 表单有标签且错误被朗读
  • 颜色不是唯一指示器
  • 尊重减少动画偏好
  • 至少进行一次屏幕阅读器测试
• CI/CD 中引入无障碍扫描，PR 引入违规直接失败

2. 界面层面要求

• 所有交互元素必须键盘可达
• 每个表单控件必须有关联标签
• 动态内容更新必须用 ARIA live region 通知辅助技术
• 触摸目标至少 24×24 CSS 像素
• 不能仅靠颜色传达信息
• 使用原生语义元素，ARIA 仅在原生不足时使用（"No ARIA is better than bad ARIA"）

3. 处理无障碍 Issue 的原则

GitHub 明确要求维护者：

• 感谢报告者，不带怀疑地提问
• 优先处理阻塞性问题（无法完成核心流程）
• 尽可能提供临时解决方案
• 与报告者确认修复

原文："Treat accessibility reports as expertise, not complaints - they may represent more people than you think."

---

二、GitHub 公司无障碍战略（2026）

2026年5月，GitHub 发布了官方无障碍战略（accessibility.github.com），四大优先方向：

来源：https://github.blog/open-source/building-githubs-next-chapter-in-accessibility/

1. 大规模改善开源无障碍 — 承诺三个目标：赋能残障人士参与开源、增加开源辅助技术、改善主流开源项目无障碍
2. 举办开源辅助技术黑客松 — 2026年在旧金山总部举办首届，16个featured项目
3. 开源无障碍峰会 — 2025年10月首届，300人注册、500人候补，产出六大优先挑战领域和协作路线图
4. 开源无障碍工具 — 开源了 Figma Annotation Toolkit 和 AI 无障碍扫描器（基于 axe-core）

关键数据：

• 48% 的无障碍问题可以在设计阶段预防
• GitHub Copilot 自动分析无障碍报告，自动填充约 80% 的 Issue 元数据
• 问题解决时间降低 62%，89% 的 Issue 在 90 天内关闭

---

三、GitHub 建议的开源项目无障碍文件结构

ACCESSIBILITY.md                          # 无障碍声明与承诺
.github/ISSUE_TEMPLATE/accessibility.yml  # 无障碍 Issue 模板
.github/pull_request_template.md          # PR 无障碍检查清单

GitHub 还提供了示例文件：

• ACCESSIBILITY.md 示例
• 无障碍 Issue 模板示例
• PR 模板示例

---

四、对 Operit 的具体建议

基于 GitHub 官方指南，Operit 可以立即采取的行动：

1. 创建 ACCESSIBILITY.md — 声明无障碍承诺，列出已知限制和报告渠道
2. 添加 accessibility Issue 标签 — 本 Issue（[Accessibility] AI对话页面消息浏览存在严重无障碍问题，视障用户无法有效使用 #735）就应打上此标签
3. 创建无障碍 Issue 模板 — 引导用户报告时提供辅助技术、系统版本等信息
4. 在 PR 模板中加入无障碍检查项 — 至少包含"屏幕阅读器测试"一项
5. 参考 GitHub 官方建议的严重程度分级 — 本 Issue 中的6个问题均属于 Critical 级别（阻止视障用户完成核心任务——阅读消息）

GitHub 自己都在大力推动开源无障碍，作为 GitHub 上的开源项目，跟进这些最佳实践既是责任也是机会。

[baich110]

@AAswordman 你好！作为仓库的主要维护者，想麻烦你看一下这个 Issue。

我是一名视障用户，完全依赖 TalkBack 屏幕阅读器使用 Operit。目前在 AI 对话页面，消息列表的无障碍存在严重问题，导致视障用户基本无法正常浏览消息。

本 Issue 详细列出了 6 个具体问题，并附上了：

• 相关源码文件定位和问题分析
• 基于 Compose Semantics API 的修复建议
• Google 官方 Jetpack Compose 无障碍指南和代码示例（评论1）
• 国内 AI 助手无障碍横评（豆包已做到视障可用）及国家团体标准（评论2）
• GitHub 官方开源无障碍最佳实践指南（评论3）

这些问题按 GitHub 官方严重程度分级均属于 Critical 级别--阻止视障用户完成核心任务（阅读消息）。

Operit 作为 Android 上最强大的 AI Agent 应用，如果能在无障碍方面率先跟进，将成为开源 AI 应用中的无障碍标杆。希望能引起重视，感谢！