索尼vgn ux拆屏幕_针对屏幕阅读器优化您的Android应用UX

索尼vgn ux拆屏幕

In my last post, I discussed some ways to make sure your app’s design handles text with variable length and font sizes. This is a good starting point, however, for the legally blind, no increase in the size of text will help them read that text. Your design should also be accessible via a screen reader, such as TalkBack.

一篇文章中 ,我讨论了确保应用程序设计处理可变长度和字体大小的文本的一些方法。 这是一个很好的起点,但是,对于法律上盲人来说,增加文本大小不会帮助他们阅读该文本。 您的设计还应该可以通过屏幕阅读器(例如“话语提示”)进行访问。

Android屏幕阅读器基础知识 (Android screen reader basics)

For Android, Google provides two screen readers: TalkBack and Select to Speak. In order to see these options in the Accessibility settings, you should have the Android Accessibility Suite installed.

对于Android,Google提供了两种屏幕阅读器:“ 话语提示”和“ 选择讲话” 。 为了在“辅助功能”设置中看到这些选项,您应该安装了Android Accessibility Suite

The primary reader is TalkBack. It provides both accessible navigation and text to speech. When enabled, it completely changes the way the touch screen works. A word of caution: if you enable TalkBack, you will want to go through the provided tutorial to understand how to get around. Without understanding navigation, you will likely get frustrated, as the touch screen will no longer work the way you expect. I have also found Google’s cheat sheets for TalkBack gestures and keyboard shortcuts to be very helpful.

主要读者是TalkBack 。 它提供了可访问的导航和文本到语音。 启用后,它将完全改变触摸屏的工作方式。 请注意 :如果启用“话语提示”,则需要阅读提供的教程以了解如何解决。 如果不了解导航,您可能会感到沮丧,因为触摸屏将无法再按预期的方式工作。 我还发现Google的TalkBack 手势键盘快捷键备忘单非常有用。

On devices with Android 9.0 or later, there is a second screen reader called Select to Speak. This one is handy for preserving touch navigation while enabling quick access to screen reads. I recommend enabling this on the emulator or device you use for development and testing, as it will give you a good idea how your app is audibly rendered for those using TalkBack. It puts a small person icon in the bottom right corner of the screen in the navigation bar. Tap it, and it will pop up some controls that let you enable an entire screen read, or just touch a View whose content you want to hear.

在装有Android 9.0或更高版本的设备上,还有第二个屏幕阅读器,称为“ 选择讲话” 。 这是在保持触摸导航的同时方便快速访问屏幕读数的一种方法。 我建议在用于开发和测试的仿真器或设备上启用此功能,因为它可以使您很好地了解如何为使用TalkBack的用户呈现您的应用。 它将一个小人物图标放在导航栏的屏幕右下角。 点按它,它将弹出一些控件,使您可以读取整个屏幕,或仅触摸要听其内容的视图。

Select to speak controls at the bottom of the screen
Select to speak controls at the bottom of the screen
选择说出屏幕底部的控件

图像“说”什么? (What do images “say”?)

One of the more important considerations is what to do when a screen reader encounters an image. Typically you use an ImageView in Android to display the image. This works fine for people with normal vision, but for the impaired, this image is possibly going to be useless. Android Studio will even warn you about this situation. If you’re an Android engineer, you’ve probably already seen this because of the way Android Studio warns you about missing contentDescription attributes in XML:

更重要的考虑因素之一是屏幕阅读器遇到图像时该怎么做。 通常,您在Android中使用ImageView来显示图像。 这对于具有正常视力的人来说效果很好,但对于有障碍的人,此图像可能会无用。 Android Studio甚至会警告您这种情况。 如果您是一名Android工程师,那么您可能已经因为Android Studio警告您有关XML中缺少contentDescription属性的方式而看到了这一点:

Image for post

The full text of the lint warning here is:

棉绒警告的全文如下:

Missing contentDescription property on image

图片缺少contentDescription属性

Non-textual widgets like ImageViews and ImageButtons should use the contentDescription attribute to specify a textual description of the widget such that screen readers and other accessibility tools can adequately describe the user interface.

非文本小部件(如ImageViews和ImageButtons)应使用contentDescription属性指定小部件的文本描述,以便屏幕阅读器和其他辅助功能工具可以充分描述用户界面。

Note that elements in application screens that are purely decorative and do not provide any content or enable a user action should not have accessibility content descriptions. In this case, just suppress the lint warning with a tools:ignore=”ContentDescription” attribute.

请注意,应用程序屏幕中的纯装饰性元素,不提供任何内容或不支持用户操作,不应包含可访问性内容描述。 在这种情况下,只需使用tools:ignore =” ContentDescription”属性抑制掉毛警告。

Note that for text fields, you should not set both the hint and the contentDescription attributes since the hint will never be shown. Just set the hint. See http://developer.android.com/guide/topics/ui/accessibility/checklist.html#special-cases.

请注意,对于文本字段,不应同时设置提示和contentDescription属性,因为将永远不会显示提示。 只需设置提示。 请参阅http://developer.android.com/guide/topics/ui/accessibility/checklist.html#special-cases。

The right thing to do is assign the ImageView a value for contentDescription that describes the image, which will be read by screen readers when they encounter the view. This is similar to the way the alt attribute works for images in web browsers.

正确的做法是为ImageView分配一个用于描述图像的contentDescription值,当屏幕阅读器遇到该视图时,屏幕阅读器会读取该值。 这类似于alt属性对Web浏览器中的图像起作用的方式。

对于没有上下文意义的装饰性图像 (For decorative images without contextual meaning)

Content descriptions are not desirable everywhere. Purely decorative images that do not have a meaning should have a value of @null to avoid speaking anything when the screen is read. However, the view is still discoverable by touch, and will render some dummy text, which is probably not what you actually want. To get an element completely out of the way of a screen reader, it should also have the importantForAccessibility attribute set:

内容描述并非到处都是可取的。 没有意义的纯装饰性图像应具有 @null 值,以避免在阅读屏幕时说出任何内容。 但是,该视图仍然可以通过触摸发现,并将呈现一些虚拟文本,这可能不是您真正想要的。 为了使元素完全不影响屏幕阅读器,它还应该设置importantForAccessibility ForAccessibility属性:

android:importantForAccessibility="no"

Read more about the effective difference between contentDescription and importantForAccessibility.

了解更多有关之间的有效差异contentDescriptionimportantForAccessibility

Definitely think about what you want the aural experience to be for each image you place on screen, and mark it appropriately. This even includes TextViews!

绝对考虑一下,您希望屏幕上放置的每个图像都具有什么样的听觉体验,并对其进行适当的标记。 这甚至包括TextViews!

TextView:截断或椭圆形的文本怎么办? (TextView: What about truncated or ellipsized text?)

Usually, for TextViews, there’s nothing you have to do to get a screen reader to correctly read the displayed text. By default, a screen reader will speak the entire text that you’ve placed into it using the text XML attribute or setText method. In many cases, this is good enough, but not always sufficient.

通常,对于TextViews,无需执行任何操作即可让屏幕阅读器正确读取显示的文本。 默认情况下,屏幕阅读器会使用text XML属性或setText方法说出放入其中的全部文本。 在许多情况下,这足够好,但并不总是足够的。

In my last post, I showed an example of using android:ellipsize="end" to automatically truncate long text so that it fits within the static vertical space for items in a menu:

在我的上一篇文章中,我展示了一个使用android:ellipsize="end"自动截断长文本的示例,以使其适合菜单项的静态垂直空间:

Image for post

If you’re concerned about what a screen reader will do with the ellipsized text as shown above, the good news is that screen readers will use exactly the text that you’ve set into the view, not just what appears on the screen. So, if the screen reader encounters a TextView, it will simply speak the entire contents of the text provided by the code. The screen reader is using the raw data in the view hierarchy, not the pixels on the screen, though it is using the position of each view on screen in order to determine the order they should be read. (In general, you can expect it to read views on the screen from left to right, top to bottom. If the order of text is important, you should test that before you publish the app, and change the order as needed.)

如果您担心屏幕阅读器将如何处理如上所示的椭圆形文本,那么好消息是屏幕阅读器将完全使用您在视图中设置的文本,而不仅仅是屏幕上显示的内容。 因此,如果屏幕阅读器遇到TextView,它将仅说出代码提供的文本的全部内容。 屏幕阅读器使用视图层次结构中的原始数据,而不是屏幕上的像素 ,尽管它使用屏幕上每个视图的位置来确定应读取的顺序。 (通常,您可以期望它从左到右,从上到下读取屏幕上的视图。如果文本的顺序很重要,则应在发布应用之前进行测试,然后根据需要更改顺序 。)

您真的要说所有隐藏的文字吗? (Do you really want to speak all of the hidden text?)

Consider for a moment that a truncated TextView can hide a lot of extra text. Do you really want the screen reader to read all of it? If the text is very long, it might be too time-consuming for the user of your app to listen through it, given the context of what the screen wants them to accomplish. Visually, there might be no problem with truncated text, but aurally, it could be a UX disaster.

考虑一下,被截断的TextView可以隐藏很多额外的文本。 您是否真的要屏幕阅读器阅读所有内容? 如果文本很长,则鉴于屏幕希望他们完成的内容,您的应用程序用户可能无法花费很长时间来收听文本。 在视觉上,截断的文本可能没有问题,但是从听觉上讲,这可能是UX灾难。

Remember that people using screen readers have a harder time skimming large amounts of text like your visually abled users. If this is a concern for your app, you could allow for a shortened version of the text to be used by screen readers. The shortened version could simply truncate the text to the first sentence of content ending with a period. However, note that this could be problematic, since a period has more meanings than simply ending a sentence.

请记住,使用屏幕阅读器的人很难像拥有视觉能力的用户一样浏览大量文本。 如果这是您的应用程序所关心的问题,则可以允许屏幕阅读器使用较短的文本版本。 缩短的版本可以简单地将文本截断为以句点结尾的内容的第一句。 但是,请注意,这可能是有问题的,因为句点的含义比简单地结束句子更有意义。

A better solution is to allow for a completely new piece of metadata for the express purpose of being read aloud. This metadata can be customized for use with screen readers. It could also contain text that indicates that there is more to hear by adding the words “select for more” (assuming your app actually allows for that). App design and architecture that fully streamlines the experience of all of your users can be a worthwhile effort.

更好的解决方案是允许使用全新的元数据 ,以明确表达大声读取的目的。 可以自定义此元数据以供屏幕阅读器使用。 它还可能包含一些文字,这些文字通过添加“更多选择”来表明还有更多可听的内容(假设您的应用实际上允许这样做)。 完全精简所有用户体验的应用程序设计和体系结构可能是值得的。

To change the way a TextView renders using a screen reader, you can use the contentDescription attribute, just like any other View. The screen reader will prefer the contentDescription text over the normal text. In fact, contentDescription works for all Android views, even custom views. (The general advice is not to use contentDescription with TextView, so be sure you are getting exactly the intended effect by adding it.)

要更改使用屏幕阅读器的TextView呈现方式,可以像其他任何View一样使用contentDescription属性。 屏幕阅读器将contentDescription文本而不是普通文本。 实际上, contentDescription适用于所有 Android视图,甚至自定义视图。 (一般建议不要contentDescription与TextView一起使用,因此请确保通过添加它完全达到预期的效果。)

ScrollView对于可访问性也很重要 (ScrollView is also important for accessibility)

In my last article, I pointed out that views that don’t render on screen are completely unusable and inaccessible to the user. The same is true for people using screen readers. If a view doesn’t occupy space on the screen for any reason (for example, it got pushed out of bounds by other content), it won’t be found and spoken by a screen reader. So, if you have content that doesn’t fit on screen for any reason, and you want the user to be able to see or hear its contents, you should put it in a scrolling container. Here’s a screenshot of content in a dialog that would be inaccessible without a scrolling container:

在上一篇文章中,我指出了无法在屏幕上呈现的视图对于用户是完全不可用和不可访问的。 使用屏幕阅读器的人也是如此。 如果某个视图由于某种原因没有占据屏幕空间(例如,其他内容将其推出了边界),则屏幕阅读器将不会找到该视图并说出该视图。 因此,如果您的内容由于某种原因无法显示在屏幕上,并且希望用户能够看到或听到其内容,则应将其放在滚动容器中。 这是对话框中的内容的屏幕快照,如果没有滚动容器,该对话框将无法访问:

Screenshot of overflowing text in a ScrollView
Allow text to overflow and scroll with a ScrollView container, under all circumstances.
在任何情况下,都允许文本溢出并使用ScrollView容器滚动。

Abled users will, of course, be able to scroll through the content in a ScrollView using up and down scroll gestures as you would expect. Bear in mind that TalkBack users can not scroll in the same way. TalkBack provides its own gestures and keyboard shortcuts for navigating between the next and prior elements on screen. When the user navigates to a ScrollView, TalkBack will advance through its child views, automatically scrolling the screen as it goes. This style of navigation can make large amounts of content difficult to skip — there is no “fling” shortcut for TalkBack (though you can quickly move to the last item on the screen).

当然,Abled用户将能够使用您期望的上下滚动手势在ScrollView中滚动浏览内容。 请注意,“话语提示”用户不能以相同的方式滚动。 “话语提示”提供了自己的手势和键盘快捷键,可在屏幕上的下一个和上一个元素之间进行导航。 当用户导航到ScrollView时,“话语提示”将前进至其子视图,并自动滚动屏幕。 这种导航方式会使大量内容难以跳过-“话语提示”没有“转换”快捷方式(尽管您可以快速移至屏幕上的最后一项)。

If you have large amounts of data to present, consider breaking it up into sections, initially hide the content of each section, then allow each section to be navigable by disclosure, similar to how Wikipedia’s mobile view works.

如果您要呈现大量数据,请考虑将其分解为多个部分,首先隐藏每个部分的内容,然后允许每个部分通过公开进行导航,类似于Wikipedia的移动视图的工作方式。

Screenshot of Wikipedia’s mobile view showing sections with disclosures
Wikipedia collapses sections under a heading with a disclosure arrow for faster navigation.
Wikipedia将带有标题的箭头折叠在标题下,以加快导航速度。

出色的辅助功能不仅仅需要启用屏幕阅读器 (Great accessibility requires more than just enabling screen readers)

Designing an app for accessibility goes beyond making sure all the text is readable through a screen reader. In order for an app to be a pleasure to use with accessibility tools, consider the actual user experience every step of the way.

设计可访问性的应用程序不仅要确保所有文本都可以通过屏幕阅读器阅读。 为了使应用程序易于使用可访问性工具,请考虑每个步骤的实际用户体验。

翻译自: https://medium.com/mesmerhq/optimize-your-android-app-ux-for-screen-readers-454837bc4d30

索尼vgn ux拆屏幕

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值