让屏幕阅读器说出按钮 alt-attribute 而不是 innerText [英] Make screenreader say button alt-attribute instead of innerText

问题描述

是否可以强制屏幕阅读器读取 alt 属性而不是按钮内的文本?

示例html:<button alt="user menu">DrKawashima</button>

在 MacOS 中使用内置的无障碍屏幕阅读器进行测试时，我发现它只显示DrKawashima"，并且从未使用过 alt 属性.

有没有办法提示屏幕阅读器我宁愿让它说用户菜单"?

解决方案

是的，这是可能的 - 但要注意完全覆盖按钮的可见文本.

tl;dr - 我在这里推荐方法 4.

您的问题针对屏幕阅读器，但还有其他类型的辅助技术需要考虑.特别是使用语音控制的视力正常的人(例如 Dragon Naturally speak).注意处理 WCAG 成功标准 2.5.3:名称中的标签.

辅助技术处理元素的计算的可访问名称:>

• 屏幕阅读器将读取计算出的可访问名称.请记住，屏幕阅读器的基本目的是阅读屏幕上的内容 - 小心尝试向屏幕阅读器用户呈现不同的界面.
  • 当盲人屏幕阅读器用户和视力正常的人都在谈论同一个屏幕时，可能会出现混淆.例如，电话技术支持人员可能会说单击显示 DrKawashima 的按钮".但是，如果这被覆盖，屏幕阅读器会显示该按钮称为用户菜单"，并且用户无法找到他们被告知要按下的按钮.
  • 视力正常的人也会使用屏幕阅读器.例如，有阅读障碍的人可能喜欢朗读一些东西以使生活更轻松.当计算出的可访问名称与可见文本不同时，屏幕阅读器实际上是在向用户谎报屏幕上显示的内容.
• 语音控制将尝试将用户所说的内容与计算出的可访问名称相匹配.如果按钮具有可见文本，则该文本出现在元素的计算出的可访问名称内很重要.期望是语音控制用户可以通过说出可见文本来激活按钮.在你的例子中，说点击 DrKawashima"应该激活按钮.如果计算出的可访问名称是用户菜单"，这将不起作用.
  • 对此有一个解决方法.Dragon Naturally speak 有一个工具可以使用数字突出显示所有按钮:说单击按钮"，查找数字，然后说选择 2".然而，这是一个多步骤的过程，需要用户付出额外的努力.

请注意，计算出的可访问名称和可见文本不必完全匹配.相反，可见文本必须构成可访问名称的部分.

让我们看一些例子:

1. 您在按钮上带有 alt 属性的示例根本不起作用，因为按钮没有 alt 属性.这不是有效的 HTML:<button alt="user menu">DrKawashima</button>.

   • 可见文字是DrKawashima"
   • 计算出的可访问名称是DrKawashima".alt 属性无效.
   • 这通过了WCAG名称中的标签"，因为可见文本和计算出的可访问名称完全相同.
   • 但是，它无法通知屏幕阅读器用户按钮的用途；视力正常的用户可能可以从随附的图标或头像图片中推断出这一点.

2. aria-label 属性可用于完全覆盖按钮内容:<button aria-label="user menu">DrKawashima</button>.

   • 可见文字是DrKawashima".
   • 计算出的可访问名称是用户菜单".aria-label 属性完全覆盖按钮内容.
   • 这种方法使 WCAG名称中的标签"失败，因为可见文本不构成可访问名称的一部分.语音控制用户无法通过说点击 DrKawashima"来激活按钮.

3. aria-label 属性可用于完全覆盖按钮内容，同时复制可见文本:<button aria-label="DrKawashima, User菜单">川岛博士</button>.

   • 可见文字是DrKawashima".
   • 计算出的可访问名称是DrKawashima，用户菜单".aria-label 属性完全覆盖按钮内容，但它复制了可见文本.
   • 这通过了 WCAG名称中的标签".可以激活按钮说单击 DrKawashima"，因为可见文本在计算的可访问名称内.
   • 这种方法很简单，但可能很脆弱，因为您必须管理两个字符串.

4. 包含一些视觉上隐藏的文本，为屏幕阅读器用户提供一些额外的上下文.例如，使用 HTML5Boilerplate 的 .visuallyhidden 类，或 Bootstrap 的 .sr-only 类:<button>DrKawashima<span class="visuallyhidden">，用户菜单</span></button>

   • 可见文字是DrKawashima"
   • 计算出的可访问名称是DrKawashima，用户菜单".这是按钮内容的结果.
   • 这通过了 WCAG名称中的标签".可以激活按钮说单击 DrKawashima"，因为可见文本在计算的可访问名称内.
   • 这是最简单的解决方案，非常强大.

