UIAccessibilityLayoutChangedNotification 和 UIAccessibilityScreenChangedNotification 之间的实际区别? [英] Actual difference between UIAccessibilityLayoutChangedNotification and UIAccessibilityScreenChangedNotification?

问题描述

我试图确定在发布 UIAccessibilityLayoutChangedNotification 和 UIAccessibilityScreenChangedNotification 时到底发生了什么不同.据我所知，我可以在任何地方互换使用它们，没有什么不同.

I’m trying to ascertain what exactly happens differently when posting a UIAccessibilityLayoutChangedNotification, and a UIAccessibilityScreenChangedNotification. From what I can see, I can use them interchangeably everywhere and nothing different happens.

Apple 文档只是说在(例如)一个元素被隐藏或显示时使用 LayoutChanged，如果整个屏幕发生变化，则使用 ScreenChanged，但我我对他们在我提供这些信息时做了什么感兴趣，以及在使用其中一个或另一个时我应该看到什么不同.

The Apple documentation simply says to use LayoutChanged when (for example) an element has been hidden or shown, and to use ScreenChanged if the entire screen changes, but I’m interested in what THEY do when I provide this information, and what I should see differently when using one or the other.

谁能清楚地解释两者之间的实现差异?

Can anyone give a clear explanation of implementation differences between the two?

推荐答案

这两个通知用于视图上的动态内容，并将这些更改传达给 VoiceOver 以供屏幕阅读器用户使用.这两个通知之间几乎没有区别，除了它们的默认行为，以及 ScreenChange 通知的愚蠢的小boop beep".

These two notifications are for dynamic content on views, and communicating these changes to VoiceOver for screenreader users. There is little difference between these two notifications, except for their default behavior, and the silly little "boop beep" for ScreenChange notifications.

在这两种情况下，参数

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, arg);

代表一个要读出的字符串，或一个屏幕元素，VoiceOver 将把它的焦点转移到这个元素上.在发生戏剧性的上下文变化时，重要的是将焦点转移到有意义的地方，或宣布发生了此类变化.从可访问性的角度来看，这两种方法都是可以接受的，但我更喜欢涉及尽可能少的更改的方法.在简单的布局更改的情况下，几乎总是最好只宣布上下文更改，并将焦点留在原处.虽然有时，导致上下文更改的元素被隐藏，然后显然有必要直接画外音以突出显示新内容，因为这种情况下的默认行为是未定义的，或者可能是确定性的，但由一个完全不知道的框架决定关于您的应用！

Represents a string to be read out, or an on screen element, which VoiceOver will shift its focus to. In the event of dramatic context changes, it is important to send focus to a place that makes sense, or announce that such changes have taken place. Either approach is acceptable from an accessibility point of view, though I prefer approaches that involve the least amount of change possible. In the event of simple layout changes, it is almost always best just to announce the context change, and leave focus where it was. Though sometimes, the element that caused the context change is hidden, and then it is clearly necessary to direct voiceover to highlight new content, because the default behavior in this case is undefined, or perhaps deterministic, but determined by a framework that knows absolutely nothing about your app!

这两个事件之间的区别在于它们的默认行为，因为它们都做完全相同的事情.如果您向 UIAccessibilityLayoutChangedNotification 提供 nil，就好像您什么也没做.如果您向 UIAccessibilityScreenChangedNotification 提供 nil 参数，一旦所有视图层次结构更改和绘图完成，它就会将焦点发送到视图层次结构中标记为可访问性元素的第一个 UIObject.

The difference between the two events, given that they both do exactly the same thing, is in their default behavior. If you supply nil to the UIAccessibilityLayoutChangedNotification it is as if you have done nothing. If you supply a nil argument to the UIAccessibilityScreenChangedNotification it will send focus to the first UIObject in your view hierarchy that is marked as an accessibilityElement, once all view hierarchy changes and drawings are complete.

UIAccessibilityLayoutChangedNotification

UIAccessibilityLayoutChangedNotification 的一个很好的用例示例是动态表单.您想让用户知道，根据他们在表单中做出的决定，可以使用新选项.例如，如果在表单中选择您是退伍军人，则表单的其他区域可能会弹出以提供更多输入，但这些区域可能已对其他不关心它们的用户隐藏.因此，您可以在用户交互后将重点转移到这些元素上:

A good use case example for UIAccessibilityLayoutChangedNotification is for dynamic forms. You want to let users know that, based on decisions they've made in the form, new options are available. For example, if in a form you select that you are a Veteran, additional areas of the form may pop up to provide more input, but these areas may have been hidden to other users who did not care about them. So you could shift focus to these elements after user interaction:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstNewFormElement);

这会将焦点转移到所提供的元素上，并宣布它是可访问性标签.

Which would shift focus to the provided element, and announce it's accessibilityLabel.

或者只是告诉他们新的表单元素已经存在:

Or just tell them that the new form elements are there:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, @"Veterans form elements available");

这会将焦点留在原处，但 VoiceOver 会宣布退伍军人表单元素可用".

Which would leave focus where it is, but VoiceOver would announce "Veterans form elements available".

注意:我的 iPad (8.1.2) 上存在这种特殊行为.

Note: This particular behavior is bugged on my iPad (8.1.2).

或者最后你可以这样做:

Or finally you could do this:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);

这绝对没有任何作用:).说真的，我什至不认为 a11y 框架后端在乎.这行代码完全是浪费！

