HTML评分对星星组件的影响与依赖全解析

修改 aria-valuetext 为什么对HTML评分没有帮助？

这个问题，很多开发者都遇到过。Lighthouse在检查HTML时，例如“表单控件有恰当的标签”或“使用语义化标签”这些项目，它只会查找静态标记，比如 aria-label、aria-labelledby、legend 等。它不会执行你的JavaScript，也不会监听任何属性的动态变化。 这就意味着，即使你在 change 事件中把 aria-valuetext 更新得再详细，Lighthouse扫描时看到的也仅仅是它的初始值，或者是空值。它不会认可这个动态变化。 那么，真正影响HTML评分的是什么？

• 你是否使用
  +
  包裹整个评分组？
• 每一个 是否有对应的 ？
• 所有单选框的 name 属性是否统一且不为空？

aria-valuetext 是为屏幕阅读器等运行时工具设计的，Lighthouse的静态解析器并不关心它。所以，要提升HTML评分，重点应该放在这些基础结构上：有没有漏写 for 属性？id 和 for 的值是否拼写错误？legend 中的文本是否为空？

使用 input[type="range"] 实现星星评分，一个典型的“双输”选择

使用 input[type="range"] 来实现星星评分，看似简化了代码，但实际上在HTML评分和用户可用性两方面都不划算。

• 评分上吃亏：Lighthouse会直接报“表单控件缺少关联标签”。因为 range 和 label 本身不太匹配，更难用 legend 来表达控件的分组意义。即使你添加了 aria-label，也无法传达“五星制”的完整语义信息。
• 语义上脱节：浏览器不会因为你设置 value="4" 就自动渲染成“四颗实心星星”。你需要靠CSS的刻度线或JavaScript来绘制图标，导致DOM结构和实际语义分离。
• 键盘操作不友好：对于键盘用户，按左右方向键只能单步移动1。如果忘记设置 min="1" 和 max="5"，值可能滑出1到5的合法范围。而使用radio组，天然限制在这个范围内，不会出错。
• 触摸体验差：在移动设备上，range 滑块的点击区域较窄，误操作概率高。相反，星星组件中每个星星的点击区域可以轻松扩展到整个 label，用户体验更好。

动态表格里多组星星，name 冲突会有什么后果？

如果你的表格中有多行星星评分，但所有单选框都使用同一个 name="rating"，这不会导致HTML评分直接归零，但会触发多个严重的扣分项。 关键问题在于：所有同名 input[type="radio"] 会被浏览器视为一组。如果10行都用同一个 name，Lighthouse会认为你只提供了一个评分控件，其他9行都没有表单语义，从而扣除“表单结构清晰”这一项的得分。 另外，如果每行都有 id="star1"，那就是重复ID，直接违反HTML规范。Lighthouse会在“ID重复”这一项上标红，这属于基础合规性错误，非常明显。 解决这个问题，不能靠JavaScript事后补救，必须在生成时保证唯一性。例如：name="rating-event-123"、id="rating-event-123-star3"、for="rating-event-123-star3"。同时，CSS选择器不能硬写 #star3，应该使用属性选择器如 input[id$="-star3"]，或者直接依靠class来控制样式。 说白了，真正影响性能的从来不是Lighthouse的静态HTML评分，而是你在运行时里的操作，比如用 document.querySelectorAll('.star') 在每次hover时重新查询DOM，或者用 innerHTML 整行重绘星星。这些行为与Lighthouse的静态分数毫无关系。