技术控

    今日:0| 主题:63445
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Android accessibility debugging with Stetho

[复制链接]
回首望不到邊 发表于 2016-10-18 05:12:54
357 4
Android has a powerful built-in accessibility system that allows people to use applications through an alternative interaction mode called “focus navigation.” Rather than directly touching the screen to activate an element, focus navigation allows people who use accessibility services such as screen readers, physical switch devices, refreshable Braille displays, or voice control to focus on and activate different elements of an interface.
  Although focus navigation is built into the Android platform, many engineers don’t consider it when designing, building, and testing their applications. This can lead to a variety of problems, such as the inability to activate buttons or content being announced in the wrong order, which can be difficult to debug.
   Accessibility is important to our work at Facebook, so to help with the above challenges we’ve added support for accessibility properties toStetho, our open source Android debugging tool. Now engineers can easily find elements that aren’t accessible through focus navigation, understand the reasons behind the bug, and implement a fix.
  Let’s go over an example of a UI with a focus navigation issue and show how Stetho makes the problem easier to debug.
     

Android accessibility debugging with Stetho

Android accessibility debugging with Stetho
      Screenshot showing the currently focused element highlighted in green.      Example problem

   In this fairly simple UI, there are two TextView s and a Button inside a LinearLayout . The LinearLayout is found inside a ListView .
  1. <LinearLayout
  2.         xmlns:android="http://schemas.android.com/apk/res/android"
  3.         android:orientation="vertical"
  4.         android:layout_width="match_parent"
  5.         android:layout_height="wrap_content">
  6.         <TextView
  7.               android:text="Heading One"
  8.               android:layout_width="match_parent"
  9.               android:layout_height="wrap_content"
  10.               />
  11.         <Button
  12.               android:text="Action"
  13.               android:layout_width="wrap_content"
  14.               android:layout_height="wrap_content"
  15.               />
  16.         <TextView
  17.               android:text="Heading Two"
  18.               android:layout_width="match_parent"
  19.               android:layout_height="wrap_content"
  20.               />
  21. </LinearLayout>
复制代码
  Which views would you expect to be focusable? If you answered "the TextView s and the Button ," you'd be wrong. The correct answer is the Button and the LinearLayout .
   Since focus will first fall on the LinearLayout , screen reader users will hear the content of both TextView s before the Button that is between them. This could cause confusion if the context of the button's action depended on being preceded by the first heading. For example, if the button said “Buy Now,” and the headings were the names of two different products, a user may not understand which product they would be purchasing by clicking the button. So why is this the case, how can we fix it, and most importantly, how could we have predicted this would happen?
  Well, you could run every view through this flow chart, and keep note of what is focusable and what isn't.
     

Android accessibility debugging with Stetho

Android accessibility debugging with Stetho
      A flow chart showing exactly why a given view may or may not be focusable.      Stetho

   Or you could use Stetho! Stetho is an Android debugging platform that we open sourced last year . Since then, we've added a ton of new features, including accessibility inspection.
     

Android accessibility debugging with Stetho

Android accessibility debugging with Stetho
      Screenshot of the new Stetho Accessibility Properties panel.      Stetho now includes an Accessibility Properties section that shows:
  
       
  • Whether or not a View is focusable   
  • Why a View is or isn't focusable   
  • Whether it is the currently focused View   
  • The description that will be sent to any Accessibility Service   
  • A list of supported AccessibilityAction s, including any custom actions.  
  Let's go over these in detail.
  
       
  • Ignored: A boolean displaying whether a View will be ignored by Accessibility Services. This will always be the opposite of focusable.   
  • Focusable: A boolean displaying whether a view will be focusable by Accessibility Services. This will always be the opposite of ignored.   
  • Ignored-reasons: For ignored View s, a plain-text message explaining precisely why the View is being ignored.   
  • Focusable-reasons: For focusable Views, a plain-text message explaining precisely why the View is focusable.  
   Note that "actionable" in this context means a View is clickable, long-clickable, or focusable. This could be set explicitly via setting any of those attributes, or implicitly via adding click, long-click or focus listeners.
  
       
  • Focused: For focusable View s, a boolean displaying whether this is the currently focused view.   
  • Description: For focusable View s, the description that will be sent to Accessibility Services. This may simply be the contentDescription or text of the View itself, or may be computed by concatenating the descriptions of un-focusable child views.  
   This will not contain any additional text that individual Accessibility Services may add, such as the current state (selected, disabled, etc.) or position (in list, out of list, etc.) of the View .
  
       
  • Actions: For focusable View s, a list of all supported AccessibilityAction s that can be taken on this view, including any custom actions.  
   Running Stetho on the original example given shows that the TextView s are not focusable because they are not actionable, and therefore their description was co-opted by their ancestor, the LinearLayout .
     

Android accessibility debugging with Stetho

Android accessibility debugging with Stetho
      Screenshot showing the accessibility properties of the example TextView.       Setting android:focusable="true" on the TextView s will solve the problem by making them actionable.
  1. <TextView
  2.           android:text="Heading One"
  3.           android:focusable="true"
  4.           android:layout_width="match_parent"
  5.           android:layout_height="wrap_content"   
  6.           />
复制代码
  When both of the TextView s are focusable, the LinearLayout will inherently become un-focusable since it has no description of its own. Stetho will tell you this is the ignored reason when you inspect the LinearLayout .
     

Android accessibility debugging with Stetho

Android accessibility debugging with Stetho
      Screenshot showing the accessibility properties of the example LinearLayout.      The new accessibility additions to Stetho made the problem easy to debug and provided a clearer understanding of why the problem occurred. Stetho now makes it easier than ever to ensure your app will be a great experience for people with disabilities and other users of assistive technology.
   To learn how to integrate Stetho into your app, check out ourdocumentation. If you're interested in contributing to the project, check out Stetho onGitHub.
乐巧 发表于 2016-10-19 07:37:47
本宫准楼下的继续跟帖。。。
回复 支持 反对

使用道具 举报

蒋鑫 发表于 2016-10-22 02:11:16
元芳你怎么看?
回复 支持 反对

使用道具 举报

胡瑞 发表于 2016-11-5 14:34:38
你长的比假奶粉的毒性都大,我看了就头大。
回复 支持 反对

使用道具 举报

875456 发表于 2016-11-7 19:49:48
运气就是机会碰巧撞到了你的努力。
回复 支持 反对

使用道具 举报

我要投稿

推荐阅读


回页顶回复上一篇下一篇回列表
手机版/c.CoLaBug.com ( 粤ICP备05003221号 | 粤公网安备 44010402000842号 )

© 2001-2017 Comsenz Inc.

返回顶部 返回列表