哦操，我的应用成功了，但我压根没考虑无障碍

独立的可访问版本 vs 包容性设计

• 有人提出制作独立的“低视力”/“低触控精度”版本，或仅数据前端。
• 也有人认为这不现实：组织不会维护功能对等，次级应用最终会荒废。
• 类比响应式设计：与其做多个站点，不如有一个能自适应的 UI。
• 法律与伦理上的反对意见：所谓“分开但平等”很少真的平等；很难长期保证功能对等。

法律责任与监管

• 在美国，针对网站和应用的 ADA 诉讼正在增加；通常赔偿和解金额不高，但整改成本高昂。
• 某些领域（大学、招聘网站、政府）面临更大压力，因为无障碍缺失会阻碍受保护活动。
• 欧盟《无障碍法案》（自 2025 年起）将要求许多产品/服务具备无障碍能力；微型企业可能豁免，但仍受到鼓励。
• 一些人认为必须通过执法来推动，否则激励太弱；另一些人则认为这属于侵权滥用和监管负担。

优先级、成本与初创公司

• 常见观点：早期产品应优先考虑生存和产品-市场契合，之后再加入 a11y。
• 反方观点：像安全或可扩展性一样，若从一开始就考虑，基础 a11y 的成本更低（例如 alt 文本字段、非拖拽替代方案、语义化 HTML）。
• 对影响的分歧：有人把受影响用户视为很小的边缘群体；也有人指出统计数据表明这是相当大的市场份额。

道德与亲身经验论点

• 多个个人故事（失明、低视力、轮椅、截肢、带婴儿车养育孩子）表明，设计选择会在实质上决定日常生活能否顺利进行。
• 许多人强调，几乎每个人最终都会出现残障，或者经历暂时性障碍。
• 一些残障读者描述了在提出 a11y 问题时遭遇的敌意或轻视，以及一再为自身需求辩护的疲惫。

技术方法与工具

• 强烈建议：
  • 使用原生 UI 组件和操作系统无障碍 API（iOS、Android、现代工具包如 Flutter、SwiftUI、Compose、GTK）。
  • 依赖语义化 HTML、正确的 role、label，并仅在必要时使用 ARIA。
  • 避免试图“外挂”无障碍的 overlay 小部件，这类方案往往让 UX 更糟，也增加法律风险。
  • 使用屏幕阅读器、大字号、高对比度模式和无障碍树进行测试。
• 有人指出浏览器和辅助技术可以做得更多（ML 转换、更好的基础原语），但也有人认为，若不“把所有玩具都拿走”，就无法在浏览器层面修复糟糕的自定义组件。

无障碍对所有人都有益

• 例如：坡道和路缘切口、字幕、更大的点击目标、高对比文本、减少动态效果、键盘导航、供多任务使用的屏幕阅读器。
• 表述建议：把 a11y 看作灵活性和用户控制，而不仅仅是残障适配。

争议与反弹

• 少数人认为 a11y 主要服务于非常小的人群，成本过高，或者应该由用户通过“特殊浏览器”自行解决。
• 其他人强烈反驳，称这不道德，并指出许多工作其实很小：标签、对比度、语义。
• 关于强制措施应走多远、如何平衡成本与包容性的分歧；有人希望严格监管，也有人担心这会巩固大型现有企业。

术语与沟通

• 关于数字缩写 “a11y” 的争论：有人喜欢它的可发现性和 “ally” 的双关；另一些人指出它对屏幕阅读器不够友好，而且就无障碍而言，这种说法多少有些讽刺。