5. aria-labelledby 属性可以通过引用 2 个元素 ID 来构建可访问的名称:<button aria-labelledby="user-menu-visible-label user-menu-suffix"><span id="user-menu-visible-label">DrKawashima</span><spanid="user-menu-suffix" class="visuallyhidden">, 用户菜单</span></button>

   • 可见文字是DrKawashima"
   • 计算出的可访问名称是DrKawashima，用户菜单".这是连接 aria-labelledby 引用的两个元素的结果.
   • 这通过了 WCAG名称中的标签".可以激活按钮说单击 DrKawashima"，因为可见文本在计算的可访问名称内.
   • 这是健壮的，但要实现更多的工作，因为您需要管理 ID 引用.

Is it possible to force a screen-reader to read the alt-attribute instead of the text inside a button?

Example html: <button alt="user menu">DrKawashima</button>

When testing this with the built-in accessibility screen-reader in MacOS, I found that it only said "DrKawashima", and the alt-attribute was never used.

Is there a way to hint to screen-readers that I would rather have it say "user menu"?

解决方案

Yes, it's possible - but beware of completely overriding the visible text of a button.

tl;dr - I recommend approach 4 here.

Your question addresses screen readers, but there are other types of assistive technology to consider. In particular, sighted people using speech control (e.g. Dragon Naturally Speaking). Take care to address WCAG Success Criterion 2.5.3: Label in Name.

Assistive technology deals with the computed accessible name of an element:

• Screen readers will read the computed accessible name. Remember that the basic purpose of of a screen reader is to read what's on the screen - beware of trying to present a different interface to screen reader users.
  • Confusion can arise when a blind screen reader user and a sighted person are both talking about the same screen. For example, a telephone tech support person might say "Click on the button which says DrKawashima". But if this is overridden, the screen reader says the button is called "User menu", and the user can't find the button they're being told to press.
  • Sighted people also use screen readers. For example, someone with dyslexia may like to have stuff read out to make life easier. When the computed accessible name differs from the visible text, the screen reader is effectively lying to the user about what it says on the screen.
• Speech control will try to match what a user says, to the computed accessible name. If a button has visible text, it's important that this text appears inside the computed accessible name of the element. The expectation is that a speech control user can activate a button by saying the visible text. In your example, saying "Click DrKawashima" should activate the button. This won't work if the computed accessible name is "User menu".
  • There's a work-around for this. Dragon Naturally Speaking has a tool to highlight all buttons using numbers: say "Click button", look for the number, then say "Choose 2". However this is a multi-step process, requiring extra effort from the user.

Note that the computed accessible name and the visible text do not have to match exactly. Rather, the visible text must form part of the accessible name.

Let's look at some examples:

1. Your example with an alt attribute on the button simply won't work, because buttons don't have an alt attribute. This isn't valid HTML: <button alt="user menu">DrKawashima</button>.

   • The visible text is "DrKawashima"
   • The computed accessible name is "DrKawashima". The alt attribute had no effect.
   • This passes WCAG "Label in name", because the visible text and the computed accessible name are exactly the same.
   • However it doesn't manage to inform a screen reader user about the purpose of the button; sighted users can probably infer this from an accompanying icon or avatar image.

2. The aria-label attribute can be used to completely over-ride the button content: <button aria-label="user menu">DrKawashima</button>.

   • The visible text is "DrKawashima".
   • The computed accessible name is "User menu". The aria-label attribute completely overrides the button content.
   • This approach FAILS WCAG "Label in name", because the visible text doesn't form part of the accessible name. A speech control user can't activate the button by saying "Click DrKawashima".

3. The aria-label attribute can be used to completely over-ride the button content, whilst duplicating the visible text: <button aria-label="DrKawashima, User menu">DrKawashima</button>.

   • The visible text is "DrKawashima".
   • The computed accessible name is "DrKawashima, User menu". The aria-label attribute completely overrides the button content, but it duplicates the visible text.
   • This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
   • This approach is simple, but may be fragile because you have to manage two strings.

4. Include some visually-hidden text, to give screen reader users some additional context. For example, using HTML5Boilerplate's .visuallyhidden class, or Bootstrap's .sr-only class: <button>DrKawashima<span class="visuallyhidden">, User menu</span></button>

   • The visible text is "DrKawashima"
   • The computed accessible name is "DrKawashima, User menu". This results from the button content.
   • This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
   • This is the simplest solution, very robust.

5. The aria-labelledby attribute can build an accessible name, by referencing 2 element IDs: <button aria-labelledby="user-menu-visible-label user-menu-suffix"><span id="user-menu-visible-label">DrKawashima</span><span id="user-menu-suffix" class="visuallyhidden">, User menu</span></button>

   • The visible text is "DrKawashima"
   • The computed accessible name is "DrKawashima, User menu". This results from concatenating the two elements refernced by aria-labelledby.
   • This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
   • This is robust, but a bit more work to implement because you need to manage the ID references.

这篇关于让屏幕阅读器说出按钮 alt-attribute 而不是 innerText的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！