在Web开发中，为表单元素提供无障碍标签是至关重要的。当一个输入框同时拥有`
理解“重复标签”无障碍性错误
当您使用无障碍性检测工具（如ARC Toolkit）扫描网页时，可能会遇到“重复标签”或“冗余标签”的警告。这类错误通常指向一个输入控件，它通过多种方式提供了相同的可访问名称，最常见的情况是同时使用了HTML的<label>元素和WAI-ARIA的aria-label属性。
考虑以下HTML结构：
<form onsubmit="return false;" class="city-form-inner">
<div id="ember506" class="wrap-autocomplete ember-view">
<label for="search-locations-address">Enter ZIP, State or City</label>
<div class="autocomplete-input">
<input aria-label="Enter ZIP, State or City"
role="combobox"
aria-expanded="false"
type="text"
name="search-locations-address"
id="search-locations-address"
class="form-control ember-text-field ember-view ui-autocomplete-input"
autocomplete="off">
</div>
<div role="status" aria-live="polite" class="autocomplete-status">0 results are available, use up and down arrow keys to navigate</div>
</div>
<input type="button" value="Find Stores" class="btn-blue submit" data-ember-action="" data-ember-action-513="513">
</form>在这个例子中，id="search-locations-address"的<input>元素同时具备：
- 一个通过for属性与其关联的<label>元素，文本内容为“Enter ZIP, State or City”。
- 一个aria-label属性，其值同样为“Enter ZIP, State or City”。
尽管从视觉上看，用户只会看到一个标签，但对于辅助技术而言，这种双重声明，尤其是当内容完全一致时，构成了冗余。
aria-label与<label>的优先级规则
要理解为何这会触发警告，我们需要参考W3C的无障碍名称计算（Accessible Name Computation, ANC）规范。该规范定义了浏览器和辅助技术如何为UI元素计算可访问名称（Accessible Name），这是屏幕阅读器等辅助技术向用户传达元素目的的关键信息。
根据ANC规范的计算步骤，aria-label属性在确定元素的无障碍名称时，其优先级高于通过<label>元素提供的标签。具体来说：
- 步骤 2C： 检查元素是否存在aria-label属性。如果存在，其值将作为元素的无障碍名称。
- 步骤 2D： 如果aria-label不存在，则检查元素是否由<label>元素标记（通过for属性或嵌套）。
这意味着，在上述示例中，由于<input>元素上存在aria-label="Enter ZIP, State or City"，浏览器会直接使用这个值作为其无障碍名称，而与它关联的<label for="search-locations-address">Enter ZIP, State or City</label>则会被忽略。
为什么冗余标签是问题？
尽管在某些情况下，这种冗余可能不会直接导致功能性错误，但它仍被视为不良实践，原因如下：
- 代码冗余与维护： 拥有多余的代码会增加HTML的复杂性，降低可读性，并可能在未来维护时引入混淆。如果标签文本需要更新，开发者可能会忘记同时修改aria-label和<label>，导致两者不一致。
- 无障碍性工具警告： 无障碍性检测工具旨在识别潜在问题和最佳实践违规。冗余标签虽然不总是“破坏性”的，但它表明代码结构不够优化，可能会掩盖更严重的无障碍性问题。
- 潜在的混淆： 尽管aria-label优先，但在某些边缘情况下或不同的辅助技术组合下，冗余可能导致意外行为或额外的处理负担。
解决方案：优化无障碍标签
解决“重复标签”问题的最佳方法是遵循“单一信息源”原则，即为每个输入控件选择最合适且唯一的无障碍名称提供方式。
最佳实践：移除冗余的aria-label
当一个<input>元素已经通过<label>元素与其视觉标签语义化关联时（使用for和id属性），并且aria-label的内容与<label>完全一致，那么aria-label就是多余的。在这种情况下，应该移除aria-label属性。
优化后的代码示例：
<form onsubmit="return false;" class="city-form-inner">
<div id="ember506" class="wrap-autocomplete ember-view">
<label for="search-locations-address">Enter ZIP, State or City</label>
<div class="autocomplete-input">
<input role="combobox"
aria-expanded="false"
type="text"
name="search-locations-address"
id="search-locations-address"
class="form-control ember-text-field ember-view ui-autocomplete-input"
autocomplete="off">
</div>
<div role="status" aria-live="polite" class="autocomplete-status">0 results are available, use up and down arrow keys to navigate</div>
</div>
<input type="button" value="Find Stores" class="btn-blue submit" data-ember-action="" data-ember-action-513="513">
</form>通过移除aria-label，<input>的无障碍名称将通过其关联的<label>元素正确提供，代码也变得更简洁和符合规范。
何时使用aria-label
虽然在上述情况下应移除aria-label，但在某些特定场景下，aria-label是提供无障碍名称的有效且推荐的方式：
-
无可见标签的元素： 当UI设计要求某个交互元素（如仅图标的按钮）没有可见文本标签时，aria-label可以提供其功能描述。
<button aria-label="关闭对话框" class="close-button">❌</button>
- 视觉标签不足以描述： 当视觉上显示的标签过于简洁或需要更详细的上下文来辅助理解时，aria-label可以提供更丰富的描述。
- 非表单控件的元素： 对于一些非表单控件（如自定义组件或区域），可能没有天然的<label>元素可以关联，此时aria-label可以提供无障碍名称。
注意事项与总结
- ID的唯一性： 虽然本教程主要关注aria-label与<label>的优先级，但确保HTML文档中所有id属性的唯一性是无障碍性和JavaScript操作的基础。如果您的表单在不同位置（如主页面和模态框）出现，请确保它们内部的id属性是唯一的。例如，在模态框中的表单元素可以添加前缀，如modal-search-locations-address。
- 测试的重要性： 始终使用多种无障碍性工具（如Lighthouse, ARC Toolkit, axe DevTools）进行自动化测试，并结合实际的屏幕阅读器（如NVDA, JAWS, VoiceOver）进行手动测试，以确保您的实现真正符合无障碍性标准。
- 理解WAI-ARIA： WAI-ARIA（Web Accessibility Initiative - Accessible Rich Internet Applications）规范为开发者提供了增强Web内容和Web应用程序无障碍性的方法。正确理解和应用ARIA属性是构建无障碍Web体验的关键。
通过遵循这些最佳实践，您可以避免常见的“重复标签”无障碍性错误，并构建出更健壮、更易于访问的Web应用程序。记住，简洁、语义化的HTML结合有目的性的ARIA使用，是实现卓越无障碍性的基石。
