bug-reporting

用途：在提交、审查或生成无障碍缺陷报告时应用统一规范，适用于自动化工具输出、人工测试、用户反馈以及残障人士参与测试等来源。核心要求是让报告能说明障碍是什么、影响谁、如何复现、影响程度、责任来源与如何验证修复；不以缺少选择器、工具规则、WCAG 映射或代码级修复为由拖延有效报告。\n\n主要能力：区分发现、问题、出现位置、根因等术语；给出严重度分级（Blocker、Major、Moderate、Minor、Needs review，属示例尺度，需结合本地实际校准），并要求将严重度与优先级、影响范围、频率、置信度分开记录，不因多处出现而自动升级单处严重度。要求先描述障碍再对应标准，区分用户报告、残障人士测试、人工评估、自动化结果与推断等证据基础，并记录事实、假设、疑似原因与建议修复。\n\n使用方式：有效受理至少包含标题、位置/状态、任务与影响、实际结果、证据基础。技术定位、标准映射与验证计划由分诊后续补充，不应要求报告者提供。标题应写明组件、失败与后果，例如“结算：卡号错误文本未与字段关联”。位置需安全脱敏，移除会话标识、令牌、邮箱、姓名、账号等；用测试账号而非生产凭据。定位优先使用人类可读组件名，必要时补充稳定选择器，绝对 DOM XPath 不应强制。步骤包含前置条件与最短可靠路径；期望结果写用户可见的结果而非具体 ARIA/JS 实现；实际结果记录观察与辅助技术输出。环境只记录与结果相关的浏览器、系统、辅助技术、输入方式、视口、缩放、色彩偏好与语言。证据可选，需去除个人数据、凭据与私密内容，截图用文字描述，不以颜色为唯一信息。\n\n标准与工具：记录确切的 WCAG 版本、准则与级别，不确定时标为疑似或待审查；工具结果需保留工具与版本、规则 ID、配置、测试方法与原始结果，并注明人工复核状态。工具的影响/置信度不等同项目严重度；不应仅因工具打标签而添加准则。义务性与处理方式独立于 WCAG 映射，obligation 可为 required、aspirational、advisory、unmapped、not-applicable；handling 可为 report、review、suppress，未解决的自动化指标应先送 review，suppress 需有范围、原因、证据、负责人与复核或到期日。须规划互补测试：自动化、人工评估与残障人士测试回答不同问题，不能互相替代；自动化通过不能作为用户障碍消失的充分证据。验证收尾不能仅凭代码变更、自动化通过或目视检查。\n\n限制：具体实施规则以其示例文件为权威；资料未提供该技能的安装方式、平台支持、费用与许可信息。