Which does absolutely nothing :). Seriously, I don't even think the a11y framework backend cares. This particular line of code is a complete waste!

UIAccessibilityScreenChangedNotification

UIAccessibilityScreenChangedNotification 的一个很好的用例示例是自定义选项卡式浏览情况.当整个屏幕(导航区域除外)发生变化时.您想让画外音知道基本上整个屏幕都发生了变化，但不是聚焦第一个元素(您的第一个选项卡)而是聚焦第一个内容元素.

A good use case example for the UIAccessibilityScreenChangedNotification is customized tabbed browsing situations. When the entire screen, with the exception of your navigation area, changes. You want to let voiceover know that essentially the entire screen changed, but NOT to focus the first element (your first tab) but to focus the first content element.

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstNonGlobalNavElement);

它会播放boop beep"的声音，然后将焦点转移到全局导航栏的正下方.或者你可以这样做:

Which would play the "boop beep" sound and then shift focus to just beneath your global navigation bar. Or you could do this:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, @"You're on a new tab");

这将等待新标签加载，播放哔哔"声，在画外音中宣布你在新标签上"，然后将焦点转移到屏幕上的第一个元素，然后宣布无障碍标签那个元素.(PHEW！太多了！这对屏幕阅读器用户来说很刺耳.避免这种情况，除非绝对必要).

Which would wait for the new tab to load, play the "beep boop" sound, announce "You're on a new tab" in voiceover, then shift focus to the first element on the screen, then announce the accessibilityLabel for that element. (PHEW! That's a lot! This is jarring for screen reader users. Avoid this scenario, unless absolutely necessary).

最后你当然可以这样做:

And finally you can of course do this:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);    

相当于:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstA11yElement);

两者都会播放哔哔"的声音，将 VoiceOver 焦点移到屏幕上的第一个元素，然后宣布它.

Both of which will play the "beep boop" sound, shift VoiceOver focus to the first element on the screen, and then announce it.

终于

在评论中有人提到了缓存，我偶尔会在我的回答中评论 A11y 后端可能关心或不关心的事情.虽然肯定有可能发生一些后端魔术，但我不相信这两种情况中的任何一种，后端根本不在乎.我之所以这么说是因为:

In a comment somebody mentioned caching, and I occasionally comment in my answer about things the A11y Backend may or may not care about. While it is certainly possible that there is some backend magic happening, I don't believe in either of these circumstances, the back end cares at all. The reason I say this is because:

如果你曾经使用过 UIAccessibilityContainer 协议，你可以观察你的视图容器被查询.没有缓存正在进行.每次 VoiceOver 将焦点更改为容器内的新 AccessibilityElement 时，甚至 accessibilityElementCount 属性也会被 ping.然后它经历检查它在哪个元素上的过程，请求下一个元素，等等.它的核心设计是为了处理动态情况.如果您在交互后将一个新元素插入到您的容器中，它仍然会通过所有这些查询并且很好！此外，如果你覆盖了 UIAccessibility 协议的属性，为了提供动态提示和标签，你还可以看到这些函数每次都会被调用！因此，我相信 A11y 框架后端从这些通知中收集到的信息绝对为零.VoiceOver 需要完成它的工作的唯一信息是它当前的焦点辅助功能元素，而这个元素是辅助功能容器.通知只是为了让 VoiceOver 用户更容易使用您的应用.

If you've ever used the UIAccessibilityContainer protocol, you can watch as your container of views gets queried. There is no caching going on. Even the accessibilityElementCount property gets pinged each time VoiceOver changes focus to a new AccessibilityElement within your container. Then it goes through the process of checking which element it is on, asking for the next element, and so on. It is designed at its core to handle dynamic situations. If you were to insert a new element into your container after interaction, it would still go through all of these queries and be just fine about it! Furthermore, if you override the properties of the UIAccessibility protocol, in order to provide dynamic hints and labels, you can also see that these functions get called every time! As such, I believe that the A11y Framework backend gleans ABSOLUTELY ZERO information from these notifications. The only information VoiceOver needs to do its job is it's currently focused Accessibility Element, and this elements Accessibility Container. The notifications are simply there for you to make your app more usable for VoiceOver users.

想象一下，如果不是这样，Safari 会发布多少次这些通知！！！！:)

Imagine if this weren't the case how many times Safari would post these notifications!!!! :)

这些特定的陈述只能由具有框架后端知识、使用代码的人证实，并且应该被视为猜想.这可能是高度依赖于版本/实现的情况.绝对可以讨论这些要点！这篇文章的其余部分非常具体.

These particular statements can only be confirmed by someone with backend knowledge of the framework, who works with the code, and should be viewed as conjecture. It could be the case that this is highly version/implementation dependent. Definitely open to discussion on these points! The rest of this post is pretty concrete.

供您参考

其中大部分来自使用框架的经验，但如果您想进一步挖掘，这里是一个有用的参考.

Most of this comes from experience working with the frameworks, but here is a useful reference if you wish to dig further.

https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility

https://developer.apple.com/documentation/uikit/uiaccessibilitylayoutchangednotification

https://developer.apple.com/documentation/uikit/uiaccessibilityscreenchangednotification

最后，我放在一起测试所有这些东西的愚蠢的小应用程序的开源存储库.

And finally, an open source repo of the silly little app I put together to test all this stuff.

https://github.com/chriscm2006/IOS-A11y-Api-Test

这篇关于UIAccessibilityLayoutChangedNotification 和 UIAccessibilityScreenChangedNotification 之间的实际区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！