如何使屏幕阅读器不能将元素识别为元素组? [英] How to make screenreader not recognise an element as an element group?

查看:179
本文介绍了如何使屏幕阅读器不能将元素识别为元素组?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在尝试使DOM元素与一到几个子元素尽可能地可访问。该元素将使用多层背景图像包含说明性内容。我目前正在使用子元素来提供图像描述,如



是否可以以某种方式更新此元素的标记,从而使 group 公告不是屏幕阅读器发出的?在几乎所有情况下,用户都无法在元素内部进行进一步的探索或使用,因此此消息将是多余的,我希望VoiceOver不能将元素识别为触发此消息的组。

解决方案

(由于评论中的讨论已解决了问题,因此将我的所有评论从评论部分移至答案部分)。



我认为对于屏幕阅读器(SR)的工作方式以及SR用户如何浏览网页可能会有一些误解。



您的< div>上有 tabindex = 0 ,但< div>没有角色,它不是交互式元素。 tabindex规范的警告内容为:


只有当元素充当交互控件时,作者才应使其具有焦点。


因此,除非用户可以与< div>进行实际交互,否则用户不应具有 tabindex = 0



如果用户可以与< div>进行交互,则< div>还将需要 role (请参见 role 的先前URL),以便SR可以正确地宣布元素和用户



对于非交互式元素,SR用户可以通过多种方式浏览页面,以便他们可以访问页面上的其他文本。



一种更常见的导航方式是使用箭头键行走DOM。 (实际上,实际上,您并不是在遍历DOM,而是可访问性树,它基本上是DOM的子集,例如,隐藏元素(CSS display:none )在DOM中,但不在可访问性中树。)



无论如何,向上/向下箭头键可让SR用户访问显示屏上的每一段文本。您的所有标题,段落,列表等。



还有单字母快捷键,可让SR用户导航到特定类型的元素。例如,




  • H 会将我带到下一个标题

  • T 将带我到下一张桌子

  • L 将带我到下一张列表

  • B 将带我进入下一个按钮



但是这些键仅在您处于使用语义html,例如< h2>,< table>,< ul>,< button>等(如果您使用适当的 ARIA属性。例如,如果由于某种原因您不能使用< h2>进行真实标题,则仍可以使用ARIA告诉SR您有标题。

 < span role = heading aria-level = 2>这是自定义的h2标题< / span> 

JAWS和NVDA是PC上常见的SR。它们将具有类似的单键快捷方式,可在此处查看:




  • JAWS快捷键

  • NVDA快捷键

  • VoiceOver快捷键(对于Mac,不是iOS)。请注意,这些不是单键快捷方式,就像简单的 H 一样,而是需要 VO键(默认情况下为 Ctrl + Option )与 Cmd H 组合使用。



苹果的关于VoiceOver的教程



在PC上,Freedom Scientific(JAWS的制造商)在JAWS上具有很好的教程



如果您对可访问性有疑问,在stackoverflow上发帖肯定是一种方法,特别是如果您使用 accessibility标记问题和其他与可访问性相关的标签(例如 wai-aria 屏幕阅读器您在这个问题上做了)。



另一个资源是 WebAIM co免疫力。任何人都可以加入,您可以潜伏并在讨论进入时阅读它们,或者完全参与其中。


I'm currently trying to make a DOM element with one to several child elements as accessible as possible. The element will contain illustrative content using background images in several layers. I'm currently using a child element for providing the image description as described in this informative blog post about how to label illustrative content inside of a content group. The container element may also contain other child elements containing text content.

An example element would currently look as follows:

<div tabindex="0" class="comic-panel">
  <span role="img" aria-label="There is a cat sitting in the window."></span>
  <div style="background-image: url(/assets/img/window.png);" class="comic-panel__layer"></div>
  <div style="background-image: url(/assets/img/cat.png);" class="comic-panel__layer"></div>
  <p class="speech-bubble">Meow!</p>
</div>

Testing with OSX VoiceOver, after tabbing into this element, the image description and the text is read fine, but subsequently, the following announcement is made as well:

Is it possible to update the markup of this element in a way, that this group announcement is not made by screenreaders? In almost all cases there will be nothing for the user to further explore or use inside of the element so this message would be redundant and I'd like VoiceOver to not recognise the element as a group that triggers this message.

解决方案

(Moving all my comments from the comment section to the answer section since the discussion in the comments resolved the issue.)

I think there might be some misunderstanding of how a screen reader (SR) works and how a SR user navigates a webpage.

You have tabindex="0" on your <div> but the <div> doesn't have a role and is not an interactive element. The tabindex spec has a warning that says:

"authors should only make elements focusable if they act as interactive controls".

So unless the user can actually interact with the <div>, it should not have tabindex="0".

If the user can interact with the <div>, then the <div> will also need a role (see previous URL to role) so that the SR will announce the element properly and the user will understand how to interact with that element.

For non-interactive elements, SR users have lots of ways to navigate around the page so that they can access other text on the page.

One of the more common ways to navigate is by using the up and down arrow keys to walk the DOM. (Actually, you're not walking the DOM, per se, but rather the Accessibility Tree, which is basically a subset of the DOM. For example, hidden elements (CSS display:none) are in the DOM but are not in the Accessibility Tree.)

Anyway, the up/down arrow keys let the SR user get to every piece of text on the display. All your headings, paragraphs, lists, etc.

There are also single letter shortcut keys that allows the SR user to navigate to specific types of elements. For example,

  • H will take me to the next heading
  • T will take me to the next table
  • L will take me to the next list
  • B will take me to the next button

But these keys will only work if you are using semantic html, such as an <h2>, <table>, <ul>, <button>, etc or if you are using the appropriate ARIA attributes. For example, if there's a reason you can't use <h2> to make a real heading, you can still tell the SR that you have a heading by using ARIA.

<span role="heading" aria-level="2">This is a custom h2 heading</span>

JAWS and NVDA are common SRs on the PC. They'll have similar single key shortcuts that can be seen here:

Apple has a good tutorial on VoiceOver.

For the PC, Freedom Scientific (the maker of JAWS) has a good tutorial on JAWS.

If you have questions about accessibility, posting on stackoverflow is certainly one way to go, especially if you tag your question with accessibility and other accessibility related tags (such as wai-aria or screen-readers, as you did on this question).

Another resources is the WebAIM community. Anyone can join and you can "lurk" and just read the discussions as they come in, or fully participate.

这篇关于如何使屏幕阅读器不能将元素识别为元素组?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