ARIA 替代使用表单元素超长 ID 的标签
ARIA Alternative to Labels that use the Form Element's Very Very Long ID
我正在向我们的企业平台 UI 框架添加各种辅助功能标准。我们使用 Web 客户端、DOM 元素等。我们在 DOM 中呈现所有框架,但框架中的小部件可以(多年来)由客户以非标准方式组合在一起构建他们 UI.
的各个页面
我已经设法涵盖并处理了大部分规范(我认为),但我有一个特定的案例,我们有 "texty labely widgets" 用于描述各种 "input / formlike widgets"。就 DOM 而言,它们唯一的联系是一个共同的父 "container" 元素,树上的可变距离。
我遇到的 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 来加倍该块,并且我们的内容不会被 gzip 压缩。所以这就是我要避免的。实际上,出于其他原因我也不想这样做,因为标签小部件和输入小部件实际上彼此一无所知,所以我必须编写一些额外的渲染逻辑才能让输入小部件从兄弟标签小部件。
我的问题是:有人有其他解决方案吗?
我想象的事情:
A. 是否有一些使用 aria-label 的技术,我可以在其中标记父容器并让屏幕阅读器知道如何 link 内部标签和输入?
乙。我可以将标签文本从标签小部件复制到输入小部件并使用 aria-label="duplicated text"
。我可以在服务器端做一些痛苦的事情,或者在客户端做一些笨拙的行走逻辑,但宁愿避免重复和额外的逻辑。但是,如果我这样做,那么我是否需要 aria-hide 所有现有的标签小部件?
C。是否有一些 <label for="">
或 aria-labeledby=""
的 shorthand 而不是 id,它可以通过 css 选择器或接近度来引用元素? (做梦,我知道),但这是一个镜头。
D.让用户选择加入 aria 支持,然后他们才能获得双倍的包大小。 (是的,我知道 gzip 可以解决很多问题,但为什么它没有到位这是一个很长的故事)。
简短的回答是 <input>
元素需要某种标签,并且该标签必须与 "tied to"、<input>
直接关联。 "Proximity" 不是直接关联。也就是说,仅仅因为标签是 "close" 到 DOM 中的输入,这不会将两个元素联系在一起。
一些屏幕 readers 将尝试寻找一些文本作为标签,如果没有明确找到的话,但这通常涉及到 <input>
中的前一个兄弟DOM 并且如果该兄弟有某种与之关联的文本,则将其视为标签。有时有效,有时无效。我不会依赖它。
例如,
<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>
在这种情况下,"should contain..." 文本将被视为输入的标签,这是错误的。在 <p>
之前有一个 <label>
元素并不重要。 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)绑定,密码描述通过 <input>
上的 aria-describedby
绑定].
因此,如果可能,标记输入的首选应该是原生 html。使用 <label>
.
的 for
属性
如您所述,另一种标记方法是在 <input>
本身上使用 aria-label
或 aria-labelledby
。虽然这将为屏幕 readers 提供 accessible name 的输入,但它不会帮助有视力的用户。 aria-label
不是可见的东西。但是,在您的情况下,看起来已经有一个视觉标签(即使它不是正式的 "tied" 输入)。
因此,对您的四个提案 (A-D) 发表评论:
一个。您可以将 aria-label
放在父容器上,但仍然需要告诉 <input>
查看父容器以检索标签,这是通过 [=12= 上的 aria-labelledby
完成的](并且需要父级的 ID,以便您可以指向它。)。
乙。如果将 aria-label
直接放在 <input>
上,那么是的,您应该在可见标签上设置 aria-hidden="true"
,否则屏幕 reader 用户可以导航到可见标签文本然后导航到输入并再次听到相同的文本。但这是一个奇怪的解决方案。如果文本已经可见,最好的办法是在可见文本上放置一个 ID,并通过 aria-labelledby
.
将其与 <input>
相关联
C。值得一看,但没有。
D.这是一个友好的地方,所以所有的想法都会被考虑,但请不要这样做。不要隔离不同类型的用户或强迫人们选择加入可访问的站点。
听起来您不创建可访问解决方案的主要理由是您的页面大小。不是戏剧性的,但这在法庭上是站不住脚的。也就是说,如果您的站点最终成为诉讼的被告,则争辩说您没有实施可访问性是因为您不希望页面加载更大,这将不是一个正当理由。那只是你这边的一个实现问题。
我正在向我们的企业平台 UI 框架添加各种辅助功能标准。我们使用 Web 客户端、DOM 元素等。我们在 DOM 中呈现所有框架,但框架中的小部件可以(多年来)由客户以非标准方式组合在一起构建他们 UI.
的各个页面我已经设法涵盖并处理了大部分规范(我认为),但我有一个特定的案例,我们有 "texty labely widgets" 用于描述各种 "input / formlike widgets"。就 DOM 而言,它们唯一的联系是一个共同的父 "container" 元素,树上的可变距离。
我遇到的 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 来加倍该块,并且我们的内容不会被 gzip 压缩。所以这就是我要避免的。实际上,出于其他原因我也不想这样做,因为标签小部件和输入小部件实际上彼此一无所知,所以我必须编写一些额外的渲染逻辑才能让输入小部件从兄弟标签小部件。
我的问题是:有人有其他解决方案吗?
我想象的事情: A. 是否有一些使用 aria-label 的技术,我可以在其中标记父容器并让屏幕阅读器知道如何 link 内部标签和输入?
乙。我可以将标签文本从标签小部件复制到输入小部件并使用 aria-label="duplicated text"
。我可以在服务器端做一些痛苦的事情,或者在客户端做一些笨拙的行走逻辑,但宁愿避免重复和额外的逻辑。但是,如果我这样做,那么我是否需要 aria-hide 所有现有的标签小部件?
C。是否有一些 <label for="">
或 aria-labeledby=""
的 shorthand 而不是 id,它可以通过 css 选择器或接近度来引用元素? (做梦,我知道),但这是一个镜头。
D.让用户选择加入 aria 支持,然后他们才能获得双倍的包大小。 (是的,我知道 gzip 可以解决很多问题,但为什么它没有到位这是一个很长的故事)。
简短的回答是 <input>
元素需要某种标签,并且该标签必须与 "tied to"、<input>
直接关联。 "Proximity" 不是直接关联。也就是说,仅仅因为标签是 "close" 到 DOM 中的输入,这不会将两个元素联系在一起。
一些屏幕 readers 将尝试寻找一些文本作为标签,如果没有明确找到的话,但这通常涉及到 <input>
中的前一个兄弟DOM 并且如果该兄弟有某种与之关联的文本,则将其视为标签。有时有效,有时无效。我不会依赖它。
例如,
<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>
在这种情况下,"should contain..." 文本将被视为输入的标签,这是错误的。在 <p>
之前有一个 <label>
元素并不重要。 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)绑定,密码描述通过 <input>
上的 aria-describedby
绑定].
因此,如果可能,标记输入的首选应该是原生 html。使用 <label>
.
for
属性
如您所述,另一种标记方法是在 <input>
本身上使用 aria-label
或 aria-labelledby
。虽然这将为屏幕 readers 提供 accessible name 的输入,但它不会帮助有视力的用户。 aria-label
不是可见的东西。但是,在您的情况下,看起来已经有一个视觉标签(即使它不是正式的 "tied" 输入)。
因此,对您的四个提案 (A-D) 发表评论:
一个。您可以将 aria-label
放在父容器上,但仍然需要告诉 <input>
查看父容器以检索标签,这是通过 [=12= 上的 aria-labelledby
完成的](并且需要父级的 ID,以便您可以指向它。)。
乙。如果将 aria-label
直接放在 <input>
上,那么是的,您应该在可见标签上设置 aria-hidden="true"
,否则屏幕 reader 用户可以导航到可见标签文本然后导航到输入并再次听到相同的文本。但这是一个奇怪的解决方案。如果文本已经可见,最好的办法是在可见文本上放置一个 ID,并通过 aria-labelledby
.
<input>
相关联
C。值得一看,但没有。
D.这是一个友好的地方,所以所有的想法都会被考虑,但请不要这样做。不要隔离不同类型的用户或强迫人们选择加入可访问的站点。
听起来您不创建可访问解决方案的主要理由是您的页面大小。不是戏剧性的,但这在法庭上是站不住脚的。也就是说,如果您的站点最终成为诉讼的被告,则争辩说您没有实施可访问性是因为您不希望页面加载更大,这将不是一个正当理由。那只是你这边的一个实现问题。