No accessibility events/delegates do not apply to Activities, and they don't need to. Every Activity should have a root/content view that is an instance of ViewGroup. This has worked well for me to filter all accessibility events within an activity:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
View contentView = findViewById(android.R.id.content);
contentView.setAccessibilityDelegate(new View.AccessibilityDelegate(){
@Override
public boolean onRequestSendAccessibilityEvent(ViewGroup host, View child, AccessibilityEvent event) {
Log.wtf("Event: " + event.toString());
return super.onRequestSendAccessibilityEvent(host, child, event);
}
});
}
I would also point out, that TalkBack supports the ability to navigate by character, and that such a solution may be solving a problem that TalkBack users do not see as a problem. In fact in some circumstances this could be viewed as worse. Any time you're changing the content an individual with a disability sees in compared to the actual content you have to do so VERY carefully. Even though the announcement is cleaner:
"ABC" != "A B C"
For example in a different case, one might view this behavior as a "feature" like:
"NASA"
A naive implementation of this might be to just "toLowerCase" all of your content descriptions or add a space betwenn all capital letters. Clearly each of these solutions creates a different type of problem.
My point is, TalkBack gives users the ability to navigate by character if content on the screen is confusing them. AT users on various platforms will become accustomed to the "quarks" of their platform. By using one of the above solutions you have forced on them a different quark. Sometimes, the most accessible solution is to just let "ABC" == "ABC", and allow AT users to sort things out for themselves.
If you're not going to go to the trouble to fix all of your strings in the "ideal" way specifically, it is most certainly better to just leave things alone. Though, the best case scenario is to properly consider both of these problems and which solution best applies given the scenario.
Some examples of times when I prefer overriding with a content description, that could potentially be caught with regular expressions or string matching. A good implementation of this would be spotting these specific scenarios and fixing them via a REGEX -> String dictionary with "replace" to the text or content description property, and set it as the new content description.
"OFF" -> "off" //This one is super dumb on Google's part. "OFF" shows up on every switch in the OS!
"ON" -> "on" //See above comment.
"NASA" -> "nasa"
etc.
Note that in my dictionary, I'm always going towards the word and not towards the individual character announcement :). The reason for this is, I am not changing the nature of the string. Or rather, in every insance the following is true:
oldString.equalsIgnoreCase(newString);
Now add string localization into the equation and well... this is a very complicated problem indeed. Maybe just leaving things alone is the best option.
