英文:
Scrolling to error with accessibility on Android
问题
我有一个带有可访问性的表单。当用户点击表单底部的按钮并且存在无效的EditText字段(例如,它为空)时,我希望错误被宣布,并且视图滚动到该EditText字段。我尝试了几种方法,但遇到一个问题,即当我滚动到表单的那一部分时,Talkback会随着滚动拖动焦点并宣布最后的视图。
这是我尝试过的内容:
XML:
android:importantForAccessibility="yes"
android:accessibilityLiveRegion="assertive"
以编程方式:
field.requestFocus()
field.sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED)
//scrollView.smoothScrollTo(0, field.bottom) - 以前尝试过的
我还尝试了从其他视图清除焦点(这没有起作用),在滚动之前禁用Talkback并在滚动后启用它(我无法实现),以及滚动到字段在屏幕底部以便Talkback会宣布它(如果字段在屏幕顶部,您无法滚动到那里)。在您的应用中如何实现这一功能?
英文:
I have a form with accessibility. When the user clicks on the button at the bottom of the form and there is an invalid EditText field (e.g. it is empty), I would like the error to be announced and for the view to scroll to that EditText field. I have attempted several methods, but I encounter the issue that when I scroll to that part of the form, Talkback drags the focus with the scrolling and announces the last view.
Here is what I have tried:
XML:
android:importantForAccessibility="yes"
android:accessibilityLiveRegion="assertive"
Programmatically:
field.requestFocus()
field.sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED)
//scrollView.smoothScrollTo(0, field.bottom) - older try
I have also tried to clear the focus from other views (which didn't work), disable Talkback before scrolling and enable it after (which I couldn't), and scroll to the point that the field is at the bottom of the screen so that Talkback will announce it (if the field is at the top of the screen, you can't scroll there). How does it work in your apps?
答案1
得分: 1
这是一个带有许多含义的简单答案 - 我将它们分开,这样您可以决定要深入了解多少。
答案
- 永远不要在任何情况下关闭任何人的辅助技术。 永远不要。
- 不要更改用户的焦点(WCAG 3.2.1“On Input”)
- 使用越多“标准”错误通知,您和用户都会更容易
- 使用
EditText
自带的错误通知
// 会被屏幕阅读器自动宣读,附带内置图像 view.error = "描述性错误"
- 如果必须使用
LiveRegion
:
<!-- 每当文本属性更改时,TalkBack 将宣读它 --> <!-- 您需要添加自己的样式,并记住一次只能提供一个反馈元素 --> <TextView android:id="@+id/error" android:accessibilityLiveRegion="assertive" android:layout_width="match_parent" android:layout_height="wrap_content"/>
- 使用
解释
-
Android 上有许多种辅助技术,不仅仅是 TalkBack。用户可能会运行自定义服务,如果我们作为开发人员开始干预,就会干扰这些用户。此外,他们使用的辅助技术正是使他们独立的关键。不要剥夺人们这个,哪怕只有一秒钟。
-
代表用户更改焦点会导致混淆和沮丧。Web 内容可访问性指南明确规定您不应该这样做:
更改任何用户界面组件的设置不会自动导致上下文的更改,除非在使用组件之前已经告知用户该行为。
上下文的更改被定义为:
上下文的更改包括以下内容:
- 用户代理;
- 视口;
- 焦点;
- 更改 Web 页面含义的内容
也许有时我们必须调整焦点,因为系统一直表现出奇怪的行为(通常是因为我们以奇怪的方式加载组件 - 例如,从某个网络调用动态加载 - 但即使在这种情况下,也应慎重考虑)。
-
Google 已经为开发人员提供了标准化的 API(错误字段和
LiveRegions
)来确保这一点变得容易 - 通知用户,但让用户导航到需要修复错误的位置。请记住,除了屏幕阅读器之外还有许多其他辅助技术,如放大、Switch Access、Voice Access 等。
最后的话语
-
使用 TalkBack 测试您的应用程序 - 当您首次打开它时,会有教程。我还制作了一个备忘单来帮助您,我还有另一种工具,用于检查 Android 中的不同可访问性元素。
-
少即是多,只要您记住:一致性(标准 API)、可配置性(为用户提供多种方式)和同意(给用户选择权)。
-
与真实用户测试您的应用程序。有一家名为Fable的公司专门为有不同残疾的用户进行应用程序的可访问性测试。这是您可以得到的最好的反馈。
-
只需检查您的样式在暗模式和亮模式下的情况。
英文:
This is a simple answer with many implications - I'm separating the two so you can decide how much depth you'd like to go into.
Answer
- Do not ever under any circumstances turn off anyone's assistive tech for them. Ever.
- Don't change a users focus (WCAG 3.2.1 "On Input")
- The more "standard" error notifiers you use, the easier it will be for you and the user
- Use the built in ones that come with
EditText
// automatically gets announced by screen reader and has a built in image view.error = "Descriptive error"
- If you must use a
LiveRegion
:
<!-- every time the text property is changed it will be announced by TalkBack --> <!-- You will need to add your own styling and remember you can only give one --> <!-- element of feedback at a time --> <TextView android:id="@+id/error" android:accessibilityLiveRegion="assertive" android:layout_width="match_parent" android:layout_height="wrap_content"/>
- Use the built in ones that come with
Explanation
- There are many types of assistive technologies on Android, not just TalkBack. Users may have custom services running and if we as developers start messing with them, we interfere with those users. Additionally, the assitive tech they are using is the very thing giving them independence. Don't take that away from people, even for a second.
- Changing focus on behalf of users causes confusion and frustration. The Web Content Accessibility Guidelines specifically state you should not so this:
> Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
A change of context being defined as such:
> Changes in context include changes of:
> 1. user agent;
> 2. viewport;
> 3. focus;
> 4. content that changes the meaning of the Web page
There may be times where we have to adjust focus because the system is consistently behaving strangely (normally because we're loading components in a strange way - e.g. dynamically from some web call - but even here careful consideration should be taken)
- Google has done a lot of work to make sure this is easy for developers by providing standardized API's (Error fields and
LiveRegions
) - inform the user, but let the user navigate to where they need to fix any errors. Remember that there are many assistive technologies other than Screen Readers - Magnification, Switch Access, Voice Access, etc.
Final words
-
Test your app with TalkBack - when you turn it on for the first time there is a tutorial. I have also made a cheat sheet to help you and I have another tool for checking different accessibility elements with Android.
-
Less is more, as long as you remember: Consistency (standard API's), Configurability (Giving users multiple means) and Consent (give the user the choice)
-
Test your app with real users. There is a great company called Fable that do accessibility testing of apps with users who have different disabilities. This is the best feedback you can get.
-
Just check your styles in dark and light mode.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论