“咏叹调所描述的”是什么意思？财产？

发布于 2024-10-10 02:04:01 字数 185 浏览 3 评论 0原文

以下 HTML 是由 jQuery Grid 插件插入的：

<td role="gridcell" style="" aria-describedby="list_createdBy">Sam</td>

'aria-descriptedby' 属性的含义是什么？

原文

The following HTML is inserted by the jQuery Grid plugin:

<td role="gridcell" style="" aria-describedby="list_createdBy">Sam</td>

What is the meaning of the 'aria-describedby' property?

分享到QQ

分享到微博

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

发布评论

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

仅一夜美梦 2024-10-17 02:04:01

aria 规范对此进行了描述。它给出了元素的 id，该元素提供了一些用户可能需要的有关当前元素的一些附加信息。

回复收藏 0 原文

谁对谁错谁最难过 2024-10-17 02:04:01

下面是如何使用 aria-descriptedby 属性的示例。当您的文本包含有关元素的信息时，将使用它。 Aria-descriptedby 必须与描述它的文本的 id 相同。

名字：您的名字必须正确。

回复收藏 0 原文

另类 2024-10-17 02:04:01

乍一看，我会说 aria-scribedby 在这里可能会被忽略，因为它是在上定义的。当设置在不可交互（可聚焦）的元素上时，大多数浏览器和屏幕阅读器将忽略 aria-scribedby 信息。

但具体示例有点复杂，因为 role="gridcell" 覆盖了的语义，因此如果提供的示例遵循 < a href="https://www.w3.org/TR/wai-aria-1.1/#gridcell" rel="noreferrer">gridcell 的 ARIA 规范。这是一个自定义组件。

一般来说，属性aria-descriptedby为屏幕阅读器提供了要在元素内容中公布的附加信息（不是唯一的，而是最常见的用例）。

例如，屏幕阅读器将宣布“Logout，John Doe”，而不是仅“Logout”：

    Logged-in as <span id="user">John Doe</span>.
    <a aria-describedby="user" href="/logout">Logout</a>

或者带有工具提示的示例（提示：此处缺少Javascript部分）：

    <button type="button" aria-describedby="my-tooltip">Snipping Tool</button>
    <div hidden id="my-tooltip" role="tooltip">
        It can take still screenshots of an open window,
        rectangular areas, a free-form area,
        or the entire screen.
    </div>

或者带有表单元素的示例，另一个常见用例：

    <form ...>
        <label for="my-name">Full name</label>
        <input aria-describedby="my-name-desc" id="my-name" type="text"/>
        <p id="my-name-desc">
            Please tell us your full name.
        </p>
    </form>

上面的示例将在用户聚焦输入字段。它不仅不需要读取周围环境来理解预期输入的内容，而且在

内部读取表单控件以外的所有元素可能会更复杂屏幕阅读器用户。这是一种与阅读页面其余部分不同的体验。因为键盘事件可以与屏幕阅读器或表单控件交互，但很难同时与两者交互。更不用说屏幕阅读器提供了一堆有用的键盘快捷键，例如按“H”将跳转到下一个标题，但显然当字段获得焦点时则不会。然后“H”将被输入到中。

关于 ARIA：

ARIA 通常用于提高辅助功能用于屏幕阅读器（不仅是，而且主要是自动取款机）。
使用 ARIA 并不一定会让事情变得更好！轻松如果没有正确实施和测试，ARIA 可能会导致可访问性明显变差。不要只是为了在代码中添加一些您不完全理解的“很酷的东西”而使用 ARIA。遗憾的是，在可访问性方面，ARIA 实现常常带来的问题多于解决方案。这种情况相当常见，因为有视力的用户和开发人员不太可能在屏幕阅读器的广泛测试中投入额外的精力，而另一方面 ARIA 规范和验证器目前远非完美，在某些情况下甚至令人困惑。除此之外，每个浏览器和屏幕阅读器都不一致地实现 ARIA 支持，从而导致行为上的主要不一致。通常，当不清楚 ARIA 的具体用途、行为方式并且不会使用所有屏幕阅读器和浏览器（或至少最常见的组合）。免责声明：我的目的不是要羞辱 ARIA，而是要羞辱它糟糕的 ARIA 实现。事实上，HTML5 不提供任何其他替代方案的情况并不少见，而实施 ARIA 将为可访问性带来显着的好处，例如 aria-hidden 或 aria-expanded。但前提是正确实施和测试！

关于 aria-scribedby

