TinyMCE 辅助功能:标签

发布于 2024-10-03 20:17:29 字数 708 浏览 6 评论 0原文

我们的一个 Web 应用程序刚刚通过了 508 合规性测试。我们使用 TinyMCE 版本 3 进行内容开发,据我了解它通常具有良好的可访问性。然而,我们的一个页面包含 3 个或更多 TinyMCE 实例,每个实例前面都有一个标签,指示 TinyMCE 实例的用途,但我们被告知这些是“隐式”标签,而它们应该是“显式”标签标签(即带有 for 属性)。问题是,TinyMCE 实例只是带有各种复杂的自定义 html“控件”的 iframe,而据我所知,label/for 技术仅适用于传统的表单元素。为 TinyMCE 实例实现“显式”标签的最佳策略是什么?

谢谢!

编辑

使用 label + for 探索的解决方案不起作用:将 label 指向初始 textarea,将标签指向生成的iframe

我正在探索的一种可能的解决方案是用 ledgend + fieldset 包围每个 TinyMCE 实例,但使用 JAWS 9.0 测试它似乎没有任何区别,除非 fieldset 包含表单元素(例如inputtype=text)并且JAWS 处于表单模式。

One of our web applications just went through 508 compliance testing. We use TinyMCE version 3 for content development and I understand it generally has good accessibility. However, one of our pages contains 3 or more TinyMCE instances each preceded by a label indicating what the TinyMCE instance is for but we are being told that these are "implicit" labels when they should be "explicit" labels (i.e. with the for attribute). Problem is, TinyMCE instances are just iframes with a complex assortment of custom html "controls", whereas as far as I know the label/for technique only works with traditional form elements. What's the best strategy for achieving an "explicit" label for a TinyMCE instance?

Thanks!

Edit

Solutions explored using label + for which don't work: pointing the label at the initial textarea, pointing the label at the generated iframe.

One possible solution I am exploring is encompassing each TinyMCE instance with a ledgend + fieldset but testing this out with JAWS 9.0 it doesn't seem to make any difference unless the fieldset contains form elements (e.g. input, type=text) and JAWS is in forms mode.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

意犹 2024-10-10 20:17:29

有一个新兴标准专门针对此类问题:ARIA(可访问的富互联网应用程序)。它仍然是一个工作草案,但当与最新的浏览器(IE 9、Firefox 3.6(部分)和 4.0、Chrome)一起使用时,最新的屏幕阅读器(JAWS 9、最新版本的 NVDA)开始显示支持。

在这种特殊情况下,请查看 aria-标签aria-labelledby。这些属性将添加到 TinyMCE 小部件中的 BODY 元素中,或者添加到 IFRAME 中,无论用户输入数据时两者中的哪一个实际获得焦点。因此:

<body aria-label="Edit document">

aria-label 属性仅指定用作标签的字符串。 aria-labelledby(注意两个 L,按照英国拼写)的工作方式与传统的 LABEL 元素相反。也就是说,您向它提供一个 ID:

<body aria-labelledby="edit-label">

然后您将在代码中的其他位置找到它:

<label id="edit-label">Edit document</label>

它不一定必须是 LABEL 元素,您可以使用 SPAN 或其他元素,但 LABEL 在语义上似乎是合适的。

ARIA 属性不会在 HTML 4 或 XHTML DTD 下验证。然而,它们将在 HTML 5 下进行验证(本身仍在开发中)。如果在较旧的 DTD 下验证对您很重要,则可以在页面加载后使用 JavaScript 以编程方式添加属性。

理想情况下,如果您已经有一个可见的小部件标签,那么您应该使用 aria-labelledby 来防止冗余。但是,我不知道它是否可以跨文档边界工作。也就是说,如果 BODY 位于 IFRAME 中,并且可见标签是在 IFRAME 的父文档中定义的,我不知道它是否有效。浏览器/屏幕阅读器可能会将这两个文档视为彼此不交互的单独文档。你必须尝试才能找到答案。但如果结果证明它们不起作用,请尝试< a href="http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden" rel="noreferrer">http://www.w3.org/TR/wai-aria/states_and_properties#咏叹调隐藏。因此,在父文档中:

<label aria-hidden="true">Edit document</label>

在 TinyMCE 文档中:

<body aria-label="Edit document">

aria-hidden 属性将阻止读取父文档中的标签,子文档中的 aria-label 属性(不可见)将取代它。瞧,这是一个带有可见和可听标签的小部件,没有多余的阅读。

如果您以这种方式使用 aria-hidden,请务必小心,确保您隐藏的部分(或等效内容)始终可供其他地方阅读。

此解决方案仅适用于使用支持 ARIA 的 Web 浏览器和屏幕阅读器的用户。使用较旧屏幕阅读器或浏览器的人可能会运气不佳,最近关于 A List Apart 的文章 WAI ARIA 的可访问性。作者为尽可能选择传统语义 HTML 解决方案提供了一个很好的案例;但就你而言,我认为你没有其他选择。至少,添加 ARIA 属性可以让您合理地声称您已经完成了尽职调查,并真诚地努力使其尽可能易于访问。

祝你好运!

未来的读者请注意:此处给出的 ARIA 规范链接指的是 2010 年 9 月的工作草案。如果距离此后已经过去了几个月,请检查更新的规格。

There is an emerging standard for exactly this kind of problem: ARIA (Accessible Rich Internet Applications). It's still a working draft, but support is beginning to show up in recent screen readers (JAWS 9, recent versions of NVDA) when used with recent browsers (IE 9, Firefox 3.6 (partial) and 4.0, Chrome).

In this particular case, take a look at aria-label and aria-labelledby. These are attributes which would be added to the BODY element in TinyMCE's widget -- or to the IFRAME, whichever of the two actually takes focus when the user is entering data. Thus:

<body aria-label="Edit document">

The aria-label attribute just specifies a string that serves as the label. The aria-labelledby (note the two L's, as per British spelling) works like the traditional LABEL element in reverse. That is, you feed it an ID:

<body aria-labelledby="edit-label">

And then you would have this someplace else in the code:

<label id="edit-label">Edit document</label>

It doesn't necessarily have to be a LABEL element, you could use a SPAN or whatever, but LABEL seems semantically appropriate.

ARIA attributes will not validate under HTML 4, or XHTML DTD's. However, they WILL validate under HTML 5 (itself still in development). If validation is important to you under an older DTD, you can add the attributes programmatically using JavaScript when the page has loaded.

Ideally, if you have a visible label for the widget already, then you should be using aria-labelledby to prevent redundancy. However, I have no idea if it'll work across document boundaries. That is, if the BODY is in an IFRAME, and the visible label is defined in the IFRAME's parent document, I don't know if it'll work. The browser/screen reader may treat the two as separate documents which don't talk to one another. You'll have to experiment to find out. But if it turns out they don't work, try http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden. Thus, in the parent document:

<label aria-hidden="true">Edit document</label>

And in the TinyMCE document:

<body aria-label="Edit document">

The aria-hidden attribute will prevent the label in the parent document from being read, and the aria-label attribute in the child document (which is not visible) will take its place. Voila, a widget labeled both visibly and audibly with no redundant reading.

If you use aria-hidden this way, be very careful that the bit you're hiding (or an equivalent) is always made available for reading someplace else.

This solution will only work for people using web browsers and screen readers that support ARIA. People with older screen readers or browsers will be out of luck, which is discussed at length in the recent article on A List Apart, The Accessibility of WAI ARIA. The author makes a good case for preferring traditional semantic HTML solutions whenever possible; but in your case I don't think you have any other option. At the very least, adding ARIA attributes will let you reasonably claim that you've done your due diligence and made a good faith effort to make it as accessible as possible.

Good luck!

Note to far future readers: The links to the ARIA specification given here refer to the September 2010 working draft. If it's been more than a few months since then, check for more recent specs.

万水千山粽是情ミ 2024-10-10 20:17:29

使用 Will Martin 提供的有关 aria-label 属性的信息,我编写了以下适用于 TinyCME 4 的代码行:

tinymce.init({
    …
    init_instance_callback: function(editor) {
        jQuery(editor.getBody()).attr('aria-label', jQuery('label[for="' + editor.id + '"]').text())
    }
});

它使用编辑器初始化后触发的回调函数。

必须有一个针对调用 TinyMCE 的原始元素的 label,在我的例子中是 textarea。例如:

<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>

标签的内容(仅限文本)作为 aria-label 属性添加到 TinyMCE-iframe 内的 body 标签中。

选择 TinyMCE 时,OSX 屏幕阅读器会正确返回标签

一些灵感来自 TinyMCE:初始化后如何绑定事件

Using the information Will Martin provided regarding the aria-label attribut, I wrote the following line of code which works for TinyCME 4:

tinymce.init({
    …
    init_instance_callback: function(editor) {
        jQuery(editor.getBody()).attr('aria-label', jQuery('label[for="' + editor.id + '"]').text())
    }
});

It uses the callback function triggered after initialisation of the editor.

There has to be a label targeted at the original element on which TinyMCE is call upon, in my case a textarea. e.g.:

<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>

The content of the label (text only) is added as aria-label attribute to the body tag inside the TinyMCE-iframe.

OSX screenreader is propperly returing the label when selecting the TinyMCE

Some inspiration from TinyMCE: How bind on event after its initialized

鱼窥荷 2024-10-10 20:17:29

如果我正确阅读了 规范,则 正如您已经说过的,for 属性确实必须指向同一页面上的另一个控件

因此,我认为唯一有效的选择是将 for 属性指向 TinyMCE 替换的

If I read the specs right, the for property must indeed point to another control on the same page, as you already say.

Therefore, I think the only valid option is to point the for attribute to the <textarea> element that TinyMCE replaces. It makes the most sense, seeing as that element gets sent to the server when editing is finished.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文