6

As the title says, Android Talkback is not registering the onFocus event. I understand that the onFocus event is not ever registered since the screen reader is using a special type of accessibility focus. How, then, can we drive/manipulate the accessibility focus to provide the user a better experience?

I have an example here: https://codesandbox.io/s/r54j2mqrl4 . So here the console.log("hello!") is not registering for me in mobile Android Talkback, however it is registering correctly on desktop mac OSX(with no screen reader on). I am using the tab key to navigate.

Is there something similar to an onFocus event to use for Android Talkback's accessibility focus?

Thank you in advance for your time.

Device and versions:

Mobile Android Talkback: Samsung Galaxy Tab S2, Android version 7.0, Google Chrome 62.0.3202.84

Desktop Mac OSX: macOS Sierra 10.12.6, Google Chrome 61.0.3163.100

kdizzle
  • 577
  • 1
  • 11
  • 23
  • Are you trying to manipulate or respond to, accessibility focus? Your headline suggests manipulate, but your details and example seem to suggest that you're trying to respond to it. – MobA11y Nov 16 '17 at 15:00
  • I would like to manipulate(using something similar to [`focus()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus)) and also respond to accessibility focus(using something similar to `onFocus`). – kdizzle Nov 16 '17 at 18:02
  • @ChrisCM Is there any way to control Android Talkback's focus? ^^^ I've been researching for the past couple days now and i haven't been able to find any leads. – kdizzle Nov 20 '17 at 21:14

1 Answers1

2

The ".focus()" method theoretically should work. The problem would come into play in the event that the thing that was receiving "focus" would not also receive accessibility focus. An Android Accessibility Service can only accessibility focus things that are also Accessibility focusable.

Unfortunately you cannot manipulate Accessibility Focus directly from Javascript, only focus. This being said, when you're in Android and something requests focus, this usually suggests accessibility focus will also move to that item along with focus. In TalkBack terms, this is how Tab navigation works, Accessibility Focus just follows input focus around. It's not perfect, but it's a reasonable expectation that Focus and Accessibility Focus want to be the same. Though not always: EditTexts can be in an quazi focused/unfocused state in TalkBack, for good reason... you may need to interact with the onscreen keyboard while the field still has the cursor (input focus).

If the following is true:

  • Your Element is Accessibility Focusable
  • Your element is focusable
  • The thing that is A11yFocusable and the thing that is focusable are the same, and not just descendants (very important).

You can easily confirm the above three things by exploring in Android Device monitor. Triple check that you aren't focusing something (like a child of the element) of the thing that you are envision getting accessibility focus.

If, after that, you call .focus() on the thing, and it doesn't work, you have essentially found a bug in the webview you are using to render your HTML/Javascript content, and no there is nothing you can do about it.

MobA11y
  • 18,425
  • 3
  • 49
  • 76
  • the `.focus()` and `.blur()` functions work fine with Android Talkback is there really no way to respond to an accessibility focus event in Javascript? Since Accessibility Service is in java. Is it possible to access the AccessibilityService api with Javascript? – kdizzle Nov 20 '17 at 23:23
  • 1
    Nope, you cannot. There is no way for a javascript/html webview to know where accessibility focus is. Only for elements that would also receive focus when they receive accessibility focus. – MobA11y Nov 20 '17 at 23:27
  • When you say "Only for elements that would also receive focus when they receive accessibility focus", that would require a user on a mobile device to double-tap which would trigger a focus event followed with a click event. Separate question but how would you handle a situation like this where the html focus is not following the accessibility focus when making the swiping motion? – kdizzle Nov 20 '17 at 23:51
  • I mean, the functionality should be the same as you describe on desktop. The problem is, you're not using the Tab key to navigate. What I meant was, Android Chrome could potentially send a focus event, when accessibility focus is handled. In the current ecosystem this is likely no elements, but it is a "smart" thing that Chrome could do. Ultimately, I believe you are concerned with fixing problems screen reader users don't have. This is a quirk they will be accustomed to dealing with. – MobA11y Nov 21 '17 at 14:58
  • 1
    I see. Thanks for the help @ChrisCM. I've submitted a feature request to the Android team: https://issuetracker.google.com/issues/69569112 – kdizzle Nov 21 '17 at 18:11
  • Hey @ChrisCM, this issue is still pending for me. Do you know of any workarounds for this issue in the current meantime? – kdizzle Dec 15 '17 at 22:42
  • Only in native code. In web, you're kind of stuck. If you answer a more web oriented question about the behavior you want, perhaps I could suggest design alternatives. But, when you phrase it like: "Can I do this specific thing with this API?" the only answer I can give, is... no, you can't. Post a different behavioral based question and maybe I can come up with something, or ask one of our web a11y experts in the office. – MobA11y Dec 16 '17 at 06:25