提供了附加信息元素的内容
在可聚焦元素（例如按钮、输入、a）上按预期工作。对其他元素来说大部分没用（“大部分”也有例外）
IE 11 有点棘手。有时它会被忽略。如果在 a 或 button 上实现，如果引用的元素被隐藏（display:none），它的位置（是引用的内部元素？）或者它是否有 tabindex="-1" 或 role （例如 role="none"）等。确保测试所有屏幕阅读器
如果在焦点模式（TAB 键）或虚拟模式（使用箭头键阅读内容）下使用屏幕阅读器，则行为可能会有所
不同 Firefox 和 Internet Explorer 均尊重 aria-scribedby 仅在对焦模式下。因此，将其添加到不可聚焦的元素中是没有意义的。来自：ADG
虽然 NVDA 立即宣布了描述， JAWS 有时会提示手动按 JAWS+Alt+R 来宣布。来自：ADG
如果引用的元素被隐藏，则不会可使用 Ctrl+F 进行搜索（这是用户浏览网站以快速找到所需内容的常用方式）。来自：ADG
我们真正推荐的唯一案例aria-descriptedby 的用法是将附加信息附加到交互元素（例如，将可见信息与表单控件相关）。来自： ADG
好主意：使用 < 的组合code>aria-scribedby（在表单控件上）和 role="alert"（在 SPAN 上）用于表单控件错误。来自：W3.org

At the first glance I'd say aria-describedby is likely to be ignored here because it's defined on <td>. Most browsers and screen readers will ignore aria-describedby information when set on element which is not interactive (focusable).

But the specific example a bit more complex due to role="gridcell" which overrides the semantics of <td> and therefore the provided example is valid if it follows the ARIA specification for gridcell. It's a custom component.

Generally speaking the attribute aria-describedby provides the screen reader with the additional information to be announced along the content of the element (not the only but the most common use-case).

For example instead of only "Logout" the screen reader will announce "Logout, John Doe":

    Logged-in as <span id="user">John Doe</span>.
    <a aria-describedby="user" href="/logout">Logout</a>

Or example with a tooltip (Hint: Javascript part is missing here):

    <button type="button" aria-describedby="my-tooltip">Snipping Tool</button>
    <div hidden id="my-tooltip" role="tooltip">
        It can take still screenshots of an open window,
        rectangular areas, a free-form area,
        or the entire screen.
    </div>

Or example with a form element, another common use-case:

    <form ...>
        <label for="my-name">Full name</label>
        <input aria-describedby="my-name-desc" id="my-name" type="text"/>
        <p id="my-name-desc">
            Please tell us your full name.
        </p>
    </form>

The example above will announce both <label> and the additional description (defined by aria-describedby) immediately when a user focuses the input field. Not only that it eliminates a need to read the surroundings to be able to understand what is expected to enter but also reading all elements other than form controls when inside of the <form> might be more complex for a screen reader user. It's a different experience then reading the rest of the page. Because keyboard events can either interact with screen readers or with form controls, but hardly with both in the same time. Not to mention that screen readers offer bunch of useful keyboard shortcuts for example pressing "H" will jump to a next heading but obviously not when <input> field is focused. Then "H" will be entered into <input>.

About ARIA:

ARIA is commonly used to improve the accessibility for screen readers (not only but mostly atm.).
Using ARIA does not necessarily make things better! Easily ARIA can lead to significantly worse accessibility if not implemented and tested properly. Don't use ARIA just to have some "cool things in the code" which you don't fully understand. Sadly too often ARIA implementations introduce more issues than solutions in terms of accessibility. This is rather common since sighted users and developers are less likely to put extra effort in extensive testing with screen readers while on the other hand ARIA specs and validators are currently far from perfect and even confusing in some cases. On top of that each browser and screen reader implement the ARIA support non-uniformly causing the major inconsistencies in the behavior. Often it's better idea to avoid ARIA completely when it's not clear exactly what it does, how it behaves and it won't be tested intensively with all screen readers and browsers (or at least the most common combinations). Disclaimer: My intention is not to disgrace ARIA but rather its bad ARIA implementations. In fact it's not so uncommon that HTML5 don't offer any other alternatives where implementing ARIA would bring significant benefits for the accessibility e.g. aria-hidden or aria-expanded. But only if implemented and tested properly!

About aria-describedby

Provides the additional information along the content of the element
Works as expected on focusable elements (e.g. button, input, a). Mostly useless on other elements ("mostly" there are exceptions)
IE 11 is a bit tricky. Sometimes it's ignored. It might make a difference if implemented on a or button as well if referenced element is hidden (display:none), its position (is the inner element referenced?) or if it has tabindex="-1" or role (e.g. role="none") on it etc. Make sure to test all screen readers
Might behave differently if a screen reader is used in a focus mode (TAB key) or virtual mode (reading the content with ARROW keys)
Both Firefox and Internet Explorer respect aria-describedby only in focus mode. As such, it does not make sense to add it to non-focusable elements. From: ADG
While NVDA announces descriptions right away, JAWS sometimes prompts to manually press JAWS+Alt+R to announce it. From: ADG
If referenced element is hidden it's not searchable with Ctrl+F (which is a common way the users like to navigate the website to quickly find what they look for). From: ADG
The only case where we truly recommend the usage of aria-describedby, is to attach additional information to interactive elements (e.g. to relate visible information e.g. to form controls). From: ADG
Good idea: Using combination of aria-describedby (on a form control) and role="alert" (on a SPAN) for a form control error. From: W3.org