Question

我正在将各种辅助功能标准添加到我们的企业平台UI框架中。我们使用Web客户端，DOM元素等。我们在DOM中呈现所有框架，但是框架中的小部件可以（并且已经使用了很多年）由客户以非标准的方式组合在一起，以构建其UI的各个页面。

我已经设法涵盖并处理了许多规范（我认为），但是我有一个特定的案例，其中我们有用于描述各种“输入/类似表单的窗口小部件”的“文本标签窗口小部件”。就DOM而言，它们唯一的连接是公共父“容器”元素，该元素在树上的距离可变。

我遇到的ARIA准则（在任何时候我都可能会误解了）建议我需要在实际的表单元素上使用aria-labeledby="id_of_text_label_widget"。我现在的意思是：

<div id="parent_label_value_widget_001">
  <div class="inputLabel">This is visible Label Text</div>
  <div class="various_other_junk_in_here"></div>
  <div class="some_wrapper_around_the_input">
    <input id="I_am_the_form_input_in_question_with_a_very_long_id" value="42">
  </div>
</div>

我可以轻松地将aria-labeledby属性添加到输入中，但这意味着我需要在inputLabel元素中添加一个ID。虽然这似乎没什么大不了（因为您在DOM中看到的是来自断开的小部件的WYSIWYG编辑器的渲染周期要复杂得多的结果，所以它稍微复杂了一点）它恰好是没有更改的可能性，我们的ID已经非常长了。由于页面庞大，有时会出现成千上万个字段以及嵌套的动态事物等

我们的ID占有效载荷的60％。而且，我实际上必须通过向每个标签元素添加一个新的id来使该块增加一倍，并且我们的内容不会被压缩。所以这就是我要避免的事情。我实际上也不想这样做，因为标签小部件和输入小部件之间实际上一无所知，所以我不得不编写一些额外的渲染逻辑，以使输入小部件从ID中提取ID。兄弟标签小部件。

我的问题是：还有其他解决方案吗？

我想像的东西： A.是否有使用aria-label的技术，我可以在其中标记父容器并让屏幕阅读器知道如何链接内部标签和输入？

B。我可以将标签文本从标签小部件复制到输入小部件上，然后使用aria-label="duplicated text"。我可以为服务器端做些痛苦的工作，或者为客户端做一些笨拙的行走逻辑，但宁愿避免重复和多余的逻辑。但是，如果我这样做了，那么我是否需要对所有现有的标签小部件进行aria-hide隐藏？

C。是否有<label for="">或aria-labeledby=""的简写形式，它可以通过css选择器或接近来引用元素而不是id？（做梦，我知道），但这只是一个镜头。

D。让用户选择使用aria支持，然后他们才能获得两倍的软件包大小。（是的，我知道gzip可以解决很多问题，但是为什么它没有就位了，这是一个很长的故事。）

Answer 1

简短的答案是<input>元素需要某种标签，并且该标签必须直接与<input>关联或“捆绑”。 “邻近”不是直接关联。也就是说，仅因为标签“接近” DOM中的输入，才不会将两个元素联系在一起。

如果未明确找到某些屏幕阅读器，它们会尝试查找一些文本用作标签，但这通常涉及到DOM中<input>的上一个同级，并且该同级中有一些与之关联的文本，然后将其视为标签。有时它起作用，有时却不起作用。我不会依靠它。

例如，

<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>

在这种情况下，“应该包含...”文本将被视为输入的标签，这是错误的。在<label>之前没有<p>元素没关系。 DOM中没有将<label>绑定到<input>的内容。上面的示例应写为：

<label for="pw">password</label>
<p id="rules">should contain upper and lower case letters, a number, and a special character</p>
<input id="pw" aria-describedby="rules">

这会将两个文本元素与输入相关联。 <label>通过for属性（和<input>上的ID）直接绑定，密码说明通过{{1}上的aria-describedby绑定}。

因此，如果可能的话，标记输入的首选应该是使用本机html。使用<input>的{{1}}属性。

如上所述，另一种标记方法是在for本身上使用<label>或aria-label。尽管这会为屏幕阅读器提供一个accessible name输入，但对视力不佳的用户没有帮助。 aria-labelledby不是可见的东西。但是，在您的情况下，看起来好像已经有一个可视标签（即使未正式“捆绑”到输入中）。

因此，对您的四个提案（A-D）进行评论：

A。您可以将<input>放在父容器上，但仍需要告诉aria-label查看父容器以检索标签，这是通过在{{1}上使用aria-label来完成的}（并且需要在父级上有一个ID，以便您可以指向它。）

B。如果将<input>直接放在aria-labelledby上，则可以，应在可见标签上设置<input>，否则屏幕阅读器用户可以导航到可见标签文本，然后导航到输入并再次听到相同的文本。但这是一个奇怪的解决方案。如果文本已经可见，最好的办法是在可见文本上放置一个ID，然后通过aria-label将其与<input>关联。

C。值得一提，但没有。

D。这是一个友好的地方，因此将考虑所有想法，但请不要这样做。不要隔离不同类型的用户，也不要强迫人们选择加入可访问的网站。

听起来，不创建可访问的解决方案的主要论据是页面的大小。并不是很戏剧性，但这在法庭上不会成立。就是说，如果您的站点最终成为诉讼的被告，则因为您不希望页面加载量更大而声称您未实现可访问性将不是有效的理由。那只是您的实现问题。

ARIA替代使用表单元素的非常长ID的标签

1 个答案: