27e2da7c171afa39358bbead18fbe3e6b8ea6637 |
|
03-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove the accessibility focus search code. 1. In JellyBean we have added some APIs to search for next accessibility focus in various directions and set accessibility focus from hover. However, we have decided that there is not clean answer for how this should behave and the APIs were hidden. Now the accessibility service is responsible for that. The unused code is now taken out. 2. This patch also takes out the hidden attribute accessibiligyFocusable since we moved the responsibility for implementing focus search strategy to accessibility services and we did not need that for Jellybean which is a good sign that this is not needed. I general this is one less thing for an app developer to worry about. We can add this if needed later. bug:6773816 Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
45a02e0809c14a52aa24658666df0d41ce661857 |
|
18-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
API for finding accessibility focus in virtual tree not needed. 1. The function for finding where the accessibility focus in a virtual node tree presented by an AccessibilityNodeProvider is not needed API since the framework already keeps track of the accessibility focused virtual node in order to draw the focus rectangle. This API adds unnecessary complexity to developers of AccessibilityNodeProviders. bug:6675330 Change-Id: I84774686b06a995073a39e45b8ef22f2cd04b773
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
8ffe8b304e4778b3c95e57ad5a77cd41c9cf9f7b |
|
15-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus search and setting it from hover are performed by the client. 1. Currently we are providing accessibility focus search algorithm in the framework and we are also setting accessibility focus from hover. It appears that implementing a focus search strategy that works for all accessibility services is non trivial task if feasible. Based on feedback from the developers of two such services at Google - TalkBack and BarilleBack - the built in focus search does not quite match what they need and they would like to implement a custom strategy. Hence, having APIs for accessibility focus search in the framework does not make. Therefore, we are hiding this APIs and later will take out the focus search logic and allow the accessibility service to implement search. Also putting accessibility focus from hover is tightly integrated with the focus search since the set of views that get accessibility focus from hover should be the same as the set of views returned by the focus search routine. Therefore, we are letting the accessibility service decide where to put accessibility focus when it gets an accessibility hover event. bug:6675330 Change-Id: Ie152230990a6602f3fd1d82de2177d0b1444d654
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
57aab755441a28c2e5c78c35a57b940afc2799e0 |
|
10-May-2012 |
alanv <alanv@google.com> |
Fixed typo in findAccessibilityFocus API. Change-Id: I3ca1448792a1b712f781c1bfa73823ca08ea3d39
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
76f287e416ded85734b610f316e38d243d2ddb09 |
|
23-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing hierarchical accessibility focus directions. 1. The accessibility focus directions are not needed since an accessibility service just get the root, first child, next sibling, previous sibling and call execute the action to give it accessibility focus. Now the accessibility node info tree is properly ordered taking into account layout manager directions for both layout manager that we report and ones that we have determined as not important for accessibility. Also the position of a node info are ordered properly based on their coordinates after all transformations as opposed to child index. bug:5932640 Change-Id: I994a8297cb1e57c829ecbac73a937c2bcbe0bac7
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
aa780c110922148a6a4ba06734bb2b0bb8c98f93 |
|
20-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding support for traversing the content of a node info at granularity. 1. A view that creates an accessibility node info may add to the info a list of granularity labels. These are granularities by which the source view can iterate over its content. For example a text view may support character, word link while a web view may additionally support buttons, tables, etc. There are actions on accessibility node info to go to the next/previous at a given granularity which is passesed as an argument. 2. Added Bundle argument to the APIs for performing accessibility actions. This is generic and extensible. bug:5932640 Change-Id: I328cbbb4cddfdee082ab2a8b7ff1bd7477d8d6f9
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework Usefulness: Keep track of the current user location in the screen when traversing the it. Enabling structural and directional navigation over all elements on the screen. This enables blind users that know the application layout to efficiently locate desired elements as opposed to try touch exploring the region where the the element should be - very tedious. Rationale: There are two ways to implement accessibility focus One is to let accessibility services keep track of it since they have access to the screen content, and another to let the view hierarchy keep track of it. While the first approach would require almost no work on our part it poses several challenges which make it a sub-optimal choice. Having the accessibility focus in the accessibility service would require that service to scrape the window content every time it changes to sync the view tree state and the accessibility focus location. Pretty much the service will have to keep an off screen model of the screen content. This could be quite challenging to get right and would incur performance cost for the multiple IPCs to repeatedly fetch the screen content. Further, keeping virtual accessibility focus (i.e. in the service) would require sync of the input and accessibility focus. This could be challenging to implement right as well. Also, having an unlimited number of accessibility services we cannot guarantee that they will have a proper implementation, if any, to allow users to perform structural navigation of the screen content. Assuming two accessibility services implement structural navigation via accessibility focus, there is not guarantee that they will behave similarly by default, i.e. provide some standard way to navigate the screen content. Also feedback from experienced accessibility researchers, specifically T.V Raman, provides evidence that having virtual accessibility focus creates many issues and it is very hard to get right. Therefore, keeping accessibility focus in the system will avoid keeping an off-screen model in accessibility services, it will always be in sync with the state of the view hierarchy and the input focus. Also this will allow having a default behavior for traversing the screen via this accessibility focus that is consistent in all accessibility services. We provide accessibility services with APIs to override this behavior but all of them will perform screen traversal in a consistent way by default. Behavior: If accessibility is enabled the accessibility focus is the leading one and the input follows it. Putting accessibility focus on a view moves the input focus there. Clearing the accessibility focus of a view, clears the input focus of this view. If accessibility focus is on a view that cannot take input focus, then no other view should have input focus. In accessibility mode we initially give accessibility focus to the topmost view and no view has input focus. This ensures consistent behavior accross all apps. Note that accessibility focus can move hierarchically in the view tree and having it at the root is better than putting it where the input focus would be - at the first input focusable which could be at an arbitrary depth in the view tree. By default not all views are reported for accessibility, only the important ones. A view may be explicitly labeled as important or not for accessibility, or the system determines which one is such - default. Important views for accessibility are all views that are not dumb layout managers used only to arrange their chidren. Since the same content arrangement can be obtained via different combintation of layout managers, such managers cannot be used to reliably determine the application structure. For example, a user should see a list as a list view with several list items and each list item as a text view and a button as opposed to seeing all the layout managers used to arrange the list item's content. By default only important for accessibility views are regared for accessibility purposes. View not regarded for accessibility neither fire accessibility events, nor are reported being on the screen. An accessibility service may request the system to regard all views. If the target SDK of an accessibility services is less than JellyBean, then all views are regarded for accessibility. Note that an accessibility service that requires all view to be ragarded for accessibility may put accessibility focus on any view. Hence, it may implement any navigational paradigm if desired. Especially considering the fact that the system is detecting some standard gestures and delegates their processing to an accessibility service. The default implementation of an accessibility services performs the defualt navigation. bug:5932640 bug:5605641 Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|
021078554b902179442a345a9d080a165c3b5139 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding APIs to enable reporting virtual view hierarchies to accessibility serivces. Added an interface that is the contract for a client to expose a virtual view hierarchy to accessibility services. Clients impement this interface and set it in the View that is the root of the virtual sub-tree. Adding this finctionality via compostion as opposed to inheritance enables apps to maintain backwards compatibility by setting the accessibility virtual hierarchy provider on the View only if the API version is high enough. bug:5382859 Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeProvider.java
|