J1.07.3attribution of disability设计研究
该模型改变责任归属
别名: 责任归属 · who is responsible · 缺陷还是需求
概念解释
把过不了关写成「请换一台能看的设备」或「请去学屏幕阅读器」，责任就落在使用者身上。把同一件事写成产品缺陷——主按钮没有名称、流程没有键盘通路——责任就落到发版的组织。社会模型改的不是口号，是责任归属（attribution of disability）：谁有义务改下一刀，预算记在哪一栏，这算缺陷还是「特殊需求」。
机制
医学归因把适应当成用户的作业：辅助技术自备、培训自理、「我们支持主流浏览器」。社会归因把同一缺口送进产品待办：组件要有名称和角色，组织要有人维护。第二层是归类决定优先级语言。记成功能请求，它和皮肤主题抢同一排期；记成缺陷，它挡住发布。客服话术、采购合同、事故复盘都会复制这套归类——「用户没开字幕」和「播放器不提供字幕」是两种完全不同的账单。
怎么研究
访谈产品、设计、工程、法务，看他们把同一失败归给谁：用户、辅助技术厂商、浏览器，还是自己的界面。分析缺陷跟踪里无障碍条目的类型标签（bug / 需求 / Won't fix）和关闭理由。
自变量：报告模板是否强制写「环境里缺了什么」；评审里谁有权把条目改成缺陷。 因变量：标签分布、从报告到修复的负责人、关闭理由里「请用户使用辅助技术」出现的次数。
不要把问卷里的态度分当成责任已经转移——要看待办和发布门禁里钱和否决权在谁手里。
边界
使用者仍然有策略，辅助技术仍然存在；社会模型不是让产品团队承办医疗。操作系统、浏览器、阅读器厂商有自己的责任面，不能把平台缺陷全记在应用头上，但「等系统先修好」也不能当关闭理由——应用仍要在现有平台上提供通道。内部工具、实验功能如果明确声明范围，责任边界可以收窄，声明本身必须让被排除的人读到。
怎么落地
- 无障碍失败默认进缺陷队列，不进「增强」或「特殊需求」。关闭必须写产品侧未完成的通道，禁止只写「用户应使用某某工具」。
- 发布门禁指定否决权：关键路径缺键盘通路或名称，谁可以挡住发版。
- 客服回复先给产品侧的替代做法和修复预期，再给用户侧的变通，不要第一句把问题推回去。
- 验证：抽已关闭的无障碍工单，看关闭理由和标签。凡是责任写在用户或外部工具上、产品未改通道的，重新打开。对照发版记录，确认这类工单曾经能否挡住发布。